您的位置:首页 > 其它

「杀不掉的」僵尸(zombie)进程

2017-09-10 22:38 246 查看
「杀不掉的」僵尸(zombie)进程

淘仇恕(张云开)

感谢淘宝内核组的帮助,Google
Drive原文


Linux的进程,有以下几种状态(摘自本文):

State
Description
D
Uninterruptible sleep (usually IO)
R
Running or runnable (on run queue)
S
Interruptible sleep (waiting for an event to complete)
T
Stopped, either by a job control signal or because it is being traced.
W
Paging (not valid since the 2.6.xx kernel)
X
Dead (should never be seen)
Z
Defunct ("zombie") process, terminated but not reaped by its parent.
当一个进程处于Z状态,我们称之为zombie进程,如下所示:

#top-b-p56249

 PID USER      PR  NI  VIRT  RES  SHR S %CPU%MEM
   TIME+
 COMMAND                                                                                          
56249
ats       20
  0
    0
   0
   0
Z  0.0
 0.0
  5914:36
[ET_NET 0]
<defunct>
正常情况下,处于zombie状态的进程,会很快地被它的父进程回收,以致于我们根本不会注意到zombie进程的存在。可在实践过程中,却有一些无法使用kill -9命令杀掉的zombie进程,这常常令我们束手无策。

如果某个进程一直处于zombie状态,可能会带来一些严重的问题,例如,假设这个进程没有正确地close掉socket,就会导致这些socket处于close_wait状态,这些socket将会占用系统的ip/port资源,将导致其他程序无法创建特定socket。

当出现「杀不掉」的zombie进程,我们常常归咎于kernel的bug,不了了之,但其实还有一种情况常常被忽略。让我们看看上面的这个zombie进程内部,是否还有其他线程(使用top命令的-H参数):

#top-b-H-p56249

PID USER      PR  NI  VIRT  RES  SHR S %CPU%MEM
   TIME+
 COMMAND                                                                                         
56249
ats       20
  0
    0
   0
   0
Z  0.0
 0.0253:54.05
[ET_NET 0]
<defunct>                                                                            
56337
ats       20
  0
    0
   0
   0
D  0.0
 0.0
 38:53.67
[ET_AIO 0]
                                                                                     
56338
ats       20
  0
    0
   0
   0
D  0.0
 0.0
 38:48.24
[ET_AIO 1]
                                                                                                                                                                      
由上图可见,虽然[ET_NET
0](pid=56249)进程处于zombie状态,但它其实是一个多线程的程序,该程序中的其他线程,如[ET_AIO 0](pid=56337)等,处于D(Uninterruptible
sleep)状态,因为D状态的进程(在Linux中,线程只是特殊的进程)无法被中断,因此kill -9无法杀掉D状态的进程。也正因为这些D状态的进程的存在,导致父进程无法顺利的回收它们。

通常,我们还需要分析处于D状态的进程卡在了哪里。可通过/proc文件系统查看D状态进程的调用栈:

#cat/proc/56337/stack

[<ffffffff811b372e>] __blockdev_direct_IO_newtrunc+0x6fe/0xb90

[<ffffffff811b3c1e>] __blockdev_direct_IO+0x5e/0xd0

[<ffffffff811b1317>] blkdev_direct_IO+0x57/0x60

[<ffffffff81113543>] generic_file_aio_read+0x793/0x870

[<ffffffff81177c3a>] do_sync_read+0xfa/0x140

[<ffffffff81178635>] vfs_read+0xb5/0x1a0

[<ffffffff81178962>] sys_pread64+0x82/0xa0

[<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b

[<ffffffffffffffff>] 0xffffffffffffffff
由上图可见,该进程卡在了磁盘的read操作中,很可能是磁盘坏了。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: