系统性能之cpu 篇（四）

原创

江南辉哥 2023-02-15 18:02:28 博主文章分类：性能 ©著作权

©著作权归作者所有：来自51CTO博客作者江南辉哥的原创作品，请联系作者获取转载授权，否则将追究法律责任

1.进程的几种状态

$ top
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
28961 root      20   0   43816   3148   4040 R   3.2  0.0   0:00.01 top
  620 root      20   0   37280  33676    908 D   0.3  0.4   0:00.01 app
    1 root      20   0  160072   9416   6752 S   0.0  0.1   0:37.64 systemd
 1896 root      20   0       0      0      0 Z   0.0  0.0   0:00.00 devapp
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.10 kthreadd
    4 root       0 -20       0      0      0 I   0.0  0.0   0:00.00 kworker/0:0H
    6 root       0 -20       0      0      0 I   0.0  0.0   0:00.00 mm_percpu_wq
    7 root      20   0       0      0      0 S   0.0  0.0   0:06.37 ksoftirqd/0

S列即表示进程的状态，分别有以下几种：

R 是 Running 或 Runnable 的缩写，表示进程在 CPU 的就绪队列中，正在运行或者正在等待运行。
D 是 Disk Sleep 的缩写，也就是不可中断状态睡眠（Uninterruptible Sleep），一般表示进程正在跟硬件交互，并且交互过程不允许被其他进程或中断打断。如果进程中出现大量的不可中断进程，得注意下，系统可能出现I/O性能问题，同时会造成cpu %wait 高，继而造成cpu使用率高。
Z 是 Zombie 的缩写它表示僵尸进程，也就是进程实际上已经结束了，但是父进程还没有回收它的资源（比如进程的描述符、PID 等）。正常情况下，即当一个进程创建子进程后，通过系统调用wait()或者waitpid()等待子进程结束，回收子进程资源；而子进程结束时，会向父进程发送SIGCHLD信号；父进程还可以注册 SIGCHLD 信号的处理函数，异步回收资源。如果父进程没这么做，或是子进程执行太快，父进程还没来得及处理子进程状态，子进程就已经提前退出，那这时的子进程就会变成僵尸进程。
S 是 Interruptible Sleep 的缩写，也就是可中断状态睡眠，表示进程因为等待某个事件而被系统挂起。当进程等待的事件发生时，它会被唤醒并进入 R 状态。
I 是 Idle 的缩写，也就是空闲状态，用在不可中断睡眠的内核线程上。前面说了，硬件交互导致的不可中断进程用 D 表示，但对某些内核线程来说，它们有可能实际上并没有任何负载，用 Idle 正是为了区分这种情况。要注意，D 状态的进程会导致平均负载升高， I 状态的进程却不会。
T或者t，表示进程处于暂停或者跟踪状态。向一个进程发送 SIGSTOP 信号，它就会因响应这个信号变成暂停状态（Stopped）；再向它发送 SIGCONT 信号，进程又会恢复运行（如果进程是终端里直接启动的，则需要你用 fg 命令，恢复到前台运行）。
X 表示进程已经消亡。top看不到这种状态。

2.不可中断进程及僵尸进程案例分析

运行命令

$ docker run --privileged --name=app -itd feisky/app:iowait
$ 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表示这个进程是一个会话的领导进程，而 + 表示前台进程组。

通过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
4340 root      20   0   44676   4048   3432 R   0.3  0.0   0:00.05 top
4345 root      20   0   37280  33624    860 D   0.3  0.0   0:00.01 app
4344 root      20   0   37280  33624    860 D   0.3  0.4   0:00.01 app
1 root      20   0  160072   9416   6752 S   0.0  0.1   0:38.59 systemd
...

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

结合上文的问题，继续分析。。。。

2.1 iowait分析

终端运行dstat 命令，观察cpu和i/o使用情况

间隔1秒输出10组数据
$ dstat 1 10
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw
0   0  96   4   0|1219k  408k|   0     0 |   0     0 |  42   885
0   0   2  98   0|  34M    0 | 198B  790B|   0     0 |  42   138
0   0   0 100   0|  34M    0 |  66B  342B|   0     0 |  42   135
0   0  84  16   0|5633k    0 |  66B  342B|   0     0 |  52   177
0   3  39  58   0|  22M    0 |  66B  342B|   0     0 |  43   144
0   0   0 100   0|  34M    0 | 200B  450B|   0     0 |  46   147
0   0   2  98   0|  34M    0 |  66B  342B|   0     0 |  45   134
0   0   0 100   0|  34M    0 |  66B  342B|   0     0 |  39   131
0   0  83  17   0|5633k    0 |  66B  342B|   0     0 |  46   168
0   3  39  59   0|  22M    0 |  66B  342B|   0     0 |  37   134

从 dstat 的输出，我们可以看到，每当 iowait 升高（wai）时，磁盘的读请求（read）都会很大。这说明 iowait 的升高跟磁盘的读请求有关，很可能就是磁盘读导致的。

具体的是哪个进程在读磁盘呢？从上文top命令看出是app进程。通过pidstat命令再次确认是不是此进程，可以看出确实app进程磁盘读为32M/s 。

-d 展示 I/O 统计数据，间隔 1 秒输出 20 组数据
$ pidstat -d 1 20 
...
06:48:46      UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s iodelay  Command
06:48:47        0      4615      0.00      0.00      0.00       1  kworker/u4:1
06:48:47        0      6080  32768.00      0.00      0.00     170  app
06:48:47        0      6081  32768.00      0.00      0.00     184  app
...

进程app具体在执行什么呢？通过strace 可以跟踪进程系统调用。发现没有权限，看下是否存在6082进程呢？通过ps 看出该进程变为了僵尸进程。

$ strace -p 6082
strace: attach: ptrace(PTRACE_SEIZE, 6082): Operation not permitted


$ ps aux | grep 6082
root      6082  0.0  0.0      0     0 pts/0    Z+   13:43   0:00 [app] <defunct>

有没有其他方式找到具体是哪个函数在执行磁盘读请求吗？参考"系统性能之cpu篇（三）"中关于perf record ，perf report 分析

系统性能之cpu 篇（四）_内核线程

从 new_sync_read 和 blkdev_direct_IO 能看出，进程正在对磁盘进行直接读，也就是绕过了系统缓存，每个读请求都会从磁盘直接读，这就可以解释我们观察到的 iowait 升高了。接下来就可以交给研发人员分析代码层了。

2.2 僵尸进程分析

回顾下，僵尸进程的产生是因为父进程没有回收子进程的资源而出现。解决思路就是找到父进程进而解决。父进程为app应用4009.

-a 表示输出命令行选项
p表PID
s表示指定进程的父进程
$ pstree -aps 3084
systemd,1
└─dockerd,15006 -H fd://
└─docker-containe,15024 --config /var/run/docker/containerd/containerd.toml
└─docker-containe,3991 -namespace moby -workdir...
└─app,4009
└─(app,3084)

接下来还得分析应用代码，看看子进程处理是否正确。即父进程有没有调用wait()或者waitpid();或者是有没有注册 SIGCHLD 信号的处理函数。