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

采用这样的计算方法，递归出来的load值是否更能代表系统的平均运行状况呢？由远及近权重越来越大。
到此我们已经对Linux load的计量有了一个比较完整的认识。有了以上的分析，接下去我们将聚焦于Linux load的系统性的监控。

8 Linux load 中的监控Load5s的值可以清晰的揭示linux load1 load5 load15的计算逻辑，但是load5s毕竟依赖内核模块的支持，对日常运维来说还是比较厚重。这里有一个比较轻量级的替代方案。
前文提到load2process输出结果中第一列各数字相加的事情，load2process中还封装了一个-s参数(summary) 。

文章插图
输出结果23表示当前load2process运行的同时，linux系统上所有R和D状态线程数之和。与load5s不同之处是，load5s是内核中每隔5001毫秒进行一次快照，而load2process -s是更加实时的数据。
当系统load高时，我们可以登录机器使用load2process和load2pid进行原因定位。有时候系统load高发生在半夜，或者发生在白天但并不在电脑前。这个时候，就需要依靠监控系统协助我们进行采集。在我们的load2process包中也提供了一个用于分解load的监控采集脚本check_load_process，具体使用方法如下。

文章插图
先介绍下这个监控采集脚本的使用。有2个参数load_threshold和thread_threshold，可以省略，默认值分别是2和0.4 。返回值是一个json格式的，方便于一些高级语言解析。下面分别介绍这2个参数的含义。
首先必须先说一下如何判断linux load高不高，单纯的看一个load1的绝对值是没有任何意义的。同样是load1值64，分别对于32核机器、64核机器和96核机器的压力是完全不同的。所以第一个参数load_threshold的阈值2，适用于判断当前监控采集脚本执行时机器的load是否高。根据我们的日常经验，当前压力大于机器的核数的200%时，可以用于判断机器负载较高。当然，对于一些灵敏度特别高的重要机器角色，你完全可以将此阈值调整为0.7 。
第二个参数thread_threshold比较好理解。当我们判断系统load较高时，系统上除了有几个导致系统load高的进程(线程)之外，还有一些很本分的常规进程(线程) 。我们通过thread_threshold参数将他们过滤掉，即只保留压力达到机器核数40%以上的进程(线程) 。
上面这个check_load_process监控采集指令是根据load2process脚本改造的。如果机器角色上是java、python或php等进程密集，那么需要根据load2pid脚本再改造一个监控采集指令。

9 R&D 状态对 Linux load 的不同影响很多公司在对load高进行监控的时候，会对load进行总体监控，并不区分其中的R和D两种类型的具体构成。事实上同样数量的R或D对系统的影响是远远不同的：

一般来说如果是R状态为主导致的load高，系统就会特别卡。更准确的来说，R状态的多少，主要还是要和CPU核数相关，大于主机CPU核数2倍以上，系统就会出现严重问题，出现多个R状态线程争抢CPU资源的情况。
如果是D状态为主导致的load高，曾经就有案例，当时的系统load高达11000多，但是整个操作系统还能正常服务。

既然这样，那我们就还需要进一步将load15、load5和load1，甚至load5s中的R和D状态分别进行监控记录，以便我们更加准确的判断系统健康程度。非常幸运的是kernel提供了这样的数据。

文章插图
在/proc/loadavg伪文件中，内核还提供了一个nr_running（斜线前38）的值。这个值表示当前系统中正在进行中的R状态的线程数。linux的sar命令也对这个nr_running值进行了持久化的采集，即如下输出结果中的runq-sz列。

文章插图
从上面这个案例中，也可以看到尽管load已经高达200多，但是runq-sz（即nr_running）值只有不到10 。充分说明导致load高的原因主要是当时D状态线程数过高。
区分了R和D状态线程对Linux load的影响，我们再来看一个绝大多数人都曾经历的误区。当linux系统load标高时，很多人都会去top一下，查看当前系统谁占用的CPU Usage最高。这种排查方法忽略了一下2个事实，很多时候可能不能得到满意的答案。
只有当进程（线程）处于R状态时，才耗费CPU Usage，其他状态（包括D状态）并不耗费CPU Usage 。当load高主要是由D状态线程数量过多导致的时候，此时从top中按CPU Usage的排名是不会发现任何线索的。