如何跟踪和调试 mySQL 性能问题?

如何跟踪和调试 mySQL 性能问题?

我有一个运行 Mac OS X 10.4(Darwin 内核版本 8.10.1)的服务器系统。该服务器主要用作 Bugzilla 服务器,但也运行一些其他基于 Web 的服务(Testlink、TikiWiki)。

Bugzilla 数据库中大约有 60,000 个 Bug,系统上大约有 300 个活跃用户。

Bugzilla 版本为 3.0,运行于 Perl 5.8.6、Apache 1.3.33 和 mySQL 5.0.38

有时,我们会遇到 Bugzilla 抛出数据库错误的严重问题:

Software error:

Can't connect to the database.
Error: Too many connections

我已经有了几条解决该问题的可能线索,但我想提出一个更普遍的问题:如何调试这些类型的问题?

目前我们已经设置了以下内容来监控 mySQL 数据库:

  • 每 5 分钟转储完整 mysql 进程列表的 cron 作业
  • 在 my.cnf 中启用 log-slow-queries 来记录耗时超过 15 秒的查询

我们刚刚开始收集这些数据,看看是否能找到“连接过多”问题的原因。

您能想到其他什么方法可以监控 mySQL 数据库并帮助诊断问题的根本原因吗?

答案1

在诊断这些类型的错误时,有两种不同的攻击计划可供遵循:

首先,有可能这是与正在使用的实际软件相关的问题:某些东西本质上吸收了连接并且不释放它们(无论是就挂起线程而言,还是在合理的时间内就慢速查询而言)。

慢查询日志对于诊断问题非常有用,但您给出的 15 秒值几乎毫无用处:如果查询需要 15 秒,那么您就完蛋了。一般来说,我会查找运行时间超过一两秒的查询。使用 EXPLAIN 关键字处理此日志中显示的内容,并查看导致速度变慢的原因(连接错误、排序需要临时表等)——如果无法深入研究并修改代码/数据库设计,查询缓存和索引的一些巧妙方法通常可以提供帮助。

另外,不要忽视 mysql 中的常规查询日志。虽然您不想在生产服务器上长时间打开它,但它可以快速告诉您是否软件中的某个特定功能正在用数百个小查询来敲打数据库,而不是单个查询会花费很长时间。显然,解决此类问题的唯一方法是通过重构代码。

第二,您需要调查软件配置是否是罪魁祸首。您遇到了多少个并发连接?mysql 中设置的最大连接数实际是多少。这可能是因为 apache 正在处理 100 个并发请求,而 mysql 仅配置为接受 20 个连接 - 显然会出现问题。如果您可以衡量您预计要处理的流量,那么只需一些常识(偶尔使用一点 Google 来找到正确的设置)即可平衡所有组件。

答案2

您有多少个 apache 工作者?您允许的最大 mysql 连接数是多少?由于 apache 在处理请求时为每个 httpd 工作者生成一个 cgi 进程,因此如果前者大于后者,则 apache 可以打开比 mysql 允许更多的连接。

我建议以下日志设置

log_slow_queries
log-queries-not-using-indexes
set-variable = long_query_time=1

答案3

用于转储的 cron 作业非常有用,但如果你没有准备好实际绘制图表的东西,我建议穆宁有用于监控的 MySQL 插件

  • 吞吐量
  • 查询
  • 数据库大小
  • 慢查询
  • 线程

这对于确定峰值非常有帮助。我默认以五分钟为间隔运行。

在过去一年的使用过程中,我发现了之前相当有趣的情况,如果没有它,可能完全不会被注意到。

相关内容