一个杀不死的小强,kill进程无效的原因 记录故障排查过程中kill进程无效的分析过程
Posted 黄海的编程知识世界
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一个杀不死的小强,kill进程无效的原因 记录故障排查过程中kill进程无效的分析过程相关的知识,希望对你有一定的参考价值。
今天在处理一个机器异常负载(1000+)的问题,碰到了一个从未碰到过的情况,遇到了一个异常顽固的分子。我使用了所能想到的所有杀进程的方法,却始终无法干掉这个顽固分子,最后终于在谷歌大神的指引下,干掉了这个令我郁闷至极的顽固分子。
1.问题描述:
系统:内核 2.6.32.43
机器:web A web+NFS B
机器负载超高,但是却可以正常登录,响应也很快
分析过程:
1.通过top查看,发现CPU和内存都正常,swap使用过大
A机器:/usr/local # toptop - 11:01:29 up 1051 days, 16:55, 3 users, load average: 1694.36, 1694.26, 1679.68Tasks: 5367 total, 1 running, 5366 sleeping, 0 stopped, 0 zombie Cpu(s): 9.1%us, 19.6%sy, 0.0%ni, 50.0%id, 21.3%wa, 0.0%hi, 0.1%si, 0.0%stMem: 8049196k total, 7985004k used, 64192k free, 4080k buffers Swap: 2104504k total, 2067308k used, 37196k free, 3381972k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1896 root 20 0 16840 15m 468 S 6 0.2 95:41.71 sap1002 9393 root 20 0 268m 4572 252 S 6 0.1 3650:16 newoctopusd 27609 root 20 0 9648 5300 876 R 4 0.1 0:00.55 top 13737 root 20 0 61072 58m 58m S 1 0.7 0:02.77 sqm_agent
2.free -m查看磁盘使用情况,主要是为了看swap的使用情况
A机器:/usr/local # free -m total used free shared buffers cached Mem: 7860 6611 1249 0 10 2134-/+ buffers/cache: 4466 3394 Swap: 2055 2045 10
3.揪出罪魁祸首 top +f+p,通过swap栏找出使用swap最多的程序,每个httpd使用4M,好像也不多嘛。
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND 5135 root 20 0 266m 788 432 S 6 0.0 0:26.68 265m newoctopusd 5082 root 20 0 61072 58m 58m S 1 0.7 0:02.62 1276 sqm_agent 16796 root 20 0 5796 1484 880 R 1 0.0 0:00.09 4312 top 5186 root 20 0 30616 21m 472 S 0 0.3 0:01.21 9112 dnsagent 5831 root 20 0 5288 2060 1320 S 0 0.0 0:00.06 3228 sshd 1 root 20 0 788 304 256 S 0 0.0 0:29.38 484 init 2 root 20 0 0 0 0 S 0 0.0 0:00.00 0 kthreadd
4.由于机器是从其他部门转交过来的,所以想当然认为httpd没啥问题,不过还是随手一个命令,然后就惊呆了,502个进程。
ps axu |grep http|wc -l
502
这是要闹哪样啊,有这么启动进程的?
5. 于是自信满满的killall httpd,/usr/local/apache2/bin/apachectl -k start等着释放资源,发现启动失败,端口占用。
于是查看httpd进程,发现有一个顽固分子残留,好吧,干脆点,killall -9 httpd,/usr/local/apache2/bin/apachectl -k start,加9了不信还有问题,结果可是依旧端口占用。
ps -ef |grep http nobody 16295 1 0 Nov24 ? 00:00:08 /usr/local/httpd-2.2.19/bin/httpd -k start root 29211 3398 0 11:02 pts/3 00:00:00 grep http kill 16295 ps -ef |grep http nobody 16295 1 0 Nov24 ? 00:00:08 /usr/local/httpd-2.2.19/bin/httpd -k start root 29625 3398 0 11:02 pts/3 00:00:00 grep http kill -9 16295 ps -ef |grep http nobody 16295 1 0 Nov24 ? 00:00:08 /usr/local/httpd-2.2.19/bin/httpd -k start root 30112 3398 0 11:02 pts/3 00:00:00 grep http kill -TERM 16295 ps -ef |grep http nobody 16295 1 0 Nov24 ? 00:00:08 /usr/local/httpd-2.2.19/bin/httpd -k start root 30112 3398 0 11:03 pts/3 00:00:00 grep http
是不是有什么冤情呢?那就来查看下这个进程的状态,看看有何原因:
ps axopid,comm,wchan | grep 16295
16295 httpd nfs_wait_bit_uninterruptible
原来冤情在这里:谷歌了下,确认是2.6.33.1内核之前的一个NFS bug
nfs_wait_bit_uninterruptible:
https://bugzilla.kernel.org/show_bug.cgi?id=15552
验证:
机器磁盘情况:
A机器:/usr/local # df -hFilesystem Size Used Avail Use% Mounted on/dev/sda1 9.9G 1.8G 7.6G 20% /udev 3.9G 296K 3.9G 1% /dev/dev/sda3 20G 13G 6.4G 67% /usr/local/dev/sda4 103G 28G 70G 29% /data B机器:/xx/htdocs 103G 30G 68G 31% /xx/admin/htdocs
访问挂载的目录,无法访问,长时间无响应
访问远程NFS服务机器B,发现机器超高,基本失去响应了,于是重启机器。
重启B机器 NFS机器后发现,A机器这台机器负载也恢复了。
查看顽固分子16295,发现已经消失了。
root 18012 1 1 11:14 ? 00:00:01 /usr/local/httpd-2.2.19/bin/httpd -k startnobody 18168 18012 0 11:14 ? 00:00:00 /usr/local/httpd-2.2.19/bin/httpd -k startnobody 18169 18012 0 11:14 ? 00:00:00 /usr/local/httpd-2.2.19/bin/httpd -k startnobody 18171 18012 0 11:14 ? 00:00:00 /usr/local/httpd-2.2.19/bin/httpd -k startnobody 18173 18012 0 11:14 ? 00:00:00 /usr/local/httpd-2.2.19/bin/httpd -k startnobody 18175 18012 0 11:14 ? 00:00:00 /usr/local/httpd-2.2.19/bin/httpd -k start
以上是关于一个杀不死的小强,kill进程无效的原因 记录故障排查过程中kill进程无效的分析过程的主要内容,如果未能解决你的问题,请参考以下文章