伺服器程式異常的原因分析(第二篇)

最近看到一個報警，是顯示某一個oracle的備庫程式數達到了2000多個。
ZABBIX-監控系統:

------------------------------------
報警內容: Too many OS processes on ora_xxx@10.127.13.123
------------------------------------
報警級別: PROBLEM
------------------------------------
監控專案: Number of processes：2003
------------------------------------
報警時間:2015.12.13-00:10:12

對於這個問題可以這麼理解，這臺伺服器上只有一個Oracle備庫例項，而且這個備庫的業務量也其實不大，不到一百個。而現在程式有2000多個，哪裡會消費這麼多的程式資源呢，一個設想就是一些額外的系統級指令碼執行導致，當然這個也是有前車之鑑。可以參考 伺服器程式異常的原因分析 http://blog.itpub.net/23718752/viewspace-1812698/
但是問題也不總是一個模子裡刻出來的，問題的原因也是千變萬化。
對於這個問題，也是帶著一絲的僥倖，首先登陸到伺服器端。發現了下面的伺服器情況。
top - 22:44:23 up 829 days,  1:35,  3 users,  load average: 0.00, 0.03, 0.00
Tasks: 2075 total,   1 running, 1889 sleeping,   0 stopped, 185 zombie
Cpu(s):  0.1% us,  0.1% sy,  0.0% ni, 99.1% id,  0.7% wa,  0.0% hi,  0.0% si
Mem:  16425208k total, 16371888k used,    53320k free,   389780k buffers
Swap:  8385920k total,   449736k used,  7936184k free, 12533064k cached
目前的伺服器程式有2000多個，而且io等待也不高。1889個在sleep,185個殭屍程式，所以還是有什麼特別的問題。
大概翻了幾頁程式資訊，就發現CROND和一個sh執行指令碼的程式有很多。
#  ps -ef|grep -i CROND|wc -l
449
# ps -ef|grep sh |wc -l
723
所以通過這些也能夠大概看出來，應該是一個crontab的job相關的問題。
看一看磁碟的使用情況，df -h看看發現會卡住沒有反應，那麼問題似乎就是這兒了。
怎麼知道df -h的時候命令卡在哪裡呢？ 可以簡單使用strace測試一下。
#strace df -h
statfs("/tmp", {f_type=0x1021994, f_bsize=4096, f_blocks=2053151, f_bfree=1992224, f_bavail=1992224, f_files=2053151, f_ffree=2052612, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
write(1, "/dev/shm              7.9G  238M"..., 49/dev/shm              7.9G  238M  7.6G   3% /tmp
) = 49
statfs("/proc/sys/fs/binfmt_misc", {f_type=0x42494e4d, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
statfs("/var/lib/nfs/rpc_pipefs", {f_type=0x67596969, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096}) = 0
statfs("/home/oracle/backup_stage",  <unfinished ...>
可以發現執行的結果可以看出來，最後是卡在了/home/oracle/backup_stage這一步上了。如果是明眼人可能已經猜出來緣由了。
看一下掛載點的資訊：
[@actvnew.cyou.com oracle]# mount
/dev/sda1 on / type ext3 (rw)
。。。
/dev/shm on /tmp type none (rw,bind)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
10.11.148.174:/backup/10.127.xxxx.xxx_xxxx on /home/oracle/backup_stage type nfs (rw,bg,hard,intr,nolock,tcp,rsize=32768,wsize=32768,addr=10.11.148.174)
可以看到這個路徑其實是使用了nfs的方式掛載的。
但是檢視/etc/fstab的時候，發現已經註釋了原來的掛載點資訊
$ cat /etc/fstab
。。。
/dev/shm                /tmp                    none    rw,bind         0 0
#10.11.148.174:/backup/10.127.xxxx.xxxx_xxxx /home/oracle/backup_stage nfs rw,bg,soft,intr,nolock,tcp,rsize=32768,wsize=32768 0 0
從這個資訊可以看似，之前的維護人員似乎意識到了這個掛載點失效了，直接給註釋了。
但是實際上呢。檢視/etc/mtab發現這個配置還在那裡。
$ cat /etc/mtab
/dev/sda1 / ext3 rw 0 0
...
10.11.148.174:/backup/10.127.xxxx.xxx_xxx /home/oracle/backup_stage nfs rw,bg,hard,intr,nolock,tcp,rsize=32768,wsize=32768,addr=10.11.148.174 0 0
所以可以基本明確，這個是由nfs失效導致的一個問題。那麼我們直接取消掛載好了。
# umount -f /home/oracle/backup_stage
umount2: Device or resource busy
umount: /home/oracle/backup_stage: device is busy
umount2: Device or resource busy
umount: /home/oracle/backup_stage: device is busy
強制也不行。
#umount -f /home/oracle/backup_stage
umount2: Device or resource busy
umount: /home/oracle/backup_stage: device is busy
而且進一步發現到了/home/oracle目錄下，使用ls -l也會直接卡住。當然strace一下，發現還是由於這個/home/oracle/backup_stage導致的問題。
所以可以先初步解決問題，循序漸進，把問題的影響先降下來再除根。
所以清理了部分的程式情況，發現還有相當一部分的程式是由於rman相關的兩個指令碼導致的。而在這兩個指令碼中間接使用ll和mkdir -p的操作。
oracle     359   337  0  2015 ?        00:00:00 /bin/bash /home/oracle/dbadmin/scripts/rmanbak_stby.sh
oracle     577   575  0  2015 ?        00:00:00 /bin/sh -c . $HOME/.actvdbprofile;$HOME/dbadmin/scripts/rmanbak_stby.sh
對於NFS掛載點失效的情況下，簡直就是災難。所以簡單使用awk命令生成批量的命令來清理
比如刪除殭屍程式，可以採用下面的方式
# ps -ef|grep "defunct"|awk '{print "kill -9 " $2}'> kill_defunct.lst
清理之後，程式數馬上降了下來。效果還是非常顯著的。

然後進一步處理。關鍵就是使用fuser來清理相關的程式
# umount /home/oracle/backup_stage
umount: /home/oracle/backup_stage: device is busy
# umount -l /home/oracle/backup_stage
# umount -lf /home/oracle/backup_stage
umount: /home/oracle/backup_stage: not mounted
# fuser -k /home/oracle/backup_stage
# umount /home/oracle/backup_stage
umount: /home/oracle/backup_stage: not mounted
再次檢視這個問題就基本解決了。
df -h和ls -l都沒有問題了，當然後續還需要檢視crontab中對於這個路徑的引用，還是需要考慮重新制定或者重新建立新的nfs對映。

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