一文说清linux-system-load

简介：双十一压测过程中，常见的问题之一就是load 飙高，通常这个时候业务上都有受影响，比方服务rt飙高，比方机器无奈登录，比方机器上执行命令hang住等等。本文就来说说，什么是load，load是怎么计算的，什么状况下load 会飙高，load飙高是不是必然业务受影响。

作者 | 蒋冲
起源 | 阿里技术公众号

双十一压测过程中，常见的问题之一就是load 飙高，通常这个时候业务上都有受影响，比方服务rt飙高，比方机器无奈登录，比方机器上执行命令hang住等等。本文就来说说，什么是load，load是怎么计算的，什么状况下load 会飙高，load飙高是不是必然业务受影响。

一 什么是load

咱们平时所讲的load，其全称是Linux system load averages ，即linux零碎负载平均值。留神两个关键词：一个是“负载”，它掂量的是task（linux 内核中用于形容一个过程或者线程）对系统的需要（CPU、内存、IO等等），第二个关键词是“均匀”，它计算的是一段时间内的平均值，别离为 1、5 和 15 分钟值。system load average由内核负载计算并记录在/proc/loadavg 文件中， 用户态的工具（比方uptime，top等等）读的都是这个文件。

咱们个别认为：

• 如果load靠近0，意味着零碎处于闲暇状态
• 如果 1min 平均值高于 5min 或 15min 平均值，则负载正在减少
• 如果 1min 平均值低于 5min 或 15min 平均值，则负载正在缩小
• 如果它们高于零碎 CPU 的数量，那么零碎很可能遇到了性能问题（视状况而定）

二 如何计算load

1 外围算法

坦率了不装了，外围算法其实就是指数加权挪动平均法（Exponential Weighted Moving Average，EMWA），简略示意就是:

a1 = a0 factor + a (1 – factor)，其中a0是上一时刻的值，a1是以后时刻的值，factor是一个系数，取值范畴是[0,1]，a是以后时刻的某个指标采样值。

为什么要采纳指数挪动加权平均法？我集体了解

1、指数挪动加权平均法，是指各数值的加权系数随工夫呈指数式递加，越凑近以后时刻的数值加权系数就越大，更能反映近期变动的趋势；

2、计算时不须要保留过来所有的数值，这对内核十分重要。

咱们来看看，内核是怎么计算load average的，以下简称load。

下面的指数挪动均匀公式，a1 = a0 e + a (1 – e)，具体到linux load的计算，a0是上一时刻的load，a1是以后时刻的load，e是一个常量系数，a 是以后时刻的active的过程/线程数量。

如上一节所述，linux 内核计算了三个load 值，别离是1分钟/5分钟/15分钟 load 。计算这三个load 值时，应用了三个不同的常量系数e，定义如下：

#define EXP_1 1884       /* 1/exp(5sec/1min) */
#define EXP_5 2014      /* 1/exp(5sec/5min) */
#define EXP_15 2037   /* 1/exp(5sec/15min) */

这三个系数是怎么来的呢？公式如下：

• 1884 = 2048/(power(e,(5/(601)))) / e = 2.71828 */
• 2014 = 2048/(power(e,(5/(60*5))))
• 2037 = 2048/(power(e,(5/(60*15))))

其中e=2.71828，其实就是天然常数e，也叫欧拉数（Euler number）。

那为什么是这么个公式呢？其中，5是指每五秒采样一次，60是指每分钟60秒，1、5、15则别离是1分钟、5分钟和15分钟。至于为什么是2048和天然常数e，这里波及到定点计算以及其余一些数学知识，不是咱们钻研的重点，临时不展开讨论。

咱们看看内核中理论代码：

/*
 * a1 = a0 * e + a * (1 - e)
 */     
static inline unsigned long
calc_load(unsigned long load, unsigned long exp, unsigned long active)
{       
        unsigned long newload;
        // FIXED_1 = 2048
        newload = load * exp + active * (FIXED_1 - exp);
        if (active >= load)
                newload += FIXED_1-1;

        return newload / FIXED_1;
}

就是一个很直观的实现。下面代码中，第一个参数就是上一时刻的load， 第二个参数就是常量系数，第三个参数是active的过程/线程数量（包含runnable 和 uninterruptible）。

2 计算流程

load的计算分为两个步骤：

1、周期性地更新每个CPU上的rq里的active tasks，包含runnable状态和uninterruptible状态的task，累加到一个全局变量calc_load_tasks。

2、周期性地计算 load，load的计算次要就是基于上述calc_load_tasks 变量。

第一个步骤，每个cpu都必须更新calc_load_tasks，然而第二个步骤只由一个cpu来实现，这个cpu叫tick_do_timer_cpu，由它执行do_timer() -> calc_global_load()计算零碎负载。

整体流程如下图所示，在每个tick到来时（时钟中断），执行以下逻辑：

上图中，棕色的calc_global_load_tick函数就是实现第一个步骤的，绿色的calc_global_load 是实现第二个步骤，蓝色的calc_load 就是上一节中形容的外围算法。

这里须要阐明的是，calc_global_load 把计算出来的load 值放在一个全局的变量avenrun中，它的定义是unsigned long avenrun[3]，size 是3，用于寄存1/5/15分钟的load。 当查看/proc/loadavg的时候，就是从这个avenrun数组中获取数据。

三 load高常见起因

从上述load的计算原理能够看出，导致load 飙高的起因，说简略也简略，无非就是runnable 或者 uninterruptible 的task 增多了。然而说简单也简单，因为导致task进入uninterruptible状态的门路十分多（粗略统计，可能有400-500条门路）。集体感觉，有些中央有点滥用这个状态了。

自己基于多年的linux 内核开发和疑难问题排查教训，总结了一些教训，以飨读者。

1 周期性飙高

已经有些业务方遇到过load周期性飙高的景象，如果不是因为业务上的确有周期性的峰值，那么大概率是踩中了内核计算load时的bug。这个bug和内核的load采样频率（ LOAD_FREQ）无关，具体细节不展开讨论。这个bug在ali2016，ali3000， ali4000中曾经修复。

排除这个起因的话，能够接着查看是否磁盘IO的起因。

2 IO起因

磁盘性能瓶颈

iostat -dx 1 能够查看所有磁盘的IO 负载状况，当IOPS 或者 BW 高时，磁盘成为性能瓶颈，大量线程因为期待IO而处于uninterruptible 状态，导致load飙高。此时如果用vmstat 查看，可能会察看到 b 这一列的数值飙高， cpu iowait 飙高，/proc/stat文件中的procs_blocked 数值飙高。

云盘异样

云盘是虚拟盘，IO门路长而简单，比拟容易出问题。常见的异样是IO UTIL 100%，avgqu-sz 始终不为0，至多有1 。大家不要误会，io util 100%并不意味着磁盘很忙，而只意味着这个设施的申请队列里在每次采样时都发现有未实现的IO申请，所以当某种原因导致IO失落的话，云盘就会呈现UTIL 100%, 而ECS内核里的jbd2 线程，业务线程也会被D住，导致load 飙高。

JBD2 bug

JBD2是ext4 文件系统的日志零碎，一旦jbd2 内核线程因为bug hang住，所有的磁盘IO申请都会被阻塞，大量线程进入uninterruptible状态，导致load 飙高。

排除IO起因之后，接着能够查看内存状况。

3 内存起因

内存回收

task 在申请内存的时候，可能会触发内存回收，如果触发的是间接内存回收，那对性能的挫伤很大。以后task 会被阻塞直到内存回收实现，新的申请可能会导致task数量减少（比方HSF线程池扩容），load 就会飙高。 能够通过tsar –cpu –mem –load -i1 -l 查看，个别会察看到sys cpu 飙高，cache 突降等景象。

内存带宽竞争

大家可能只据说过IO带宽，网络带宽，很少留神内存带宽。其实内存除了在容量维度有瓶颈，在带宽层面也有瓶颈，只是这个指标一般的工具察看不了。咱们开发的aprof 工具能够察看内存带宽竞争，在双十一保障期间在混部环境大显神威。

4 锁

通常是内核某些门路上的spin_lock会成为瓶颈，尤其是网络的收发包门路上。能够用perf top -g 查看到spin_lock的热点， 而后依据函数地址找到内核的源码。 随同的景象可能有sys 飙高，softirq 飙高。

另外，采纳mutex_lock进行并发管制的门路上，一旦有task 拿着lock 不开释，其余的task 就会以TASK_UNINTERRUPTIBLE的状态期待，也会引起load飙高。然而如果这把锁不在要害门路上，那么对业务可能就没啥影响。

5 user CPU

有些状况下load飙高是业务的失常体现，此时个别体现为user cpu 飙高，vmstat 看到 r 这一列升高，tsar –load -i1 -l 看到runq 升高，查看proc/pid/schedstats 可能会看到第二个数字也就是sched delay 会减少很快。

四 根因剖析大招

1 RUNNABLE 型load飙高剖析

如上所述，这种状况，通常是因为业务量的减少导致的，属于失常景象，但也有是业务代码bug导致的，比方长循环甚至死循环。但无论哪一种，个别都能够通过热点剖析或者叫on cpu剖析找到起因。on cpu剖析的工具比拟多，比方perf，比方阿里自研的ali-diagnose perf等等。

2 UNINTERRUPTIBLE型load飙高剖析

所谓UNINTERRUPTIBLE，就是意味着在等，所以咱们只有找到等在哪里，就根本找到起因了。

查找UNINTERRUPTIBLE状态过程

UNINTERRUPTIBLE，通常也称为D状态，下文就用D状态来形容。有一些简略的工具能够统计以后D状态过程的数量， 略微简单一点的工具能够把D状态过程的调用链也就是stack输入。这类工具个别都是从内核提供的proc 文件系统取数。

查看/proc/${pid}/stat 以及/proc/${pid}/task/${pid}/stat 文件，能够判断哪些task 处于D状态，如下所示：

第三个字段就是task的状态。而后再查看/proc/${pid}/stack 文件就能够晓得task 等在哪里。如：

但有时候，D状态的task 不固定，这会导致抓不到D状态或者抓到stack的不精确。这时候，就得上另一个终极大招，提早剖析。

提早剖析

提早剖析须要深刻内核外部，在内核门路上埋点取数。所以这类工具的实质是内核probe，包含systemtap，kprobe，ebpf等等。然而probe 技术必须联合常识和教训能力打造成一个实用的工具。阿里自研的ali-diagnose能够进行各种delay剖析，irq_delay, sys_delay, sched_delay, io_delay, load-monitor。

五 总结

linux 内核是一个简单的并发零碎，各模块关系盘根错节。然而就load 而言，只有从runnable task和 uninterruptible task两个维度进行剖析，总能找到本源。

原文链接
本文为阿里云原创内容，未经容许不得转载。

喜欢 (0)赏

[搞代码]

分享 (0)