一、进程的状态
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
2、进程状态图解
向一个进程发送sigstop 信号，它就会因响应这个信号变成暂停状态（stopped）；再向它发送 sigcont 信号，进程又会恢复运行（如果进程是终端里直接起动的，
则需要你用fg命令，回复到前台运行）
而当你的用的调试器调试一个进程是，在使用断点中断进程后，进程就会变成跟踪状态，这其实也就是一种特殊的暂停状态，只不过你可以用调试器
来跟踪并按需控制进程的运行
了解了这些，我们再回到今天的主题，先看不可终端状态，这其实是为了保证进程数据与硬件状态一直，并且增长情况下，不可终端状态在很短时间内会结束，
所以短时的不可终端进程我们一般可忽略
但如果系统或硬件发生了故障，进程可能会在不可中断状态保持很久，甚至导致系统中出现大量不可中断进程，这时，你就得注意下，系统时不时出现了i/o 等性能问题。
再看僵尸进程，这是多进程应用很容易碰到的问题,正常情况下，当一个进程创建了子进程后，它应该通过系统调用 wait() 或者 waitpid() 等待子进程结束，回收子进程的资源；
而子进程在结束时，会向它的父进程发送sigchld 信号，所以，父进程还可以注册 sigchld信号的处理函数，异步回收资源
如果父进程这么做，或是子进程执行太快，父进程还没有来得及处理子进程状态，子进程就已经提前退出，那这时的紫禁城就会变成僵尸进程，换句话说，父亲应该一直对儿子负责，善始善终，如果不作为或者跟不上、都会导致"问题少年"的出现
通常、僵尸进程持续的时间都比较短，在父进程回收它的资源后就会消亡；或者在父进程推出后，由init进程回收后也会消亡
一旦父进程没有处理子进程的种植，还一直保持运行状态，那么子进程就会一直处于僵尸状态，大量的僵尸进程会用尽pid进程号，
导致新进程不能创建，所以这种情况一定要避免
二、案例分析
1、运行案例应用
docker run --privileged --name=app -itd feisky/app:iowait
2、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
1、s 和 是什么意思呢？
s 表示这个进程是一个会话的领导进程，而 表示前台进程组
这里又出现了两个新概念，进程组和会话，他们用来管理一组相互关联的进程，意思其实很好理解
2、什么是进程组？
进程组表示一组相互关联的进程，比如每个子进程都是父进程所在组的成员；而会话是只共享同一个控制终端的一个或多个进程组
3、什么是会话？
比如，我么通过ssh登录服务器，就会打开一个控制终端（tty），这个控制终端就对应一个会话，而我我们在终端中运行的命令以及他们的子进程
就构成了一个个的进程组，其中，在后台运行的命令，构成后台进程组；在前台运行的命令，就构成前台进程组
3、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
...
4、分析过程
从这里你能看出什么问题吗？逐行观察，别放过任何一个地方，忘了哪行参数意思的话，也要及时返回去复习
先看第一行平均负载，过去1、5、15分钟内的平均负载依次减小，说明平均负载正在升高，而1分钟内的平均负载已经达到了系统cpu的个数，说明系统可能已经有了性能瓶颈
tasks 有1个正在运行的进程，但僵尸进程比较多，而且还在不停增加，说明有子进程在退出时没有没清理
cpu使用率：用户cpu和系统cpu都不高，但iowait分别是60.5%和94.6%好像有点不正常
每个进程的情况：cpu使用率最高的进程只有0.3%，看起来并不高；但是有两个进程处于d状态，它们可能在等待i/o，但光凭这里并不能确定是它们导致了 iowait 升高
我们把这四个问题在汇总一下，就可以得到很明确的两点：
第一点：iowait太高了，导致系统的平均负载生该，甚至达到系统cpu的个数
第二点：僵尸进程在不断增多，说明程序没能正确清理子进程的资源
三、遇到的问题及小结
1、用top命令观察，平均负载也不高，然后wa也很低，也没有看到d状态的进程
2、解决办法
老师说可能是案例里i/o线程还不够多，效果不明显，等着老师修改案例重新发镜像，再实验。
在和老师多次交流下，终于逼得老师发布一个把自己机器跑死的镜像，就可以了，结果和老师的温和了。
[root@luoahong ~]# docker run --privileged --name=app -itd feisky/app:iowait-new2
unable to find image 'feisky/app:iowait-new2' locally
iowait-new2: pulling from feisky/app
32802c0cfa4d: already exists
da1315cffa03: already exists
fa83472a3562: already exists
f85999a86bef: already exists
f69cb5280862: pull complete
digest: sha256:9fc8b013aff0bc2c1b1dc41a33989a8ddd4ed7da56f53f6559bbc76836041dc2
status: downloaded newer image for feisky/app:iowait-new2
00ed5564248127a98c467eb99f8b32d3dc3ebc5d7f47563d6617ccfd7348b10b
[root@luoahong ~]# ps aux | grep /app
root 11798 0.1 0.0 4368 380 pts/0 ss 09:54 0:00 /app
root 11851 0.0 0.8 70040 65776 pts/0 r 09:55 0:00 /app
root 11852 0.0 0.8 70040 65776 pts/0 r 09:55 0:00 /app
root 11854 0.0 0.0 112708 980 pts/0 s 09:55 0:00 grep --color=auto /app
top截图
执行这个镜像，iowait打满，直接把我的微信给挤掉了，浏览器都打不开了，不过结果是好的。
3、小结
用我么最熟悉的ps或者top，可以直接查看进程的状态，这些状态包括运行（r）、空闲（i）、不可中断睡眠（d）、可中断睡眠（s）、僵尸（z）以及暂停（t）等
其中，不可中断状态和僵尸状态，是我们今天学习的重点
不可中断状态：表示进程正在跟硬件交互，为了保护进程数据和硬件的一致性，系统不允许其他进程或中断打断这个进程。进程长时间处于不可中断状态，通常标识系统有i/o 性能问题
僵尸进程表示进程已经退出，但它的父进程还没有回收子进程占用资源。短暂的僵尸状态我们通常不必理会，但进程长时间属于僵尸状态，
就应该注意了，可能有应用程序没有正常处理子进程退出