07 | 案例篇：系统中出现大量不可中断进程和僵尸进程怎么办？（上）

每个人的机器配置不一样，所以会出现有的机器iowait不明显，有的机器被打爆。解决办法是用docker cgroup选项对 block io做限制。假设硬盘设备为 /dev/nvme0n1，测试如下： 1. 限制块设备的读写 iops 为 3: `docker run --privileged --name=app9 --device /dev/nvme0n1:/dev/nvme0n1 --device-write-iops /dev/nvme0n1:3 --device-read-iops /dev/nvme0n1:3 -itd feisky/app:iowait-new2` 2. 可以查看host机器 cgroup 已为对应 docker container 添加了相关限制： ``` cat /sys/fs/cgroup/blkio/docker/"docker-container-id"/blkio.throttle.write_iops_device 259:0 3 cat /sys/fs/cgroup/blkio/docker/"docker-container-id"/blkio.throttle.read_iops_device 259:0 3 ``` 3. ``` docker exec -it "docker-container-id" /bin/bash root@4cc5e6c74cc0:/# dd iflag=direct if=/dev/nvme0n1 of=/dev/null bs=1k count=1000 1000+0 records in 1000+0 records out 1024000 bytes (1.0 MB, 1000 KiB) copied, 340.004 s, 3.0 kB/s ``` `dd` 每次从 /dev/nvme0n1 设备读取数据写到 /dev/null 设备，每次读取 1kB，一共1000次，必须为 direct 选项。可以观测到拷贝速度为 3 kB/s，即 1kB * 3，说明cgroup 限制 `blkio.throttle.read_iops_device` 生效。 4. 观察host机器 iowait 已经上去。 ``` top - 12:10:22 up 1:25, 1 user, load average: 0.88, 0.81, 0.83 任务: 780 total, 1 running, 227 sleeping, 0 stopped, 552 zombie %Cpu0 : 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 s %Cpu1 : 2.7 us, 0.0 sy, 0.0 ni, 97.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 s %Cpu2 : 0.0 us, 0.0 sy, 0.0 ni, 0.0 id,100.0 wa, 0.0 hi, 0.0 si, 0.0 s %Cpu3 : 5.3 us, 7.9 sy, 0.0 ni, 84.2 id, 0.0 wa, 0.0 hi, 2.6 si, 0.0 s MiB Mem : 7863.3 total, 230.4 free, 3847.2 used, 3785.8 buff/cache MiB Swap: 8192.0 total, 8191.5 free, 0.5 used. 3191.1 avail Mem ``` zombie数那么高是因为这个 docker container 已经运行20多分钟了。 供大家参考:)

老师以后的案例能不能使用centos7系统进行操作？做的很多实验和你的都会有部分偏差，这次偏差更大，相信学习你课程的大部分都是用虚拟机跑的项目，用centos系统使用率会很高，而且实际生产中用centos系统肯定大于Ubuntu，造成的实验偏差会不会也是系统的原因。我也遇到了没有出现D状态的进程，出现了大量Z进程。平均负载并没有提升，反而是下降了。iowait并没有变化。所以恳请您使用centos系统来教学吧

centos7 中模拟一下一起docker中无法启动app docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 54a43bfd9ddb feisky/app:iowait "/app" 7 seconds ago Exited (1) 6 seconds ago app docker logs app也为空。 既然是c程序，使用gdb调试，发现在select_disk() const char *sd_prefix = "sd"; const char *xvd_prefix = "xvd"; ... if (strncmp(sd_prefix, entry->d_name, 2) == 0 || strncmp(xvd_prefix, entry->d_name, 3) == 0) 看看机器上磁盘格式如下： df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 99G 16G 79G 17% / /dev/vdb1 99G 5.5G 88G 6% /data1 找到原因了,磁盘前缀不同，无法找到的盘，修改app.c代码 const char *sd_prefix = "vd"; const char *xvd_prefix = "vdb"; 然后就可以正常启动了。 docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ceb6eec8129a feisky/app:iowait "/app" 2 seconds ago Up 1 second app

我是centOS，也是无法启动，参考评论中的方式，修改启动参数为： docker run --privileged --name=app -itd feisky/app:iowait /app -d /dev/vdb1 就可以了

老师您好，我有个疑惑：不可中断状态睡眠不能被其他进程或者中断打断，那照道理说如果不可中断进程很多（超过CPU）逻辑核数时，系统应该处于卡死状态，可是实际上并不是这样的，其他进程照样在执行，说明是存在进程调度，也就是存在重调度中断，键盘输入也有响应，说明也存在硬件中断，这个似乎和不可中断进程状态进程的不可中断产生了冲突？是我有什么地方理解错了吗？

同问，关于Uninterruptible sleep(D)状态 的进程如何有效的处理，以前运维的时候遇到过，貌似只能重启机器，不知道还有什么更好的办法

没有模拟出来系统I/O瓶颈，可以帮忙看下吗： 容器运行起来后只发现一个app进程 [root@liyang2 ~]# ps aux|grep /app root 23619 0.0 0.0 4368 380 pts/0 Ss+ 17:12 0:00 /app root 23777 0.0 0.0 112648 952 pts/0 S+ 17:12 0:00 grep --color=auto /app CPU情况 wa也没有很高 %Cpu(s): 1.0 us, 1.5 sy, 0.0 ni, 94.0 id, 3.3 wa, 0.0 hi, 0.2 si, 0.0 st 系统：redhat7 3.10.0-327.el7.x86_64 x86_64 GNU/Linux

这个案例的iowait比较高，但是并不影响cpu使用率。因为准确来说，iowait也是属于cpu idle状态的一部分，他和僵尸进程影响的只是平均负载和系统资源

请教一下老师，一般在写代码访问io的时候，是不可中断还是可中断？

近日刚碰到一套生产系统出问题，我们逻辑cpu是120的实体机，跑oracle数据库，业务刚接进来就卡死了，一分钟平均负载200多，运行队列也两百多，cpu的usr部分四五十，sys部分四十左右，iowait基本是零，idle个位数，top和pidstat都无法输出，perftop也无法，只能dstat。请老师指导下思路，在查到底什么问题。