我在 CentOS 6.6 上运行 WHM/cPanel 服务器，使用的是 Apache 2.4 和 PHP 5.5。大约每周，所有六个核心的 CPU 使用率都会飙升至 100%，并一直保持到 Apache 重新启动，此时一切都恢复正常。有趣的是，Apache 的server-status页面似乎不知道这些进程的存在：
顶部：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25901 nobody 20 0 1973m 28m 276 R 74.8 0.4 3:39.30 httpd
24861 nobody 20 0 1973m 28m 280 R 74.1 0.4 12:05.31 httpd
25076 nobody 20 0 1973m 28m 276 R 65.8 0.4 10:09.38 httpd
24727 nobody 20 0 1973m 28m 280 R 64.5 0.4 14:37.09 httpd
25874 nobody 20 0 1973m 28m 276 R 64.5 0.4 3:57.69 httpd
24747 nobody 20 0 1973m 28m 276 R 64.1 0.4 15:06.89 httpd
25998 nobody 20 0 1973m 28m 276 R 63.8 0.4 2:40.92 httpd
25624 nobody 20 0 1973m 28m 276 R 61.8 0.4 5:28.76 httpd
25646 nobody 20 0 1973m 28m 276 R 58.8 0.4 5:07.88 httpd
状态页：
Server Version: Apache/2.4.12 (Unix) OpenSSL/1.0.1e-fips mod_bwlimited/1.4
Server MPM: event
Server Built: Mar 27 2015 11:20:11
Current Time: Tuesday, 09-Jun-2015 09:21:07 CDT
Restart Time: Tuesday, 02-Jun-2015 11:38:37 CDT
Parent Server Config. Generation: 12
Parent Server MPM Generation: 11
Server uptime: 6 days 21 hours 42 minutes 30 seconds
Server load: 8.17 7.35 10.46
Total accesses: 461541 - Total Traffic: 10.7 GB
CPU Usage: u111.81 s369.94 cu305989 cs438.15 - 51.4% CPU load
.774 requests/sec - 18.7 kB/second - 24.2 kB/request
7 requests currently being processed, 118 idle workers
PID Connections Threads Async connections
total accepting busy idle writing keep-alive closing
21715 1 yes 1 24 0 1 0
4766 0 yes 0 25 0 0 0
10222 0 yes 0 25 0 0 0
10278 6 yes 6 19 0 0 0
10194 0 yes 0 25 0 0 0
Sum 7 7 118 0 1 0
_____________________W__________________________________________
_____________W__W____W____W_W___W___.........................___
______________________
Apache 状态页面报告的所有请求似乎都没有什么意义，这是有道理的，因为没有列出占用大量 CPU 的 PID。内存使用率、磁盘 I/O 和网络流量始终保持相对平稳，问题不会在一天中的一致时间出现。此服务器上有数十个小型网站，这使得手动搜索访问日志变得很困难。
这可能是什么原因造成的？我是不是误解了 Apache 报告数据的方式？有没有更好的方法来跟踪负责的进程并查看它实际上在做什么？
答案1
您可以使用调试实用程序“strace”和占用大量 CPU 的 PID 来查看原因。它可能会指出问题所在，strace -p <PID>
答案2
可能有两个原因：
备份 - cPanel 备份过程有点繁重，因此首先检查 Apache 负载是否在备份过程启动后几秒/几分钟内启动。
大量更新 - 更有可能；每天和每周，cPanel 都会下载大量不同的更新和检查，并且在更新期间运行许多奇怪的内部重量级程序，包括许可证验证程序，这有时会给某些用户带来问题。
不幸的是，cPanel 的 Apache 与重量级的 cPanel CGI 脚本绑定在一起，这些脚本负责执行部分更新和验证。根据我的 cPanel 经验，我敢打赌，正是这些 CGI 脚本导致了您的 Apache 问题，因为它们与 cron 作业之间的交互导致了死锁。
要检查这两个原因，请以 root 身份运行逐个禁用 cron 作业：
crontab -e
尝试一次只禁用一项服务并等待一周，直到看到下一个高 CPU 使用率，或者发现有问题的服务。
答案3
您是否尝试过设置LogLevel debug并检查 {access,error}_log 文件以获取任何提示？
最近，我也需要在 apache2 中调试一些东西。对我有帮助的是停止 apache2 服务并使用以下命令手动启动它：
# strace -f -s 1024 -o /tmp/httpd.strace /usr/local/apache/bin/httpd -k start -DSSL -X
我从您的 JSFiddle 中获取了完整的命令行，并仅添加了-X启用调试模式的选项。
一旦遇到同样的情况，您可以查看/tmp/httpd.strace提示。使用strace-graph /tmp/httpd.strace查看在运行期间调用了哪些子流程可能会很有用strace。
答案4
使用错误进程的 PPID 来追踪父进程。我怀疑您有两个不同的 apache 守护进程正在运行。CPanel 似乎可能会这样做，以便能够以 root 身份执行操作，但我注意到这些进程是用户 nobody。也许您有一个轻量级 apache，它处理传入请求并将它们传递给运行更重 mod_php 进程的第二个 apache？也许还有其他事情发生，但您的首要任务是找到那些 apache 进程是什么。您能看到两个单独的 apache 配置吗？
lsof 可能会有用。您将获得诸如给定 apache 进程打开了哪些日志文件以及它正在监听哪些端口号等信息。
假设我对它可能监听不同端口的说法是正确的，那么设置一些东西来捕获该端口上的流量可能会很有用，这样您就可以看到是什么触发了高 CPU 情况。很可能让 tcpdump 将所有流量写入文件并没有什么大不了的，但您应该监视磁盘空间以防它意外地大。
有趣的是，重新启动 Apache 似乎确实有效。也许我对存在两个 Apache 的想法是错误的，或者可能是在 Apache 实例之间转发了请求。
sudo netstat -plnt可能很有趣。它会显示与每个监听端口关联的进程和 pid。如果有两个 apache，您会在其中找到它们。 ps wwuaxf或者pstree还会显示按父进程分组的 apache 进程。您将看到命令行参数
编辑：OP 评论后的补充。
init 进程的子进程要么是正在运行的独立 Apache 实例，要么是出于某种原因未被清除的僵尸进程。在这种情况下，父进程已终止，但子进程无法停止，因此已转移到以 init 进程为父进程。
高 CPU 可能类似于反复尝试与丢失的父进程通信，尽管在这种情况下它可能会通过 strace 显示出来。我会仔细观察 apache 重新启动时发生的情况。
是否仍有一些旧进程在运行？您是否有高 CPU 何时开始的良好记录？（也许可以使用 sar、munin 和 kSar，sar 效果很好，否则只有文本表作为输出）。您能将其与 apache 重新启动的时间关联起来吗？（例如，夜间日志滚动或手动操作）。也许您可以发现与系统上发生其他事情时的联系。如果每次都在同一时间发生，那么这对于追踪事情非常有用。