摘要:
本文首先介绍了不可中断睡眠状态产生的原因，以及僵尸进程相关的概念，并通过一个简单的案例分析了cpu iowait 升高的 性能定位分析问题的场景。
不可中断睡眠状态
不可中断状态睡眠（Uninterruptible Sleep），一般表示进程正在跟硬件交互，并且交互过程不允许被其他进程或中断打断。
不可中断状态，其实是为了保证进程数据与硬件状态一致，并且正常情况下，不可中断状态在很短时间内就会结束。所以，短时的不可中断状态进程，一般可以忽略。
但如果系统或硬件发生了故障，进程可能会在不可中断状态保持很久，甚至导致系统中出现大量不可中断进程。此时就需要排查系统是不是出现了 I/O 等性能问题？
僵尸进程
正常情况下，当一个进程创建了子进程后，应该通过系统调用 wait() 或者 waitpid() 等待子进程结束，回收子进程的资源；而子进程在结束时，会向它的父进程发送 SIGCHLD 信号，所以，父进程还可以注册 SIGCHLD 信号的处理函数，异步回收资源。如果父进程没进行资源回收，或是子进程执行太快，父进程还没来得及处理子进程状态，子进程就已经提前退出，那这时的子进程就会变成僵尸进程。
正常，僵尸进程持续的时间都比较短，在父进程回收它的资源后就会消亡；或者在父进程退出后，由 init 进程回收后也会消亡。一旦父进程没有处理子进程的终止，还一直保持运行状态，那么子进程就会一直处于僵尸状态。
大量的僵尸进程会用尽 PID 进程号，导致新进程不能创建，所以这种情况一定要避免。
僵尸进程的问题相对容易排查：使用 pstree 找出父进程后，去查看父进程的代码，检查 wait() / waitpid() 的调用，或是 SIGCHLD 信号处理函数的注册就行了。
案例
yine@ubuntu:~$ ps -aux | grep app
root 425349 0.0 0.0 2488 460 ? Ss+ 22:30 0:00 /app
root 425385 7.1 0.0 0 0 ? Z+ 22:30 0:01 [app] <defunct>
root 425386 4.8 0.0 0 0 ? Z+ 22:30 0:00 [app] <defunct>
root 425388 26.6 0.0 0 0 ? Z+ 22:31 0:03 [app] <defunct>
root 425389 25.7 0.0 0 0 ? Z+ 22:31 0:03 [app] <defunct>
root 425390 21.5 3.2 68028 65708 ? R+ 22:31 0:01 /app
root 425391 12.8 3.2 68028 65708 ? R+ 22:31 0:01 /app
yine 425397 0.7 0.0 8900 732 pts/7 S+ 22:31 0:00 grep --color=auto app
root 425398 4.0 3.2 68028 65700 ? D+ 22:31 0:00 /app
root 425399 3.5 3.2 68028 65696 ? D+ 22:31 0:00 /app
s 表示这个进程是一个会话的领导进程，而 + 表示前台进程组。
进程组和会话。它们用来管理一组相互关联的进程，意思其实很好理解。
- 进程组表示一组相互关联的进程，比如每个子进程都是父进程所在组的成员；
- 而会话是指共享同一个控制终端的一个或多个进程组。
- top 观察平均负载
top - 22:41:36 up 3 min, 1 user, load average: 3.20, 1.32, 0.15
Tasks: 371 total, 1 running, 340 sleeping, 0 stopped, 30 zombie
平均负载正在升高，同时僵尸进程数量在增多， 同时各个cpu 的iowait 升高
- dstat 监控
dstat 1 20
You did not select any stats, using -cdngy by default.
--total-cpu-usage-- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read writ| recv send| in out | int csw
2 13 72 12 0| 744M 45k| 0 0 |1755B 10k|1269 1068
6 22 64 9 0|1218M 0 | 0 0 | 0 0 |1758 922
4 28 42 26 0|1593M 0 | 0 0 | 0 0 |2367 1275
5 31 35 30 0|1664M 0 | 129B 0 | 0 0 |2180 1018
6 27 39 28 0|1629M 0 | 0 70B| 0 0 |2391 961
0 1 99 0 0| 45M 0 | 0 0 | 0 0 | 329 468
4 21 56 19 0|1199M 0 | 0 0 | 0 0 |1796 1005
4 27 41 29 0|1643M 0 | 0 0 | 0 0 |2372 1138
5 31 33 31 0|1637M 0 | 120B 60B| 0 0 |2157 912
5 26 38 30 0|1670M 0 | 0 0 | 0 0 |2601 1028
0 0 100 0 0| 0 0 | 0 0 | 0 0 | 210 361
可发现 iowait 在升高的时候，磁盘读请求在升高。
- pidstat 找出磁盘读的进程 确定时app 进程在进行磁盘读
pidstat -d 1 10
Linux 5.4.0-54-generic (ubuntu) 12/07/2020 _x86_64_ (4 CPU)
10:56:18 PM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
10:56:19 PM 0 3217 -1.00 -1.00 -1.00 25 app
10:56:19 PM 0 3218 -1.00 -1.00 -1.00 35 app
10:56:19 PM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
10:56:20 PM 0 3217 -1.00 -1.00 -1.00 104 app
10:56:20 PM 0 3218 -1.00 -1.00 -1.00 82 app
10:56:20 PM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
10:56:21 PM 0 3217 -1.00 -1.00 -1.00 95 app
10:56:21 PM 0 3218 -1.00 -1.00 -1.00 106 app
10:56:21 PM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
10:56:22 PM 0 3217 -1.00 -1.00 -1.00 71 app
10:56:22 PM 0 3218 -1.00 -1.00 -1.00 83 app
10:56:22 PM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
10:56:23 PM 0 3217 -1.00 -1.00 -1.00 17 app
10:56:23 PM 0 3218 -1.00 -1.00 -1.00 19 app
10:56:23 PM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
10:56:24 PM 0 3219 -1.00 -1.00 -1.00 30 app
10:56:24 PM 0 3220 -1.00 -1.00 -1.00 39 app
10:56:24 PM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
10:56:25 PM 0 3219 -1.00 -1.00 -1.00 100 app
10:56:25 PM 0 3220 -1.00 -1.00 -1.00 85 app
4.perf 调用查看 app 调用链情况
发现有直接磁盘读的调用： blkdev_direct_IO
$ perf record -g
$ perf report
+ 8.86% 8.36% kworker/0:1H-kb [kernel.kallsyms] [k] mpt_put_msg_frame ▒
- 7.52% 0.00% app [kernel.kallsyms] [k] entry_SYSCALL_64_aft▒
entry_SYSCALL_64_after_hwframe ▒
- do_syscall_64 ▒
- 7.43% __x64_sys_read ▒
- ksys_read ▒
- 7.43% vfs_read ▒
- 7.43% __vfs_read ▒
new_sync_read ▒
blkdev_read_iter ▒
- generic_file_read_iter ▒
- 7.43% blkdev_direct_IO ▒
- 7.43% __blkdev_direct_IO ▒
+ 5.68% submit_bio ▒
+ 1.34% bio_iov_iter_get_pages ▒
+ 7.52% 0.00% app [kernel.kallsyms] [k] do_syscall_64 ▒
+ 7.52% 0.00% app libc-2.31.so [.] __libc_start_main ▒
- 7.52% 0.00% app app [.] main ▒
- main ▒
+ 7.43% read ▒
+ 7.43% 0.00% app libc-2.31.so [.] read ▒
+ 7.43% 0.00% app [kernel.kallsyms] [k] __x64_sys_read ▒
+ 7.43% 0.00% app [kernel.kallsyms] [k] ksys_read ▒
+ 7.43% 0.00% app [kernel.kallsyms] [k] vfs_read ▒
+ 7.43% 0.00% app [kernel.kallsyms] [k] __vfs_read ▒
+ 7.43% 0.00% app [kernel.kallsyms] [k] new_sync_read ▒
+ 7.43% 0.00% app [kernel.kallsyms] [k] blkdev_read_iter ▒
+ 7.43% 0.00% app [kernel.kallsyms] [k] generic_file_read_it▒
+ 7.43% 0.00% app [kernel.kallsyms] [k] blkdev_direct_IO ▒
+ 7.43% 0.00% app [kernel.kallsyms] [k] __blkdev_direct_IO
app 的确在通过系统调用 sys_read() 读取数据。并且从 new_sync_read 和 blkdev_direct_IO 能看出，进程正在对磁盘进行直接读，也就是绕过了系统缓存，每个读请求都会从磁盘直接读，这就可以解释我们观察到的 iowait 升高了。
优化
直接读写磁盘，对 I/O 敏感型应用（比如数据库系统）是很友好的，因为你可以在应用中，直接控制磁盘的读写。但在大部分情况下，最好还是通过系统缓存来优化磁盘 I/O，因此一般的应用删除 O_DIRECT 这个选项可以。
DIR *dirptr = opendir("/dev/");
perror("Failed to open dir");
int fd = open(disk, O_RDONLY | O_DIRECT | O_LARGEFILE, 0755);
perror("failed to open disk");
总结
虽然这个案例是磁盘 I/O 导致了 iowait 升高，不过， iowait 高不一定代表 I/O 有性能瓶颈。当系统中只有 I/O 类型的进程在运行时，iowait 也会很高，但实际上，磁盘的读写远没有达到性能瓶颈的程度。
因此，碰到 iowait 升高时，
- 需要先用 dstat、pidstat 等工具，确认是不是磁盘 I/O 的问题，
- 然后再找是哪些进程导致了 I/O。等待 I/O 的进程一般是不可中断状态，
- 用 ps 命令找到的 D 状态（即不可中断状态）的进程，多为可疑进程。
- 当不能用strace 直接分析 进程的系统调用时，可以通过perf 工具分析cpu时钟事件，找到对应的调用消耗，在源码中对应的系统调用部分，即可定位到实际的问题。
