Linux 性能分析调优 (四)——案例篇:系统中出现大量不可中断进程和僵尸进程怎么办

之前讲到 CPU 使用率的类型。除了上一节提到的用户 CPU 之外,它还包括系统 CPU(比如上下文切换)、等待 I/O 的 CPU(比如等待磁盘的响应)以及中断 CPU(包括软中断和硬中断)等。

在上下文切换的文章中,一起分析了系统 CPU 使用率高的问题,剩下的等待 I/O的 CPU 使用率(以下简称为 iowait)升高,也是最常见的一个服务器性能问题。今天我们就来看一个多进程 I/O 的案例,并分析这种情况。

目录:

进程状态

案例分析

小结

进程状态

当 iowait 升高时,进程很可能因为得不到硬件的响应,而长时间处于不可中断状态。从ps 或者 top 命令的输出中,你可以发现它们都处于 D 状态,也就是不可中断状态
(Uninterruptible Sleep)。既然说到了进程的状态,进程有哪些状态你还记得吗?我们先来回顾一下。


top 和 ps 是最常用的查看进程状态的工具,我们就从 top 的输出开始。下面是一个 top命令输出的示例,S 列(也就是 Status 列)表示进程的状态。从这个示例里,你可以看到R、D、Z、S、I 等几个状态,它们分别是什么意思呢?

Tasks: 102 total,   1 running, 101 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.3%us,  0.4%sy,  0.0%ni, 98.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2054084k total,  1851980k used,   202104k free,   151392k buffers
Swap:        0k total,        0k used,        0k free,   892636k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                      
 1178 root      10 -10  133m  17m 5700 R  0.8  0.9 231:49.51 AliYunDun                                                                                     
32028 root      20   0 15020 1312 1008 D  0.8  0.1   0:00.03 top                                                                                           
 2009 root      20   0 79712 2220 1728 Z  0.4  0.1  10:12.22 aliyun-service                                                                                
32580 root      20   0 2428m 280m  11m S  0.4 14.0  14:55.67 java                                                                                          
    1 root      20   0 19232 1216  932 I  0.0  0.1   0:00.88 init                                                                                          
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.03 kthreadd                                                                                      
    3 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0                                                                                   
    4 root      20   0     0    0    0 S  0.0  0.0   0:04.18 ksoftirqd/0                                                                                   
    5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 stopper/0                                                                                     
    6 root      RT   0     0    0    0 S  0.0  0.0   0:03.88 watchdog/0                                                                                    
    7 root      20   0     0    0    0 S  0.0  0.0   3:21.25 events/0                                                                                      
    8 root      20   0     0    0    0 S  0.0  0.0   0:00.00 events/0     

我们挨个来看一下:

  1. R 是 Running 或 Runnable 的缩写,表示进程在 CPU 的就绪队列中,正在运行或者正在等待运行。
  2. D 是 Disk Sleep 的缩写,也就是不可中断状态睡眠(Uninterruptible Sleep),一般表示进程正在跟硬件交互,并且交互过程不允许被其他进程或中断打断。
  3. Z 是 Zombie 的缩写,如果你玩过“植物大战僵尸”这款游戏,应该知道它的意思。它表示僵尸进程,也就是进程实际上已经结束了,但是父进程还没有回收它的资源(比如进程的描述符、PID 等)。
  4. S 是 Interruptible Sleep 的缩写,也就是可中断状态睡眠,表示进程因为等待某个事件而被系统挂起。当进程等待的事件发生时,它会被唤醒并进入 R 状态。
  5. I 是 Idle 的缩写,也就是空闲状态,用在不可中断睡眠的内核线程上。前面说了,硬件交互导致的不可中断进程用 D 表示,但对某些内核线程来说,它们有可能实际上并没有任何负载,用 Idle 正是为了区分这种情况。要注意,D 状态的进程会导致平均负载升高, I 状态的进程却不会。

当然了,上面的示例并没有包括进程的所有状态。除了以上 5 个状态,进程还包括下面这2 个状态。
第一个是 T 或者 t,也就是 Stopped 或 Traced 的缩写,表示进程处于暂停或者跟踪状态。
向一个进程发送 SIGSTOP 信号,它就会因响应这个信号变成暂停状态(Stopped);再向它发送 SIGCONT 信号,进程又会恢复运行(如果进程是终端里直接启动的,则需要你用 fg 命令,恢复到前台运行)。
而当你用调试器(如 gdb)调试一个进程时,在使用断点中断进程后,进程就会变成跟踪状态,这其实也是一种特殊的暂停状态,只不过你可以用调试器来跟踪并按需要控制进程的运行。
另一个是 X,也就是 Dead 的缩写,表示进程已经消亡,所以你不会在 top 或者 ps 命令中看到它。
了解了这些,我们再回到今天的主题。先看不可中断状态,这其实是为了保证进程数据与硬件状态一致,并且正常情况下,不可中断状态在很短时间内就会结束。所以,短时的不可中断状态进程,我们一般可以忽略。
但如果系统或硬件发生了故障,进程可能会在不可中断状态保持很久,甚至导致系统中出现大量不可中断进程。这时,你就得注意下,系统是不是出现了 I/O 等性能问题。
再看僵尸进程,这是多进程应用很容易碰到的问题。正常情况下,当一个进程创建了子进程后,它应该通过系统调用 wait() 或者 waitpid() 等待子进程结束,回收子进程的资源

而子进程在结束时,会向它的父进程发送 SIGCHLD 信号,所以,父进程还可以注册SIGCHLD 信号的处理函数,异步回收资源。
如果父进程没这么做,或是子进程执行太快,父进程还没来得及处理子进程状态,子进程就已经提前退出,那这时的子进程就会变成僵尸进程。换句话说,父亲应该一直对儿子负责,善始善终,如果不作为或者跟不上,都会导致“问题少年”的出现。
通常,僵尸进程持续的时间都比较短,在父进程回收它的资源后就会消亡;或者在父进程退出后,由 init 进程回收后也会消亡。
一旦父进程没有处理子进程的终止,还一直保持运行状态,那么子进程就会一直处于僵尸状态。大量的僵尸进程会用尽 PID 进程号,导致新进程不能创建,所以这种情况一定要避免。

案例分析

接下来,我将用一个多进程应用的案例,带你分析大量不可中断状态和僵尸状态进程的问题。这个应用基于 C 开发,由于它的编译和运行步骤比较麻烦,我把它打包成了一个 Docker 镜像。这样,你只需要运行一个 Docker 容器就可以得到模拟环境。运行案例:

docker run --privileged --name=app -itd feisky/app:iowait

然后,输入 ps 命令,确认案例应用已正常启动。如果一切正常,你应该可以看到如下所示的输出:

$ ps aux | grep /app
root    4009  0.0  0.0   4376   1008   pts/0    Ss+  05:51   0:00 /app
root    4287  0.6  0.4   37280 33660   pts/0    D+   05:54   0:00 /app
root    4288  0.6  0.4   37280 33668   pts/0    D+   05:54   0:00 /app

从这个界面,我们可以发现多个 app 进程已经启动,并且它们的状态分别是 Ss+ 和D+。
其中,S 表示可中断睡眠状态,D 表示不可中断睡眠状态,我们在前面刚学过,那后面的 s 和 + 是什么意思呢?不知道也没关系,查一下 man ps 就可以。现在记住,s 表示这个进程是一个会话的领导进程,而 + 表示前台进程组。
这里又出现了两个新概念,进程组和会话。它们用来管理一组相互关联的进程,意思其实很好理解。

进程组表示一组相互关联的进程,比如每个子进程都是父进程所在组的成员;而会话是指共享同一个控制终端的一个或多个进程组。

比如,我们通过 SSH 登录服务器,就会打开一个控制终端(TTY),这个控制终端就对应一个会话。而我们在终端中运行的命令以及它们的子进程,就构成了一个个的进程组,其中,在后台运行的命令,构成后台进程组;在前台运行的命令,构成前台进程组。

明白了这些,我们再用 top 看一下系统的资源使用情况:

# 按下数字 1 切换到所有 CPU 的使用情况,观察一会儿按 Ctrl+C 结束
$ top
top - 05:56:23 up 17 days, 16:45,  2 users,  load average: 2.00, 1.68, 1.39 Tasks: 247 total,   1 running,  79 sleeping,   0 stopped, 115 zombie
%Cpu0  :  0.0 us,  0.7 sy,  0.0 ni, 38.9 id, 60.5 wa,  0.0 hi,  0.0 si,  0.0 st%Cpu1  :  0.0 us,  0.7 sy,  0.0 ni,  4.7 id, 94.6 wa,  0.0 hi,  0.0 si,  0.0 st ...

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                      1 root      20   0 19232 1216  932 S  0.0  0.1   0:00.88 init                                                                                          
    2 root      20   0 3728033624  860 D  0.3  0.0   0:00.03 app                                                                                      
    3 root      20   0 3728033624  860 D  0.3  0.04   0:00.00 app                                                                                   
    4 root      20   0     0    0    0 S  0.0  0.0   0:04.19 systemd                                                                                     

从这里你能看出什么问题吗?细心一点,逐行观察,别放过任何一个地方。忘了哪行参数意思的话,也要及时返回去复习。
好的,如果你已经有了答案,那就继续往下走,看看跟我找的问题是否一样。这里,我发现了四个可疑的地方。

先看第一行的平均负载( Load Average),过去 1 分钟、5 分钟和 15 分钟内的平均负载在依次减小,说明平均负载正在升高;而 1 分钟内的平均负载已经达到系统的 CPU个数,说明系统很可能已经有了性能瓶颈。
再看第二行的 Tasks,有 1 个正在运行的进程,但僵尸进程比较多,而且还在不停增加,说明有子进程在退出时没被清理。
接下来看两个 CPU 的使用率情况,用户 CPU 和系统 CPU 都不高,但 iowait 分别是60.5% 和 94.6%,好像有点儿不正常。
最后再看每个进程的情况, CPU 使用率最高的进程只有 0.3%,看起来并不高;但有两个进程处于 D 状态,它们可能在等待 I/O,但光凭这里并不能确定是它们导致了 iowait升高。

我们把这四个问题再汇总一下,就可以得到很明确的两点:

  • 第一点,iowait 太高了,导致系统的平均负载升高,甚至达到了系统 CPU 的个数。
  • 第二点,僵尸进程在不断增多,说明有程序没能正确清理子进程的资源。

那么,碰到这两个问题该怎么办呢?

小结

主要通过简单的操作,熟悉了几个必备的进程状态。用我们最熟悉的 ps 或者top ,可以查看进程的状态,这些状态包括运行(R)、空闲(I)、不可中断睡眠(D)、可中断睡眠(S)、僵尸(Z)以及暂停(T)等。
其中,不可中断状态和僵尸状态,是我们今天学习的重点。

  • 不可中断状态,表示进程正在跟硬件交互,为了保护进程数据和硬件的一致性,系统不允许其他进程或中断打断这个进程。进程长时间处于不可中断状态,通常表示系统有I/O 性能问题。
  • 僵尸进程表示进程已经退出,但它的父进程还没有回收子进程占用的资源。短暂的僵尸状态我们通常不必理会,但进程长时间处于僵尸状态,就应该注意了,可能有应用程序没有正常处理子进程的退出。
原文地址:https://www.cnblogs.com/xiaowenshu/p/10477591.html