☰

MySQL 在明显崩溃后重新启动时变得不堪重负

tag-icon • tag-icon mysql
MySQL 在明显崩溃后重新启动时变得不堪重负

今天早上我发现我的网站死机了，每个请求都超时了。 systemctl restart nginx没什么区别 - 但systemctl restart mysql确实如此。

昨晚我设置了一个长时间UPDATE运行的查询。我怀疑这 10 个小时就是导致 mysql 死机的原因。

但现在我的服务器通常平均负载为 1-2（32 个内核），但负载却不断达到 20+。 网站上一个常见的复杂查询show processlist显示很多creating sort index，但以前从未出现过问题。最终网站停止响应，我不得不再次重启 mysql。

我已经对查询中涉及的所有表运行了修复/优化UPDATE。还可能发生了什么？

答案1

如果您使用 SIGKILL 终止 mysqld，或者在长期未提交的事务期间发生崩溃，则在启动时，mysql 将回滚该事务。如果您使用的是 InnoDB，则每个查询默认都包含在一个事务中。

我建议让它完成回滚。

您可以使用以下方式监视状态：

SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND <> 'Sleep' and TIME > 1 ;
SHOW ENGINE INNODB STATUS \G

答案2

codemonkey，

在 SHOW GLOBAL STATUS 中，您的 7 天正常运行时间内 max_used_connections 为 98。由于您的网站很受欢迎，将 max_connections 从 500 降低到 256 可能是合理的。

每秒速率 = RPS

对 my.cnf [mysqld] 部分的建议

innodb_io_capacity=900  # from 200 to use more of your available NVME IOPS
read_rnd_buffer_size=16K  # from 4M to reduce handler_read_rnd_next RPS of 36,095
innodb_max_dirty_pages_pct_lwm=0.00001  # from 0 percent to ENABLE pre-flushing
innodb_max_dirty_pages_pct=0.00001  # from 90 percent to clear innodb_buffer_pool_pages_dirty faster. You had 194,905 dirty pages when SGS recorded.  A very large number of dirty pages to keep up with on your server.

还有更多机会可以改善您的配置以获得更好的性能。请查看个人资料。

相关内容