全面解析 Linux Load( 五 ) _小知识

即使当load高是由R状态线程数量过多导致，如果运行top命令时导致load高的R状态线程已经结束，此时也不会从按CPU Usage的排名的top输出中发现线索的。默认情况下，top命令是3秒中刷新，只显示3秒内的CPU Usage信息。

10 分析 Linux 系统 load 高的问题既然影响load的线程状态有R和D两种，那么再结合load在不同程序线程之间的聚合情况，我们将系统load高时，划分为如下四种场景：

由单个程序线程R状态高导致。
比如load1是200，load2process结果显示“160 R process1”，那么此时可以判断导致load高的主要原因是process1 。
如果是我们业务自己开发的程序，那么很多时候是由于程序员没有注意并发数限制、执行了一些耗费CPU资源的任务。
也有可能是陷入了自旋锁的陷阱。
由多个程序线程R状态高导致。
比如load1是200，load2process结果显示“20 R process1，15 R process2，14 R process3，10 R process4…….”，这种情况在日常运维中不常见。
由单个程序线程D状态高导致。
比如load1是1000，load2process结果显示“950 D process1” 。
此时可以查看这个程序对应进程的waiting channel信息，/proc//wchan，表示当前线程D在这个函数位置。有时候可能是陷入内核互斥锁mutex，用户空间叫futex 。造成进程D住的原因多种多样，需要结合搜索引擎具体情况具体分析。进一步还可以查看内核当前wchan的内核调用栈，/proc/
由多个程序线程D状态高导致。
此时可能操作系统和所在机器整体出现了问题，比如磁盘出现问题。
就有人解释状态D的含义是“Disk Sleep”，就比较生动的说明了这个问题。
实际造成的原因也是多种多样。

文章插图
总而言之，在实际生产中，造成load高的原因千差万别，还需要对linux内核的各个模块有深入的了解。
本文转自公众号“阿里智能运维”，原文链接：深度好文-全面解析Linux Load 。
Flink 作为当今流计算最热门技术，全球规模最大 Flink 集群的运维有哪些技术难点、痛点？11月1-2日，GOPS 2019 · 上海站，阿里巴巴大数据 SRE 运维技术专家王华带来精彩分享，敬请期待。

【全面解析 Linux Load】