關於httpd 進程的簡略理解

今天無意中查看到了一個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------