Linux命令拾遗-理解系统负载

4,260 阅读2分钟

原创:打码日记(微信公众号ID:codelogs),欢迎分享,转载请保留出处。

简介

这是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 

sysrq
这里就能很清楚的看到,是由于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

d_state_offcpu
若无法使用/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文本命令技巧(下)
字符编码解惑