全面解析 Linux Load _小知识

文章插图

1 linux load 准确含义日常运维中我们经常会遇到linux系统load过高的问题，但是围绕linux load是如何计算的问题，业界还没有系统的论述文章。本文将全面系统阐述linux load计算原理和排查影响因素的方法。
日常获取linux load的方法无外乎通过top、w、uptime等linux系统命令进行获取。事实上这些linux系统命令打印的load值都是通过/proc/loadavg中获取的，大家可以在自己的linux中运行如下命令：

文章插图
在这里我们可以看到系统命令top、w、uptime都在procps-ng rpm包中，老一点版本linux中包名叫procps 。有兴趣的同学可以下载procps-ng源码包，看看load值是否取自/proc/loadavg 。
/proc/目录中mount的是一种叫proc的linux伪文件系统，主要被用作内核数据结构的接口。我们可以通过如下方法查看其中的伪文件和数值的含义。

文章插图
这段话大意是说，loadavg 文件中前三个字段是平均负载值，分别代表1、5 和 15 分钟的作业(job)数量的平均值，作业(job)包括运行队列(state R)或者等待磁盘I/O(state D)两种类型。这里面有3层信息：

/proc/loadavg中前三个数字分别表示load1、load5、load15的值。
load值代表的是对应时间内的jobs的平均数量，比如load1就表示过去1分钟内的jobs数量的平均值。job主要是一个shell概念，和进程组概念近似，这里应该属于用词不当（后面会分析，准确的用词应该是内核中的tasks或用户空间中的threads概念）。
而且只包含state状态为R和D的两种jobs，其他state状态不包含在内。

2 分解 Linux load 的脚本工具 load2process很显然具体的load1、load5和load15的值是内核计算之后，通过proc文件系统提供给用户空间的。要深入到内核中查看load的相关代码搞懂load计算过程，也非易事。而真正有个别能看懂内核代码的人分析一下load计算过程的相关代码，广大读者看完之后也还是无从下手。
在这里我们先抛开复杂的内核代码，直接给大家上干货load2process工具脚本，初步了解分解linux load的方法。具体获取方法如下：

文章插图
load2process中的关键脚本工具是load2process和load2pid，主要内容如下：

文章插图
简单解释一下这几个ps命令的参数：

-e参数，显示当前系统中所有进程；
-L参数，对每一个进程信息都展开显示包含的所有线程，每个线程展开一行；
h参数，隐藏ps命令的第一行header标题信息；
o state,ucmd，这里o和state,ucmd是组合在一起生效的，只输出state和ucmd这两列信息，state表示线程状态，ucmd表示线程名称。
o state,pid,cmd，这里o和state,pid,cmd是组合在一起生效的，只输出state,pid和cmd三列信息，pid表示进程id，cmd表示完整的线程名称。

找一台比较繁忙的机器，运行下以上脚本，同时获取当时的load情况。

文章插图
load2process 输出结果中第一列各数字相加为31，基本上和load1值26.92差不多，具体存在的差异后面会分析。此时如果想将load1值拆解到具体的线程级别，即可通过这个输出结果看到R状态的tasker_1是影响load1值的主要因素，且数量上贡献了18个。
load2process除以上这个用法外，还有如下几种用法。

文章插图
如果在执行 ./load2process 后，结果中的第三列比较集中于JAVA、Python和php等进程名。则可以继续使用load2pid工具进行进一步load分解。效果如下：

文章插图

3 更灵敏的load5s和load值预测写到这里，很多同学可能还是会有些怀疑，分解linux load就这么简单吗？下面会通过引入load5s的概念，将内核中复杂的load算法尽量转换到用户空间，让读者以一个看得见摸得着的方式来体会load的计算过程。
平时分析load高时，很多资料上都会说看load1、load5和load15的趋势。如果load15很高，但是load1已经比较低了，那说明系统已经处于逐步恢复中。反之，如果load1很高、load15比较低，那说明系统正在越来越严重。这都说的没错，也很容易理解，load1比load15更加灵敏。那有没有比load1更加灵敏的load值呢？