伺服器程序異常的原因分析(第二篇)(r8筆記第16天)
最近看到一個報警，是顯示某一個oracle的備庫程序數達到了2000多個。 ZABBIX-監控系統: ------------------------------------ 報警內容: Too many OS processes on [email protected] ------------------------------------ 報警級別: 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
# 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 ...>[@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對映。