Linux命令拾遗-理解系统负载
发布时间：2023-02-14 13:28:57 所属栏目：Linux 来源：
导读： 简介
这是Linux命令拾遗系列的第七篇，本篇主要介绍Linux中负载的概念与问题诊断方法。
一般在类unix系统上，都会有系统负载（load average）这个指标，用来形容系统的繁忙程度，值越大则代表系
这是Linux命令拾遗系列的第七篇，本篇主要介绍Linux中负载的概念与问题诊断方法。
一般在类unix系统上，都会有系统负载（load average）这个指标，用来形容系统的繁忙程度，值越大则代表系
|
简介 这是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个状态上：运行中linux命令系统，可运行，阻塞等待，其中，运行中的线程正在CPU上跑，可运行的线程等待CPU调度，而阻塞的线程等待锁释放或io完成。 在传统unix系统上（如BSD），系统负载由正在运行的线程以及可运行的线程这2个部分组成。它能很好的说明CPU的饱和情况，比如4核的CPU，如果负载一直高于4，那说明CPU资源饱和了。 而Linux扩大了负载的定义，如下：Linux负载由正在运行的线程和可运行的线程，以及D状态的线程(一般是等待io完成)这3个部分组成。 因为Linux认为，虽然D状态的线程并不消耗CPU资源，但是它会消耗磁盘、网卡等硬件资源以及锁这样的软件资源，因此它也应该被用来计算系统负载，想来也合理，毕竟系统负载是用来描述整个系统的繁忙程度的，而不仅仅是CPU的。 线程状态D 在Linux里面，线程有如下常见状态： 这里面的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将相同的栈聚合，即可发现是内核的哪些关键代码路径导致系统负载高。 （编辑：我爱资讯网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐