简介#
这是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将相同的栈聚合，即可发现是内核的哪些关键代码路径导致系统负载高。