观察到MySQL阻塞和奇怪的线程/连接行为。

Question

我们有一个MySQL实例，它在大多数情况下工作得很好。然而，我们不时地观察到奇怪的行为。发生的情况是，MySQL连接突然达到极限(目前设置为1000)，而MySQL几乎处于停滞状态。当我们检查此服务器的图表时，会观察到以下情况：

图像来自运行MySQL导出程序的Grafana实例。困扰我的是为什么缓存中的线程不被重用。另一个问题是为什么缓存中的线程突然下降到零，但同时没有创建新的线程(根据第二条图-蓝线保持在0)。

最终，我的目标是理解为什么会突然使用1000个连接，以及这是否是MySQL或应用程序的问题。对于线程，MySQL文档就是这样说的：

服务器应该缓存多少个线程以进行重用。当客户端断开连接时，如果缓存中的线程少于thread_cache_size线程，则将客户机的线程放在缓存中。如果可能的话，通过重用从缓存中获取的线程来满足对线程的请求，并且只有在缓存为空时才会创建一个新线程。

如有任何协助或指导，将不胜感激！

Answer 1

雷鸣般的羊群。或者，杂货店里有这么多人，以至于没有人能移动他们的手推车。

当Threads_running为349时，每个人都在等待、等待和等待一小片CPU和少量的I/O和.结果是，它们都需要“永远”才能完成。同时，其他人试图进入是因为你有这么高的max_connections，等等。

但是，这并不能解释是什么把牛群推下悬崖的。这可能是像一个大的SELECT一样琐碎的事情，恰好阻碍了羊群通常所做的事情。

你打开慢速日志了吗？long_query_time值很低？如果是这样，您可能已经在缓慢日志中找到了答案。由于您没有惊慌失措和重新启动，所以该慢速选择(如果它确实存在)将在慢速日志中。根据图表，我猜它可能有80到110秒的时间。

至于Threads_cached的下滑，这有点复杂。首先，让我解释一下不沾的部分。在“事件”之前，大约有200个连接，每个连接持续的时间足够长，可以连接到一个“稳定的”200个连接。

活动结束后，等待进入的人数太多，以至于人数增加到350人左右。

拥有thread_cache_size = 500会浪费内存；建议您将其降低到250个。

至于探底，我来猜一猜。如此多的连接如此努力地完成任务，以至于新的连接被拒绝访问。(这可能是MySQL的蓄意行为，也可能是每个人为各种互斥而爬来爬去的副作用。)

拥有max_connections = 1000也是不明智的；这只会引发这样的场景。相反，让客户在遇到麻烦时“采取行动”--通过拒绝访问MySQL。此外，这使得更容易说"Oops，都有问题，请稍候，请不要再按下发送，也不要刷新！“或者干脆给个"500“。

一句话:我认为慢速日志可以指出事件的原因。