mysql定期停止响应

Question

我在运行于32 32xCPU VPS上的Ubuntu14.04.3服务器上运行一个站点(Magento)。

当负载很重时，它通常会接收20-25个请求/秒。在magento中，对mysql表有一个特定的UPDATE查询，该查询通常需要1ms(±0.2ms)，每分钟运行大约200到300次(3-5次查询/秒)。然而，在这些重负荷的间隔1-2小时内，这个特定的查询突然需要5-35秒才能完成，这也会使整个网站处于停顿状态(甚至没有此查询的请求)。

我已经监测了内存和cpu的利用率，负载通常在22-28左右徘徊，无论是在冻结之前还是在冻结期间。冻结似乎几乎是永久性的。它可以持续至少40分钟，重新启动mysql和php不会使它消失。RAM的使用永远不会超过10 % av可用的RAM，交换永远不会被使用。

我必须解决的唯一方法是重新启动VPS，这让我相信有一个潜在的系统错误配置负责冻结。

不过，一个有趣的提示是:这个问题有几次在没有重新启动的情况下解决了。这些情况的共同点是，这个查询“只”需要2-7秒才能完成。在这种情况下，问题在10-15分钟内就会消失。

那么，对于是什么原因以及我如何才能找到真正的潜在问题，有什么建议吗？

更新1:系统负载( 32 CPU核心的1分钟负载)通常在27-28达到峰值，但在极端负载下可高达40。当发生这种冻结时，通常在冻结之前和期间负载为22-27。在冻结期间，大多数可用的CPU核心(32)都有一些空闲时间。

更新2:我对my.cnf做了以下更改：

innodb_buffer_pool_size = 10G (Innodb data is 5.5G)
key_buffer          = 16M
max_allowed_packet  = 16M
thread_stack        = 192K
thread_cache_size   = 8
max_connections     = 1024

Answer 1

你监视过磁盘I/O吗？I/O等待时间或排队事务是否增加？由于主机的I/O限制，请求可能在存储级别排队。另外，您是否检查了是否达到了允许的最大mysql客户端？如果这些查询突然需要很长时间才能完成，那么也有可能因为其他连接关闭得不够快，所以没有为正常的站点通信留下足够多的可用连接。

Answer 2

如果您使用的是VPS，您可能无法在相同的物理硬件上看到其他主机上正在发生的事情。

可能是IO重加载(可能是由您加载)导致了完全独立的VPS备份，然后需要时间来解决。这可能是为什么在您的系统上重新启动php和mysql并不足以使事情回到正轨。有趣的是，重新启动VPS听起来确实解决了问题吗？有没有可能那只是一段时间的函数？

如果关闭php和mysql，您可能会认为您的系统中不会有太多的资源消耗(我在那里做了很多假设，但您应该知道更多)。不过，看看这个。

看看还在进行什么活动。Atop是一个很好的工具，它包括查看每个进程的IO活动，并给出足够的权限。iostat对于查看每个设备的总磁盘活动非常有用。

如果您的VPS中没有太多的磁盘活动，但是性能很差，那么很可能是在另一个VPS中，甚至可能是在主机中。你需要和你的主机提供商谈谈这个问题，但是要知道，如果是你触发了这个问题，那么你会希望他们会对此感到担忧。

Answer 3

如果VPS负载很重，您是否可以提供有关VPS负载的信息，以及系统日志？