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

    作者回复: iowait不高是因为案例IO操作不够大导致的。我重新推了一个docker镜像，麻烦再试下看看

     1
     37
  • 书林
    2018-12-09
    每个人的机器配置不一样，所以会出现有的机器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多分钟了。

    供大家参考:)
    展开

    作者回复: 谢谢分享，见到Docker高手了😊。 这样的确可以达到IO限制的目的，不过使用系统级工具分析的时候，会有很大不同，比如iostat看看磁盘使用率可能还是很空闲；或者看看内核调用栈也有些不同。

    不过这倒是不错的性能隔离方案👍

     1
     22
  • songgoogle
    2018-12-07
    麻烦换centos吧，更接近实际工作需求
    
     17
  • 丁兆鹏
    2018-12-17
    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
    展开

    作者回复: 👍 高手，这是案例考虑不周了，已经在github上增加了参数

    
     16
  • Johnson
    2018-12-05
    遇到有大量的D状态的进程，导致负载到7000多，但是cpu和iowait都不高，除了重启设备还有什么办法解决？
    
     12
  • 每天晒白牙
    2018-12-05
    【D7打卡】
    今天主要学习进程的状态，可以通过ps或top查看进程的状态
    R:运行 Running或Runnable的缩写 表示进程在CPU的就绪队列中，正在运行或正在等待运行
    I:空闲 Idle的缩写，用在不可中断睡眠的内核线程上。空闲线程不会导致平均负载升高，D状态的会导致平均负载升高
    D:不可中断睡眠 Dist Sleep的缩写 表示进程正在跟硬件交互，并且交互过程中不允许被其他进程或中断打断
    S:可中断睡眠 Interruptible Sleep的缩写 表示进程因为等待某个事件而被系统挂起。当进程等待的事件发生时，它会被唤醒并进入R状态
    Z:僵尸 Zombie缩写 进程已经结束，但父进程还没有回收它的资源（如进程的描述符、PID等）
    T:暂停 Stopped或Traced的缩写，表示进程处于暂停或者跟踪状态
    今天实战的结果和老师的出入很大，我的系统是centos的
    ps aux | grep /app结果最开始是
    [root@localhost ~]# ps aux | grep /app
    root 3468 0.0 0.0 4364 380 pts/0 Ss+ 07:38 0:00 /app
    root 3568 12.0 3.3 37268 33036 pts/0 D+ 07:39 0:00 /app
    root 3569 7.0 3.3 37268 33036 pts/0 D+ 07:39 0:00 /app
    root 3571 0.0 0.0 112728 988 pts/4 S+ 07:39 0:00 grep --color=auto /app
    [root@localhost ~]# ps aux | grep /app
    root 3468 0.0 0.0 4364 424 pts/0 Ss+ 07:38 0:00 /app
    root 3590 15.0 3.3 37268 33016 pts/0 R+ 07:39 0:00 /app
    root 3591 15.0 3.3 37268 33016 pts/0 R+ 07:39 0:00 /app
    root 3593 0.0 0.0 112724 988 pts/4 R+ 07:39 0:00 grep --color=auto /app
    [root@localhost ~]# ps aux | grep /app
    root 3468 0.0 0.0 4364 424 pts/0 Ss+ 07:38 0:00 /app
    root 3597 0.0 0.0 112728 988 pts/4 S+ 07:39 0:00 grep --color=auto /app
    同样用top命令观察，平均负载也不高，然后wa也很低，也没看到处于D状态的进程。符合的只有 处于僵尸状态的进程比较多
    [root@localhost ~]# top
    top - 07:41:45 up 2:35, 8 users, load average: 0.00, 0.03, 0.31
    Tasks: 224 total, 1 running, 135 sleeping, 0 stopped, 88 zombie
    %Cpu0 : 0.7 us, 5.8 sy, 0.0 ni, 88.1 id, 4.1 wa, 0.0 hi, 1.4 si, 0.0 st
    %Cpu1 : 1.0 us, 7.1 sy, 0.0 ni, 86.7 id, 2.7 wa, 0.0 hi, 2.4 si, 0.0 st
    KiB Mem : 999720 total, 165196 free, 389676 used, 444848 buff/cache
    KiB Swap: 2097148 total, 1788172 free, 308976 used. 335844 avail Mem
    和老师反映了情况，老师说可能是案例里I/O线程还不够多，效果不明显，等着老师修改案例重新发镜像，再实验。
    展开
    
     6
  • 白华
    2018-12-06
    今天重新进行了测试，用了你docker hub上的fix2，fix1，new，new2都进行测试了，发现还是不行，iowait没有升高，平均负载没有上升，没有发现D状态。希望你以后使用centos7系统进行操作，性能会好很多
     1
     5
  • 黄涛
    2019-06-05
    我是centOS，也是无法启动，参考评论中的方式，修改启动参数为：
    docker run --privileged --name=app -itd feisky/app:iowait /app -d /dev/vdb1
    就可以了

    作者回复: 谢谢分享😊

    
     3
  • Brown羊羊
    2018-12-05
    没有模拟出来系统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
    展开

    作者回复: 我的机器配置太弱了，IO已经跑满还是好多人都没有观察到iowait的现象。重新推了一个镜像，加大了IO操作，再试试看现在怎么样

    
     3
  • 每天晒白牙
    2018-12-05
    【D7补卡】
    在和老师多次交流下，终于逼得老师发布一个把自己机器跑死的镜像，就可以了，结果和老师的温和了。看到老师之前的例子io压力还是不够啊
    docker run --privileged --name=app -itd feisky/app:iowait-new2
    执行这个镜像，iowait打满，直接把我的微信给挤掉了，浏览器都打不开了，不过结果是好的。
    继续坚持下去！
    
     2
  • 姜小鱼
    2018-12-05
    这个案例的iowait比较高，但是并不影响cpu使用率。因为准确来说，iowait也是属于cpu idle状态的一部分，他和僵尸进程影响的只是平均负载和系统资源

    作者回复: 确切的说是CPU繁忙程度，因为iowait也是CPU使用率的一种类型

    
     2
  • 耿长学
    2018-12-05
    学习了，每天上班路上听听音频看一看，晚上回家整理学习
    
     2
  • 一生一世
    2018-12-05
    我的思路是用1、pidstat看看上下文交换情况；2、vmstat看看wa;把僵尸进程的父进程停掉
    
     2
  • LA
    2019-05-28
    网络io也是属于不可中断的么？有些困惑，求老师指点下
    
     1
  • 林贻民
    2019-03-25
    老师您好，我有个疑惑：不可中断状态睡眠不能被其他进程或者中断打断，那照道理说如果不可中断进程很多（超过CPU）逻辑核数时，系统应该处于卡死状态，可是实际上并不是这样的，其他进程照样在执行，说明是存在进程调度，也就是存在重调度中断，键盘输入也有响应，说明也存在硬件中断，这个似乎和不可中断进程状态进程的不可中断产生了冲突？是我有什么地方理解错了吗？

    作者回复: 中断跟不可中断睡眠状态不是一回事，中断是会打断进程运行，而不可中断睡眠是指不可以被信号中断，而不是占着CPU不放了

    
     1
  • 辣椒
    2019-01-08
    评论里是高手辈出啊，两个问题都是看评论区的评论都解决了

    作者回复: 😊 高手如云

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

    作者回复: 一个基本的思路是要找出进程处于 D 状态的原因，是在等待什么样的I/O资源。比如分析系统调用、进程堆栈等等。

    找出根源之后，再去分析这些根源里面到底发生了什么，才导致的没有响应。

    当然，也有其他比较hack的方法，但生产环境中不推荐，以免给系统带来未知的损坏。

    
     1
  • CYH
    2018-12-06
    hi，老师：我晚上做的实验，操作系统是cenos7.5，我看您回复留言说已经更新可以提高iowaite了，但我这验证执行ps aux|grep app并没有发现D不可中断的进程从而导致io并没有提升，只是出现了很多僵尸进程。
    
     1
  • mj4ever
    2018-12-06
    通过实际操作和资料查阅，本次课程学到了以下知识：
    1、进程的多种状态，D (Disk Sleep) 状态的进程，会导致平均负载升高
    2、僵尸进程：
    （1）父子进程的运行是异步的过程，父进程需要知道子进程是何时关闭的
    （2）子进程需要父进程来收尸，但父进程没有安装SIGCHLD信号处理函数调用wait或waitpid（）等待子进程结束，或是子进程执行太快，父进程还没来得及处理子进程状态
    （3）父进程退出后，init进程会自动接手子进程，进行清理
    （4）僵尸进程已经放弃了几乎所有内存空间，没有任何可执行代码，也不能被调度，仅仅在进程列表中保留一个位置，记载该进程的退出状态等信息供其他进程收集
    （5）大量的僵尸进程会用尽 PID 进程号，导致新进程不能创建
    3、会话和进程组
    4、实操
    （1）查看了僵尸进程 查看僵尸进程的命令 ps -e -o stat,ppid,pid,cmd | egrep '^[Zz]' 或 ps -ef | grep "defunct"，停止父进程后，僵尸进程会被回收
    （2）没有观察到io的问题，可能是和机器配置有关系，不知道是否可以暴露个参数让我们启动docker的时候传参来施加压力。
    展开
    
     1
  • xiao豪
    2018-12-05
    打卡，太坑了，开着docker边跟着老师操作，结果卡死了T_T
    
     1
我们在线，来聊聊吧