crontab設定導致的伺服器程式異常問題

jeanron100發表於2016-08-27

前幾天的時候,有個同事問我一個問題,大體的意思是突然收到報警,伺服器的程式數翻了好幾倍,其實那個伺服器也沒有任何操作。所以想讓我幫忙看看。
他自己也做了一些簡單的分析,可以看出,裡面含有大量的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分鐘一次迴圈呼叫,所以修復了問題以後,檔案的生成頻率大大降低。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-2124115/,如需轉載,請註明出處,否則將追究法律責任。

相關文章