简介：在双重11个压力测试的过程中，常见问题之一是负载飙升。通常此时，业务受到影响，例如服务RT飙升，例如机器无法登录，例如机器上的执行命令。什么情况，负载将飙升，以及负载是否不可避免地会受到影响。
作者|江宗资料来源|阿里技术公共帐户
在双重11个压力测试的过程中，常见问题之一是负载飙升。通常在这个时候，业务受到影响。例如，服务RT正在飙升，例如机器无法登录，例如命令挂在机器上等等。负载将飙升，以及负载是否不可避免地会影响业务。
我们通常讨论Linux系统的全名平均值，Linux系统的负载平均值。注意两个关键字：一个是“负载”，它可以测量该任务（在Linux内核中描述过程或线程）（CPU，内存，IO等）。第二个关键字是“平均”，它分别计算出一段时间1、5和15分钟的平均值。系统负载平均值由内核负载计算并记录在/proc/loadAvg文件中。工具。基于用户的工具（例如正常运行时间，顶部等）都读取此文件。
我们通常认为：
1个核心算法
坦白说，核心算法实际上是指数加权运动平均方法（指数加权移动平均值（EMWA），并简单地指示：
A1 = A0
因子 + a
（1-因子），其中A0是前矩的值，A1是当前力矩的值，该因子是系数，值范围为[0,1]。A是当前时刻某个指标的采样值。
为什么使用索引移动加权平均方法？我个人了解
1.索引的加权平均方法将每个值的加权系数移动到时间索引时减小。越接近当前时刻，加权系数越大，可以反映最近变化的趋势；
2.计算时无需保存所有过去的值，这对内核非常重要。
让我们看一下内核如何计算负载平均值，以下简称为负载。
上述索引移动平均公式，A1 = A0
E +A。
（1 -e），Linux负载的计算A0是前矩的负载，A1是当前力矩的负载，E是恒定系数，A是当前力矩处的活动过程/线程的数量。
如上一节所述，Linux内核计算了三个负载值，即1分钟/5分钟/15分钟。计算这三个负载值时，使用三个不同的恒定系数E来定义以下内容：
这三个系数是如何来自的？该公式如下：
E = 2.71828实际上是天然常数E，也称为Euler编号。
那么为什么这个公式？在其中，有5个是指每五秒钟，60个指的是每分钟60秒，1、5和15分别为1分钟，5分钟和15分钟。2048和自然常数E，它涉及固定的点计算和其他数学知识，而不是我们研究的重点，我们不会暂时讨论。
让我们看一下内核中的实际代码：
这是一个非常直观的实现。在上述代码中，第一个参数是前一刻的负载，第二个参数是恒定系数，第三个参数是活动的流程/线程数（包括可运行和不间断）。
2计算过程
负载的计算分为两个步骤：
1.定期更新每个CPU中的活动任务，包括可运行的状态和不间断状态的任务，该状态累积到全局变量Calc_load_tasks。
2.计算负载周期计算，负载的计算主要基于上述Calc_load_tasks变量。
在第一步中，每个CPU必须更新CalC_Load_tasks，但第二步仅由CPU完成。此CPU称为tick_do_timer_cpu。
总体过程如下图所示。当每个刻度到达时（时钟中断）时，执行以下逻辑：
在上图中，Brown Calc_global_load_tick功能是完成第一步。绿色Calc_global_load将完成第二步。蓝色call_load是上一节中描述的核心算法。
这里需要解释的是，Calc_global_load将计算出的负载值放在全局变量avenrun中。它的定义是无符号的长avenrun [3]，大小为3，用于存储1/5/15分钟的负载。查看/proc/loadAvg时，可从此avenrun阵列获得。
从上述负载的计算原理可以看出，高飙升的原因很简单。这无非是可运行或不间断的任务的增加。但是，它是复杂且复杂的，因为有许多路径导致任务进入不间断的状态（粗糙的统计信息，可能有400-500个路径）。，有些地方有些滥用。
我总结了一些基于Linux内核开发以及Linux内核开发的困难问题以及读者难题的困难问题。
1个周期性飞涨
一些商业方遇到了周期性高负载的现象。如果不是因为业务确实具有定期峰值，那么当内核计算负载时，概率是踩到错误。此错误和内核负载采样频率（LOAD_FREQ）是相关的，并且具体细节不讨论。该错误已在Ali2016，Ali3000和Ali4000进行了修复。
如果排除此原因，则可以检查磁盘IO是否。
2 io原因
磁盘性能瓶颈
iostat -dx 1可以查看所有磁盘的IO负载。当IOPS或BW高时，磁盘变成了性能瓶颈。大量线程处于不间断的状态，因为它们等待IO，导致负载飙升。在这次，如果查看VMSTAT，可以观察到B列的数值，CPU IOWAIT飙升，Procs_blockd soaring/proc/stat文件中的值飙升。
云盘异常
云磁盘是虚拟磁盘。IO路径漫长而复杂，更容易解决问题。常见异常是100％io util，Avgququ-sz始终不是0，至少1.不误解，100％io io util并不意味着磁盘很忙，但仅表示该设备的请求队列在每个样品处找到未完成的io请求。云磁盘将出现100％的UTIL，并且ECS内核中的JBD2线程也将是D，Business线程也将为D，D，D，d。导致负载的增加。
JBD2错误
JBD2是Ext4文件系统的日志系统。一旦JBD2内核线程寿命，所有磁盘IO请求将由于悬挂而被阻止，并且大量线程进入不间断的状态，导致负载飙升。
排除IO原因之后，您可以检查内存条件。
3个记忆原因
记忆回收
申请内存时，任务可能会触发内存恢复。如果触发了直接的内存恢复，则性能非常有害。当前任务将被阻止直到内存回收完成，并且新请求可能会导致任务数增加（例如HSF线程池的扩展），并且负载将飙升。通常，将观察到系统cpus soar，缓存突然的下降和其他现象。
内存带宽竞赛
您可能只听说过IO带宽，网络带宽，并且很少注意记忆带宽。实际上，除了容量维度的瓶颈外，带宽级别还有瓶颈，但是无法观察到具有普通指标的工具我们开发的APROF工具可以观察到内存带宽竞争，在十一期保证期间，在混合环境中它非常强大。
4锁
内核的某些路径上的spin_lock将成为瓶颈，尤其是在网络和接收网络的数据包上。到函数地址。由SYS串起的ACCOMPAN，SoftIRQ飙升了。
此外，在使用mutex_lock的并发控制路径上，一旦未使用锁定任务，其他任务将与Task_unirthible的状态等待，这也会导致负载飙升。但是，如果此锁不在密钥路径上，则可能不会影响业务。
5用户CPU
在某些情况下，负载飙升是业务的正常表现。目前，用户CPU飙升。VMSTAT看到R. TSAR -LOAD -I1 -L的上升列看到Runq高程，View Proc/PID/Schedstats可能会看到第二个数字，即计划延迟，将迅速增加。
1个可运行的类型负载高昂的高分析
如上所述，这种情况通常是由于业务量的增加而引起的，这是正常的，但也是由业务代码错误引起的，例如长期循环甚至死亡周期。发现通过热点分析或CPU分析找到原因。有许多用于CPU分析的工具，例如PERF，例如Ali的Ali-Diar-Diarose Perf，等等。
2不间断的负载高昂分析
So称为不可干扰的方式意味着等待，因此，只要我们找到您的位置，我们就可以找到原因。
查找不间断的状态过程
在下面的D状态中描述了不间断的，通常也称为D状态。有一些简单的工具可以计算当前D状态过程的数量。更复杂的工具可以调用D状态进程呼叫链，该链条是堆栈输出。这种类型的工具通常是从内核提供的Proc文件系统中绘制的。
查看/proc/$ {pid}/stat和/proc/$ {pid}/task/$ {pid}/stat文件，您可以确定哪个任务在d状态下，如下所示：
第三个字段是任务的状态。然后检查/proc/$ {pid}/stack文件以了解任务在哪里等待。
但是有时候，D状态的任务不是固定的，这会导致D状态或不准确捕获堆栈。这次，它必须是终极的大动作，延迟分析。
延迟分析
延迟分析需要渗透到内核的内部以及内核路径上的点数。因此，这些工具的本质是内核探针，包括SystemTap，Kprobe，EBPF等。与知识和经验相结合，成为一个实用的工具。由Ali自行开发的Ali-Diarose可以执行各种延迟分析，IRQ_DLAY，SYS_DELAY，SYS_DELAY，SCHEN_DELAY，SCHEN_DELAY，io_delay，io_delay，Load-Monitor。
Linux内核是一个复杂的并行系统，每个模块关系都是复杂的。