前幾天的時候，有個同事問我一個問題，大體的意思是突然收到報警，伺服器的程序數翻了好幾倍，其實那個伺服器也沒有任何操作。所以想讓我幫忙看看。 他自己也做了一些簡單的分析，可以看出，裡面含有大量的CRONTD程序，sendmail程序等，大概佔用了近4000的程序。 $ ps -ef|grep sendmail |wc -l 1317 $ ps -ef|grep postdrop|wc -l 1317 $ ps -ef|grep CROND|wc -l 1315

登入到伺服器，我簡單看了下，發現確實已經是4000多程序了。如果這是一個繁忙異常的OLTP業務可能會放鬆我的警惕，但是這是一個業務很少的備庫，突然就提高了警覺。 top命令的結果如下： top - 11:41:25 up 559 days, 16:52, 1 user, load average: 0.10, 0.10, 0.10 Tasks: 4288 total, 1 running, 4287 sleeping, 0 stopped, 0 zombie Cpu(s): 0.2%us, 0.1%sy, 0.0%ni, 99.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 32862536k total, 31871784k used, 990752k free, 629660k buffers Swap: 16777200k total, 0k used, 16777200k free, 16914428k cached

可以從以上資訊看到，一共4288的程序，4287在sleep狀態，伺服器負載也不高，iowait很低，CPU使用率也很低。 看起來一切太平啊。 檢視磁碟空間 df-h發現空間還富餘不少。所以這個問題就有些奇怪了。 我靜了靜，這個問題似乎之前碰到過類似的，那是因為存在NFS的掛載點失效導致CROND執行失敗，結果累計了大量的後臺程序。這次的環境問題似乎還有所不同。 檢視CROND的屬主，是root，但是檢視root下的crontab的設定，只有ntpdate同步時間的crontab 10 * * * * /usr/sbin/ntpdate -s xxxx ;/sbin/clock -w 10 * * * * /usr/sbin/ntpdate -s xxxx ;/sbin/clock -w 看這個crontab是每個小時的第10分鐘開始同步時間，應該不會有這麼大的影響。 當然在分析問題的時候，腦子裡也在飛快的搜尋著，突然想起很久以前是處理過一個類似的案例，而問題的根源就是Inode滿了。可以參見很久以前的一篇文章。http://blog.itpub.net/23718752/viewspace-1812698/ 這次的問題是否是同樣的原因呢，df -i檢視，發現竟然如出一轍，還是套路，原來就是Inode滿了。 這個時候我沒有急於去清理這些程序，而是打算先清理inode，在/var目錄下檢視在/var/spool/postfix/maildrop下面存在大量的檔案。 當然仔細查看了部分檔案之後，確認是可以刪除的，這個時候就得分批刪除，要不直接刪除肯定會丟擲控制代碼相關的錯誤來。 分批刪除大概持續了20多秒，刪除之後inode馬上就釋放了。 # time ls |xargs -n 10 rm real 0m22.791s user 0m2.053s sys 0m6.490s df -i的結果如下： Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda3 262144 3381 258763 2% /var 而再次使用top檢視，4000多的程序瞬間降了下來，只有不到400程序。 top - 12:04:54 up 559 days, 17:16, 3 users, load average: 0.16, 0.23, 0.17 Tasks: 328 total, 1 running, 327 sleeping, 0 stopped, 0 zombie Cpu(s): 0.1%us, 0.1%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 32862536k total, 28072444k used, 4790092k free, 638572k buffers Swap: 16777200k total, 0k used, 16777200k free, 16739416k cached 通過zabbix的監控圖我看到了如下的結果，這個圖剛開始看的時候還有些疑惑，以為這個問題已經持續了很就，但是如此來看，是一個爆發式的增長過程。 其實解釋明白就很容易理解了，我查看了系統的日誌，在問題發生的時間段，確實沒有其它的操作，而就是在某一個特定的時間，因為inode溢位導致sendmail,maildrop的程序阻塞， 結果大量的程序都堆積下來了。如此來看問題在釋放inode之後似乎是引刃而解了。

我查看了一下/var/spool/postfix/maildrop目錄下的檔案，發現了一個奇怪的情況。 -rwxr--r-- 1 root postdrop 641 Aug 27 23:10 CEADC52C -rwxr--r-- 1 root postdrop 497 Aug 27 23:10 CEB7352D -rwxr--r-- 1 root postdrop 516 Aug 27 23:10 E62A552E -rwxr--r-- 1 root postdrop 632 Aug 27 23:20 CCF8F530 -rwxr--r-- 1 root postdrop 506 Aug 27 23:20 CCDD852F -rwxr--r-- 1 root postdrop 516 Aug 27 23:20 E395C531 這個目錄下的檔案生成時間似乎有些問題，案例是每個小時生成一次，每次不應該是3個檔案。這個是什麼原因呢 ，經過一番排查，發現原來是另外一個配置在作怪。 配置資訊如下： # vi /etc/cron.d/ntpdate ################################################### */10 * * * * root (/usr/sbin/ntpdate xxxx;/sbin/clock -w) */10 * * * * root (/usr/sbin/ntpdate xxxx;/sbin/clock -w) */10 * * * * root (/usr/bin/rdate -s xxxx;/sbin/clock -w) 如此來看問題就很容易理解了，這樣導致了沒10分鐘一次迴圈呼叫，所以修復了問題以後，檔案的生成頻率大大降低。