从平均负载开始，这进程是 CPU Bound 还是 IO Bound 的？

Cloud-Cloudys

发布于 2023-10-21 02:10:31

31700

代码可运行

运行总次数：0

代码可运行

在排查性能问题的时候，我们经常会使用 top 或者 uptime 两个 Linux 命令，top 命令和 uptime 命令都会给出最近机器 1 min，5 min，15 min 的平均负载情况，一般平均负载值（Average Load）接近甚至超出 CPU cores (现在一般指 processors 的个数, 现在 CPU 的一个 core 一般有两个 processor, 可以处理两个进程) 时，系统会有性能瓶颈.

平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程.

造成平均负载升高的原因一般有以下几种：

1、有 IO Bound 进程（即存在 IO 密集型任务）
2、有 CPU Bound 进程（即存在 CPU 密集型任务）
3、处于就绪状态（Ready）的进程多
…..

本篇文章主要记录下造成平均负载升高的两个场景. IO 密集型场景和 CPU 密集型场景.

这里的实验环境在一个操作系统为 Ubuntu 20.04.3 LTS 的容器内, 通过 stress 进行 IO Bound 与 CPU Bound 场景的模拟, 宿主机有 16 个 processors, 8G 运行内存.

docker run --rm -it  ubuntu:latest

root@bfdbc798879c:/# cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.3 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.3 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

root@bfdbc798879c:/# top
top - 11:21:53 up  3:10,  0 users,  load average: 0.66, 0.79, 0.46
Tasks:   2 total,   1 running,   1 sleeping,   0 stopped,   0 zombie
%Cpu0  :  1.0 us,  0.6 sy,  0.0 ni, 93.3 id,  0.0 wa,  0.0 hi,  5.1 si,  0.0 st
%Cpu1  : 10.2 us,  0.3 sy,  0.0 ni, 88.1 id,  0.0 wa,  0.0 hi,  1.3 si,  0.0 st
%Cpu2  : 10.4 us,  2.7 sy,  0.0 ni, 87.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu3  :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu4  : 11.1 us,  0.7 sy,  0.0 ni, 88.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu5  :  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu6  :  0.7 us,  1.3 sy,  0.0 ni, 98.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu7  :  3.0 us,  0.0 sy,  0.0 ni, 97.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu8  :  0.3 us,  1.0 sy,  0.0 ni, 98.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu9  :  0.7 us,  0.0 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu10 :  0.0 us,  0.0 sy,  0.0 ni, 99.7 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu11 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu12 :  0.3 us,  0.3 sy,  0.0 ni, 99.0 id,  0.3 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu13 :  0.3 us,  0.0 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu14 : 10.7 us,  0.7 sy,  0.0 ni, 88.6 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu15 :  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   7829.4 total,   1913.4 free,   1582.2 used,   4333.7 buff/cache
MiB Swap:   2048.0 total,   2047.7 free,      0.3 used.   5582.8 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    1 root      20   0    4232   3504   2952 S   0.0   0.0   0:00.02 bash
   12 root      20   0    6092   3332   2828 R   0.0   0.0   0:00.08 top

root@bfdbc798879c:/# free -mh
              total        used        free      shared  buff/cache   available
Mem:          7.6Gi       1.6Gi       1.8Gi       410Mi       4.3Gi       5.4Gi
Swap:         2.0Gi       0.0Ki       2.0Gi

让我们先安装一下 stress 压力测试工具和系统观测要用到的工具.

apt-get update
apt-get install -y stress sysstat

CPU Bound 场景

这里我们让三个逻辑 CPU 满载:

# 持续 10 min, 3 CPU 满载
stress -c 3 -t 600

我们用 watch 命令持续观察平均负载情况, 平均负载在逐渐变高，此时我的电脑 CPU 风扇也很响了😂

watch -d uptime

我们在使用 top 命令可以看到有三个 CPU 已经满载了，使用率百分百，还可以看到是哪个 COMMMAND 造成的，

但是上面不能很清楚的看到 IO 的情况，接下来我们用 mpstat 每隔 5 秒将所有 CPU 的观测情况打出来：

mpstat -P ALL 5

可以很清楚的看到，的确有三个 CPU 的空闲状态为 0（满载），使用率百分百，且 IO Wait 等待时间是很低的，所以单单 CPU Bound 场景可造成 Average Load 的升高.

不使用 top 命令,使用 pidstat 每隔 5 秒, 三次打印进程的 CPU 情况可定位出是哪个进程造成的平均负载升高.

root@bfdbc798879c:/# pidstat -u 5 3
Linux 5.4.72-microsoft-standard-WSL2 (bfdbc798879c)     10/07/21        _x86_64_        (16 CPU)

12:01:29      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
12:01:34        0       571  100.00    0.00    0.00    0.00  100.00     9  stress
12:01:34        0       572  100.00    0.00    0.00    0.00  100.00    15  stress
12:01:34        0       573  100.00    0.00    0.00    0.00  100.00    11  stress

IO Bound 场景

stress 压力工具也可以方便的进行 IO Bound 场景的模拟,

开始之前将上面 CPU Bound 场景给终止, 同样地, 我们先开好一个 Terminal 观察平均负载的变化:

watch -d uptime

使用 strees 调起 50 个进程(这里要高于 CPU processors 的数量, 让进程争夺 CPU), 不断打 IO, 持续 10 min:

root@bfdbc798879c:/# stress -i 50 -t 600
stress: info: [1756] dispatching hogs: 0 cpu, 50 io, 0 vm, 0 hdd

可以观察到, 平均负载在不断升高, 再使用 mpstat 可以观测到 IO Wait 很高.

mpstat -P ALL 5

可以 GET 到 IO Bound 任务的确会造成平均负载升高, 结合 iostat, 我们还可以观测磁盘设备的读写性能情况:

iostat -d -x

本文参与腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。

原始发表：2021-10-7，如有侵权请联系 cloudcommunity@tencent.com 删除

cpu

进程

系统

性能

本文分享自作者个人站点/博客前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！

登录后参与评论

0 条评论

热度