我使用Apache 2.4和PHP 5.5在CentOS 6.6上运行WHM / cPanel服务器。 每个星期左右，所有六个内核的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的Hogging PID列出。 内存使用情况，磁盘I / O和networkingstream量在整个过程中都保持相对平稳，并且问题不会在一个一致的时间出现。 在这个服务器上有几十个小站点，这将使人手难以search访问日志。
什么可能导致这个？ 我只是误解了Apache报告数据的方式吗？ 有没有更好的方式去追溯负责的stream程，看看它究竟在做什么？
您可以使用CPU占用PID的debugging工具“strace”来查看原因。 它可能会指出你遇到的问题， strace -p <PID>
有两个可能的原因：
备份 – cPanel备份过程有点繁重，所以首先检查一下备份过程开始后Apache load是否启动秒/分钟。
大量更新 – 更可能; 每天和每周cPanel下载大量的不同的更新和检查，并在更新期间运行许多奇怪的内部，重量级的程序，包括许可证validation，这有时会导致一些用户的问题。
不幸的是，cPanel的Apache绑定了大量的cPanel CGI脚本，这些脚本会执行这些更新和validation的某些部分。 从我的cPanel体验中，我敢打赌，这些CGI脚本正是由于它们和cron作业之间的交互造成的死锁而对Apache的问题负责的。
要检查这两个原因，以root身份运行一个一个地禁用cron作业：
crontab -e
尝试一次只禁用一个服务并等待一个星期，直到您看到下一个较高的CPU使用率，或find有问题的一个。
你有没有尝试设置LogLevel debug并检查{访问，错误} _log文件的任何提示？
最近，我不得不在apache2中debugging一些东西。 帮助我的是停止apache2服务，并使用以下命令手动启动它：
# strace -f -s 1024 -o /tmp/httpd.strace /usr/local/apache/bin/httpd -k start -DSSL -X
我从JSFiddle中获取了完整的命令行，只需添加-X选项即可启用debugging模式。
一旦你遇到相同的情况，你可以看看/tmp/httpd.strace提示。 使用strace-graph /tmp/httpd.strace来查看strace运行期间调用的subprocess可能是有用的。
使用错误进程的PPID来追踪父进程。 我怀疑你有两个不同的Apache守护进程运行。 CPanel可能会这样做，以便能够以root身份执行操作，但是我注意到这些进程是用户nobody。 也许你有一个轻量级的apache来处理不断增长的请求，并把它们传递给第二个运行较重的mod_php进程的apache？ 也许还有其他的事情，但你的第一个任务是find这些Apache进程是什么。 你能看到两个单独的Apacheconfiguration？
LSF可能是有用的。 你会得到像给定的Apache进程打开哪些日志文件，以及它正在监听的端口号。
假设我是对的，可能在不同的端口上监听，那么设置一些东西来捕获那个端口上的stream量可能是有用的，所以你可以看到什么触发了高CPU的情况。 有可能把tcpdump写入文件的所有stream量都是没有什么大不了的，尽pipe你应该监视磁盘空间，以防万一它出乎意料的大。
有趣的是，你重新启动Apache似乎工作。 也许我只是错了，有两个apaches，或者可能有请求被转发之间的Apache实例。
sudo netstat -plnt可能很有趣。 它会告诉你什么进程和PID与每个侦听端口相关联。 如果有两个阿帕奇，你会在那里find他们。 ps wwuaxf或pstree也会显示按父进程分组的apache进程。 你会看到命令行参数
编辑：额外的意见后，从OP。
初始化进程的孩子是单独运行的apache实例，或者是由于某种原因没有被收获的僵尸进程。 在这种情况下，父进程已经死亡，但是subprocess不能被停止，并且已经被转移到了作为父进程的init进程。
高CPU可能是像重复尝试与缺less的父进程谈话，但在这种情况下，它可能会显示strace。 我会仔细看看当apache重启时会发生什么。
一些旧的进程还在运行吗？ 你有好的logging，当高CPU踢？ （也许使用sar，munin，kSar和sar很好，否则只有文本表作为输出）。 你可以关联与Apache重新启动时？ （例如每晚的日志翻转或手动操作）。 也许您可以在系统上发生其他事情时发现连接。 如果每次都在同一时间发生，那么对于追踪内容非常有用。