Apache/MySQL 服务器块

Question

这是我的猜测，我尽可能逐字逐句地解释了日志，同时也做了一些推断：

某物（可能与硬件有关，但也可能是一个软件错误或文件系统损坏）导致 MySQL 守护进程在尝试完成更新查询时死锁。
您正在运行 Apache 的“prefork”MPM（多处理模块）（这是一个猜测）。这意味着每个同时的 HTTP 请求都会获得一个 Apache 进程。因此，您要么会收到大量同时的请求（啊啦DDoS），或者随着时间的推移，您会逐渐收到一些请求，但这些请求无法完成，因为 Apache 模块（可能是 mod_php、CGI 等）中的某些代码是 MySQL 客户端，并且正在调用 MySQL 执行一些更新查询。由于上述 MySQL 死锁，该查询处于“挂起”状态，因此 MySQL 永远不会回复您的代码，因此您的代码永远不会完成 HTTP 请求，因此 Apache 会保持与 Web 客户端的连接，因此 Apache 进程会堆积起来。您还可能会在 Web 前端观察到，服务器似乎需要很长时间才能回复用于获取某些页面的 HTTP 请求，也许它根本不会回复，只是超时。
涉及 MySQL 的 cron 作业因与 Apache 进程类似的原因而堆积。

当我遇到类似这样的怪异问题时，我喜欢“把洋葱从里到外剥开”，这是我对“洋葱的内层”是较低级别的东西，而洋葱的外层是依赖于较低级别的东西的较高级别的东西的比喻。因此，从内到外，我们大致有这个（过于简化的）堆栈，从内到外：

硬件
操作系统内核及驱动、进程管理、任务调度等
文件系统
C 库，在内核 ABI 之上实现 TCP/IP 例程的其他低级库
数据库服务器
用户空间配置（DNS解析/etc/hosts等）
您的 Web 服务器 (Apache)
您的服务器端网页代码和 HTML
Web 前端

那么让我们看看如何处理每一层上明显的死锁：

硬件：首先，进行 RAM 测试，并运行类似程序smartctl，检查 SMART 是否认为您的磁盘正常。如果您发现硬件故障的迹象，则很可能是硬件故障造成的。
操作系统内核：检查dmesg是否有WARNING或BUG或OOPS行，这可能表示您正在使用的内核版本或驱动程序中存在错误。除了警告和错误之外，阅读dmesg一般内容也很有用；查找任何异常情况，如果有疑问，请在 Google 上搜索错误消息，删除任何系统特定的详细信息，例如 IP 地址。
文件系统：在 MySQL 数据库所在的文件系统上运行只读命令fsck。如果您不确定，/var这是一个很好的起点——/var使用找出挂载的位置sudo mount，然后是fsck该卷，运行适当的fsck命令以指示只读完整性检查。
C 库：有时，您可能会遇到用户空间低级中间件（如 C 库）中的错误，但除非您自定义编译了大量内容，否则这种情况并不常见。版本不匹配的可能性更大，但如果您运行的是来自 vanilla Ubuntu 存储库的软件包，那么这也不太可能是罪魁祸首。
数据库服务器：MySQL 在管理其数据库文件时完全有可能存在错误，并意外将损坏的数据写入磁盘上的 DB 文件。即使您的硬盘硬件没有问题，文件系统检查无误，也可能存在这种情况。例如，可能存在竞争条件，甚至可能自 Ubuntu 12.04 发布以来就已修复了这种竞争条件（或者竞争条件仍然存在，而您只是真的很不幸，你的工作量很大。这里要检查的是尝试一些建议的技巧这里，这实际上涉及将所有表写入 SQL 文件，然后重新导入它们。如果数据库的数据文件损坏严重，您可能必须删除数据库并从头开始重新初始化；请小心，因为您可能会丢失权限等。此外，如果您的数据库处于损坏状态，则输出的 SQL 可能不包含您的所有数据，因此，除非您备份原始数据库文件，你可能会丢失数据。所以要小心。
用户空间配置：我想不出这个特定层会出什么问题，从而导致您在 mysqld 日志中报告的“信号量”问题。可以安全地假设该层运行正常。
Web 服务器：如果 Apache 有问题，那么您不会看到cron脚本出现任何异常行为，只需简单操作/etc/init.d/apache2 restart即可完全解决问题。但事实并非如此，不是吗？
您的代码：考虑到您迄今为止发布的日志的输出，这似乎不太可能是罪魁祸首，除非您绕过 MySQL 并直接写入其数据库，或者绕过文件系统在原始磁盘设备上执行块级 I/O，或者类似同样疯狂的事情。
网络前端：是的，从日志来看，这不太可能是问题所在。

Answer 1

这是我的猜测，我尽可能逐字逐句地解释了日志，同时也做了一些推断：

某物（可能与硬件有关，但也可能是一个软件错误或文件系统损坏）导致 MySQL 守护进程在尝试完成更新查询时死锁。
您正在运行 Apache 的“prefork”MPM（多处理模块）（这是一个猜测）。这意味着每个同时的 HTTP 请求都会获得一个 Apache 进程。因此，您要么会收到大量同时的请求（啊啦DDoS），或者随着时间的推移，您会逐渐收到一些请求，但这些请求无法完成，因为 Apache 模块（可能是 mod_php、CGI 等）中的某些代码是 MySQL 客户端，并且正在调用 MySQL 执行一些更新查询。由于上述 MySQL 死锁，该查询处于“挂起”状态，因此 MySQL 永远不会回复您的代码，因此您的代码永远不会完成 HTTP 请求，因此 Apache 会保持与 Web 客户端的连接，因此 Apache 进程会堆积起来。您还可能会在 Web 前端观察到，服务器似乎需要很长时间才能回复用于获取某些页面的 HTTP 请求，也许它根本不会回复，只是超时。
涉及 MySQL 的 cron 作业因与 Apache 进程类似的原因而堆积。

当我遇到类似这样的怪异问题时，我喜欢“把洋葱从里到外剥开”，这是我对“洋葱的内层”是较低级别的东西，而洋葱的外层是依赖于较低级别的东西的较高级别的东西的比喻。因此，从内到外，我们大致有这个（过于简化的）堆栈，从内到外：

硬件
操作系统内核及驱动、进程管理、任务调度等
文件系统
C 库，在内核 ABI 之上实现 TCP/IP 例程的其他低级库
数据库服务器
用户空间配置（DNS解析/etc/hosts等）
您的 Web 服务器 (Apache)
您的服务器端网页代码和 HTML
Web 前端

那么让我们看看如何处理每一层上明显的死锁：

硬件：首先，进行 RAM 测试，并运行类似程序smartctl，检查 SMART 是否认为您的磁盘正常。如果您发现硬件故障的迹象，则很可能是硬件故障造成的。
操作系统内核：检查dmesg是否有WARNING或BUG或OOPS行，这可能表示您正在使用的内核版本或驱动程序中存在错误。除了警告和错误之外，阅读dmesg一般内容也很有用；查找任何异常情况，如果有疑问，请在 Google 上搜索错误消息，删除任何系统特定的详细信息，例如 IP 地址。
文件系统：在 MySQL 数据库所在的文件系统上运行只读命令fsck。如果您不确定，/var这是一个很好的起点——/var使用找出挂载的位置sudo mount，然后是fsck该卷，运行适当的fsck命令以指示只读完整性检查。
C 库：有时，您可能会遇到用户空间低级中间件（如 C 库）中的错误，但除非您自定义编译了大量内容，否则这种情况并不常见。版本不匹配的可能性更大，但如果您运行的是来自 vanilla Ubuntu 存储库的软件包，那么这也不太可能是罪魁祸首。
数据库服务器：MySQL 在管理其数据库文件时完全有可能存在错误，并意外将损坏的数据写入磁盘上的 DB 文件。即使您的硬盘硬件没有问题，文件系统检查无误，也可能存在这种情况。例如，可能存在竞争条件，甚至可能自 Ubuntu 12.04 发布以来就已修复了这种竞争条件（或者竞争条件仍然存在，而您只是真的很不幸，你的工作量很大。这里要检查的是尝试一些建议的技巧这里，这实际上涉及将所有表写入 SQL 文件，然后重新导入它们。如果数据库的数据文件损坏严重，您可能必须删除数据库并从头开始重新初始化；请小心，因为您可能会丢失权限等。此外，如果您的数据库处于损坏状态，则输出的 SQL 可能不包含您的所有数据，因此，除非您备份原始数据库文件，你可能会丢失数据。所以要小心。
用户空间配置：我想不出这个特定层会出什么问题，从而导致您在 mysqld 日志中报告的“信号量”问题。可以安全地假设该层运行正常。
Web 服务器：如果 Apache 有问题，那么您不会看到cron脚本出现任何异常行为，只需简单操作/etc/init.d/apache2 restart即可完全解决问题。但事实并非如此，不是吗？
您的代码：考虑到您迄今为止发布的日志的输出，这似乎不太可能是罪魁祸首，除非您绕过 MySQL 并直接写入其数据库，或者绕过文件系统在原始磁盘设备上执行块级 I/O，或者类似同样疯狂的事情。
网络前端：是的，从日志来看，这不太可能是问题所在。

Apache/MySQL 服务器块

答案1

相关内容