mysql进程 kill杀不死_一个杀不死的小强，kill进程无效的原因

一个杀不死的小强，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 1629516295  httpd nfs_wait_bit_uninterruptible

原来冤情在这里：谷歌了下，确认是2.6.33.1内核之前的一个NFS bug

验证：

机器磁盘情况：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