今天无意中查看到了一个apache+php的服务器上出现了很多httpd <defunct> 进程。
第一次见到这个名字的进程，于是查阅了相关资料。
记录一下我理解到的httpd <defunct>：
?
1、什么是httpd <defunct>
defunct进程实际上是‘zombies’进程（top里查看到标记为‘Z’的进程）。
当一个进程执行完毕、结束后，需要其父进程来读取自己的状态，才能完全结束，这期间，如果父进程一直没有来读取状态，那么这个执行完毕的进程会一直在进程表中占据一个条目，这个时候的进程就是 'defunct' 进程。
?
更多的内容介绍可以查看：http://en.wikipedia.org/wiki/Zombie_process
?
?
2、为什么会产生httpd <defunct>进程
?
? ? 默认情况下，apache的设置是：一个工作进程执行完指定数目的请求后，主进程会结束掉这个工作进程。这样设计是为了不至于内存泄漏，从而导致失控。
? ? 第一种情况：像前面所说的，apache的主进程会对“寿终正寝”的工作进程进行回收。然而当服务器负载（load）很高时，apache的主进程可能没有空闲的时间去执行这一步回收工作。从而导致这些没有回收的“寿终正寝”的工作进程以‘defunct’的姿态出现在top命令里。在这种情况下出现‘defunct’进程是不用太担心的，除非有超大量的‘defunct’进程。
?
? ? 另一种可能的情况是：工作进程异常退出导致的，异常退出的原因可能有很多，比如web应用的代码里有bug，或者web应用的引擎有bug。这种情况，可以通过查看apache的error_log日志来查看，查找是否有严重的错误日志打印出来。
?
我碰到的情况都不是上面两种，所以我又查了更多的资料，比如这个：
?
BiGWill 写道（链接：点击这里）
Thanks all for your help....
I finally nailed it down to the access_log which was 2GB big, which is the limit of the file
system!
Guess i should implement some logrotation :D
Thanks everyone for their suggestions/help!
regards,
?
他说的是日志文件达到2G的上限，导致出现httpd <defunct> 进程，我这里使用的是cronolog来按天切割日志，每个日志文件才几十M，所以这个也不是想要的。
?
再比如这个：
?
gulaizi?写道（链接在这里：点击跳转）
问题的原因不会apache的问题，而是php
版本的兼容性问题。
介于这个问题，我开始察看PHP问题，终于
发现是php我安装了mmcahe，而且mmcache已经很久之前就停止开发了，对linux x86-64有兼容性问题。去掉mmcache，问题解决。
?
还有这个同学的描述：点击这里
?
都不符合我机器上的环境，所以我索性重启了一下apache，然后问题就解决了，很匪夷所思。原因依然待查……
?
最后，贴一段对系统管理员有用的，对“defunct”进程本质的解释：
?
来源：Yahoo Answers
The below explains what <defunct> means. If you aren't a Unix system administrator, this may not be of interest to you.
Normally, when a process exits (normally or abnormally), it enters a state known as “zombie” (which in top appears as Z). Its process ID stays in the process table until its parent waits on (or “reaps”) it. Under normal circumstances, when the parent process fully expects its child processes to exit, it sets up a signal handler for SIGCHLD so that, when the signal is sent (upon a child process's exit), the parent process then reaps it at its convenience.
If the parent process
has hung for some reason, such as if it's suspended, or is too busy, or is deadlocked, then child processes that exit will not be reaped (until the parent process resumes again). This
can cause serious problems if there are
many child processes, occupying slots in the process table that will not be freed.
In that case, one solution (if the parent process is unrecoverable, say), is to kill the parent process. Then, the child processes will be reparented to the init process (process ID 1), which will reap them. (If the init process is stalled, then you have much, much bigger problems than child processes not being reaped. In fact, a crashed init process will usually cause a kernel panic.)
?
-----EOF------
相关文章
