【D8打卡】
今天主要学习的是系统中出现了大量不可中断进程和僵尸进程的处理方法
现象：
①iowait太高，导致平均负载升高，并且达到了系统CPU的个数
②僵尸进程不断增多
分析过程：
1.先分析iowait升高的原因
一般iowait升高，可能的原因是i/o问题
①用dstat 命令同时查看cpu和i/o对比情况（如 dstat 1 10 间隔1秒输出10组数据），通过结果可以发现iowait升高时，磁盘读请求（read）升高
所以推断iowait升高是磁盘读导致
②定位磁盘读的进程，使用top命令查看处于不可中断状态（D）的进程PID
③查看对应进程的磁盘读写情况，使用pidstat命令，加上-d参数，可以看到i/o使用情况（如 pidstat -d -p <pid> 1 3）,发现处于不可中断状态的进程都没有进行磁盘读写
④继续使用pidstat命令，但是去掉进程号，查看所有进程的i/o情况（pidstat -d 1 20），可以定位到进行磁盘读写的进程。我们知道进程访问磁盘，需要使用系统调用，
下面的重点就是找到该进程的系统调用
⑤使用strace查看进程的系统调用 strace -p <pid>
发现报了 strace:attach :ptrace(PTRACE_SIZE，6028)：Operation not peritted,说没有权限，我是使用的root权限，所以这个时候就要查看进程的状态是否正常
⑥ps aux | grep <pid> 发现进程处于Z状态，已经变成了僵尸进程，所以不能进行系统调用分析了
⑦既然top和pidstat都不能找出问题，使用基于事件记录的动态追踪工具
如果是centos系统，可以使用下面的方法
在容器外面把分析记录保存，到容器里面查看结果
操作：
（1）在centos系统上运行 perf record -g ，执行一会儿按ctrl+c停止
（2）把生成的perf.data（通常文件生成在命令执行的当前目录下，当然可以通过find | grep perf.data或 find / -name perf.data查看路径）文件拷贝到容器里面分析：
docker cp perf.data app:/tpm
docker exec -i -t app bash
cd /tmp/
apt-get update && apt-get install -y linux-perf linux-tools procps
perf_4.9 report
然后观察调用栈信息，检查是否有磁盘读操作，这个案例是定位到了进行磁盘的直接读，当然也可以查看源码进行验证。因为我的centos系统用老师的 iowait镜像iowait升高不明显，所以使用的是iowait-new2镜像，可以得到想要的结果，但是这个镜像把我的系统能搞崩溃，所以我只能执行到cd /tmp/这步，下面那部就执行不下去了。但是整个分析过程还是理解了。

2.僵尸进程
僵尸进程出现的原因是父进程没有回收子进程的资源出现的。解决办法是找到父进程，在父进程中处理，使用pstree查父进程，然后查看父进程的源码检查wait()/waitpid()的调用或SIGCHLD信号处理函数的注册

[D8打卡]
今天又学了两个乖, dstat可以同时看cpu和io. (上篇文章安装后只看了下效果,没想到这一层).strace可以追踪系统调用.
虽然我之前也写过linux c程序,但是看到sys_read/new_sync_read/blkdev_direct_IO确实不知道是正在对磁盘进行直接读, 即使看了代码 也不知道 O_DIRECT 这个参数就是直接读.
还是功力太浅,线索摆在前面也抓不住,哈哈😁.
----
有些同学问"服务出现僵尸进程时，怎样处理".
其实我也不知道怎么处理,但是我把那个父进程杀掉, 僵尸进程就几乎没有了.
上一篇文章中,老师也提到过[通常，僵尸进程持续的时间都比较短，在父进程回收它的资源后就会消亡；或者在父进程退出后，由 init 进程回收后也会消亡]