[转帖] Linux命令拾遗-理解系统负载

https://www.cnblogs.com/codelogs/p/16060498.html

简介#

这是Linux命令拾遗系列的第七篇，本篇主要介绍Linux中负载的概念与问题诊断方法。

本系列文章索引
Linux命令拾遗-入门篇
 Linux命令拾遗-文本处理篇
 Linux命令拾遗-软件资源观测
 Linux命令拾遗-硬件资源观测
 Linux命令拾遗-剖析工具
 Linux命令拾遗-动态追踪工具

一般在类unix系统上，都会有系统负载（load average）这个指标，用来形容系统的繁忙程度，值越大则代表系统越繁忙。

查看负载#

$ uptime

19:59:57 up 29 days,  7:08,  1 user,  load average: 0.57, 0.26, 0.18

我们关注load average后的3个值，分别代表1分钟、5分钟、15分钟的系统平均负载，如果1分钟值>5分钟值>15分钟值，则代表近15分钟内系统压力越来越大，反之亦然。
同样，在top命令的第一行，也能看到系统负载，它的含义和uptime是一样的。

负载是什么#

一般来说，系统线程基本都在这3个状态上：运行中，可运行，阻塞等待，其中，运行中的线程正在CPU上跑，可运行的线程等待CPU调度，而阻塞的线程等待锁释放或io完成。

在传统unix系统上（如BSD），系统负载由正在运行的线程以及可运行的线程这2个部分组成。
它能很好的说明CPU的饱和情况，比如4核的CPU，如果负载一直高于4，那说明CPU资源饱和了。

而Linux扩大了负载的定义，如下：
Linux负载由正在运行的线程和可运行的线程，以及D状态的线程(一般是等待io完成)这3个部分组成。

因为Linux认为，虽然D状态的线程并不消耗CPU资源，但是它会消耗磁盘、网卡等硬件资源以及锁这样的软件资源，因此它也应该被用来计算系统负载，想来也合理，毕竟系统负载是用来描述整个系统的繁忙程度的，而不仅仅是CPU的。

线程状态D#

在Linux里面，线程有如下常见状态：

R: 正在运行或可运行状态
S: 睡眠状态，被阻塞等待唤醒
D: 不可中断睡眠状态，一般是等待io完成

这里面的R与D状态的线程会影响系统负载，因此，当系统负载较高时，可以通过如下命令了解是哪些线程导致的：

ps -eLo pid,tid,stat,comm | grep -E " R|D"

小实验:将系统负载升到100#

# 使用vfork函数创建一个子进程，子进程如果不调用exec系统调用，它的状态会一直是D。

$ cat uninterruptible.c

int main() {

    vfork();

    sleep(600);

    return 0;

}

# 编译成可执行程序

$ gcc -o uninterruptible uninterruptible.c

# 运行100个程序

$ for i in {1..100}; do ./uninterruptible & done

等待1分钟，就会发现系统负载升到了快100，如下：

$ uptime

20:24:42 up 29 days,  7:32,  1 user,  load average: 99.94, 74.82, 35.87

# 可以看到很多D状态的进程

$ ps -eLo pid,tid,stat,pcpu,wchan:32,comm | grep " D"

3774195 3774195 D     0.0 do_fork                          uninterruptible

3774196 3774196 D     0.0 do_fork                          uninterruptible

3774197 3774197 D     0.0 do_fork                          uninterruptible

3774198 3774198 D     0.0 do_fork                          uninterruptible

如上，通过ps命令可以看到线程状态，还有一个wchan字段，它显示的是线程当前被阻塞在什么内核函数上，这能看出一些蛛丝马迹。

另外，通过/proc/sysrq-trigger可以看到D线程阻塞时的代码路径，如下：

# 写入一个w即可，需要root权限执行

$ echo w > /proc/sysrq-trigger

# 然后内核会把D状态线程调用栈输出到内核日志，这可以通过dmesg查看

$ dmesg

这里就能很清楚的看到，是由于vfork系统调用引起的负载上升。

之前介绍过bcc工具集里的offcputime工具，它可以用来绘制offcpu火焰图，同样的，诊断高负载问题时，也可以用这个工具，传一个参数，让其只关注D状态线程的offcpu行为即可，如下：

# ubuntu安装bcc工具集

$ sudo apt install bpfcc-tools

# 使用root身份进入bash

$ sudo bash

# --state 2用于指定抓取TASK_UNINTERRUPTIBLE即D状态线程的offcpu栈

$ offcputime-bpfcc -K --state 2 -f 60  > d_state_offcpu_stack.out

# 绘制为offcpu火焰图

$ awk '{ print $1, $2 / 1000 }' d_state_offcpu_stack.out | ./FlameGraph/flamegraph.pl --color=io --countname=ms > d_state_offcpu.svg

若无法使用/proc/sysrq-trigger与bcc工具，也可以借助/proc/$pid/task/$tid/stack伪文件查看，如下：

$ cat /proc/2666/task/2666/stack

[<0>] _do_fork+0x237/0x390

[<0>] do_syscall_64+0x55/0x110

[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

[<0>] 0xffffffffffffffff

可以发现，/proc/$pid/task/$tid/stack文件记录着线程的内核栈，因此当系统负载高时，只要查看一下R或D状态线程的内核栈，即可发现问题所在，如下：

$ ps h -eLo pid,tid,s \

    | grep -E 'R|D' \

    | while read pid tid s;do paste -s /proc/$pid/task/$tid/stack;done \

    | sort | uniq -c | sort -nr

    100 [<0>] _do_fork+0x237/0x390      [<0>] do_syscall_64+0x55/0x110  [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9  [<0>] 0xffffffffffffffff

如上，通过ps、grep找出R或D状态线程，通过paste将线程内核栈折叠成一行，再通过sort、uniq将相同的栈聚合，即可发现是内核的哪些关键代码路径导致系统负载高。

往期内容#

Linux命令拾遗-入门篇
 原来awk真是神器啊
 Linux文本命令技巧(上)
Linux文本命令技巧(下)
字符编码解惑