Linux性能异常经典案例分析之D进程

一、伏笔篇

在分享案例之前，我们需要先了解几个概念：什么是平均负载？什么是D进程？什么是Z进程？TOP命令输出信息含义是什么？iostat命令输出的含义是什么？

1.1 平均负载

简单来说，平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。所谓可运行状态的进程，是指正在使用 CPU 或者正在等待 CPU 的进程，也就是我们常用 ps 命令看到的，处于 R 状态（Running 或 Runnable）的进程。不可中断状态的进程则是正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备的 I/O 响应，也就是我们在 ps 命令中看到的 D 状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程。

（1）单核处理器1C

（2）多核处理器2C

由（1）（2）可以看出，当只有1C CPU的情况下，理想状态下，同一时间、同一核CPU，只跑一个进程性能是最好的。1C CPU同时跑两个及以上的进程时，就会出现进程等待（堵车了）。即load average 上升说明系统积压了任务，说明性能出现瓶颈。

那么什么情况下会导致load average 上升呢？通常情况下，有以下两种可能：

A、CPU资源紧张，资源竞争激烈。[CPU上下文频繁切换]

B、IO资源紧张，磁盘IO达到瓶颈。[IO跑满即%util值达到100%]

1.2 D进程

D 是 Disk Sleep 的缩写，也就是不可中断状态睡眠（Uninterruptible Sleep），一般表示进程正在跟硬件交互，并且交互过程不允许被其他进程或中断打断。比如，当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

1.3 Z进程

Z 是 Zombie 的缩写，如果你玩过“植物大战僵尸”这款游戏，应该知道它的意思。它表示僵尸进程，也就是进程实际上已经结束了，但是父进程还没有回收它的资源（比如进程的描述符、PID 等）。

1.4 TOP命令输出解读

功能：显示系统中各个进程的资源占用多核CPU的监控，执行top命令后，按数字1，可监控每个逻辑CPU的状况。

（1）第一行的含义：

up day       #系统当前时间、运行时间
users        #当前登录用户数
load average #系统1min、5min、15min的CPU负载信息

（2）第2行的含义：

running   #1个进程正在运行
sleeping  #160个进程睡眠
stopped   #停止的进程数
zombie    #僵死的进程数n

（3）第3行的含义：

（4）第3行的含义：

total   #内存总量
used    #使用的内存量
free    #空闲的内存量
buffers #缓冲的内存量

（5）第5行的含义：

total  #交换区总量
used   #使用的交换区量
free   #空闲的交换区量
cached #缓存的内存量

（6）第6行的含义：

1.5 iostat命令输出解读

字段说明：

rrqm/s   #每秒进行merge的读操作数目
wrqm/s   #每秒进行merge的写操作数目
r/s      #每秒完成的读I/O设备次数
w/s      #每秒完成的写I/O设备次数
rMB/s    #每秒读M字节数 
wMB/s    #每秒写M字节数
avgrq-sz #平均每次设备I/O的数据大小
avgqu-sz #平均队列长度
await    #平均每次I/O操作的等待时间（毫秒）
Svctm    #平均每次I/O操作的服务时间（毫秒）
%uti1    #1秒中有百分之多少时间用于I/O操作，如果%util接近100%，磁盘可能存在瓶颈。

二、经典案例分享

2.1 背景介绍

架构回顾：用户业务场景类似图片服务器，通过负载均衡ULB将用户请求流量打散到A、B、C三台云主机（虚机）上，云主机挂载网络存储UFS（即NFS），用于存储用户请求图片数据。业务上线不久后，某次晚高峰，A、B、C三台服务器同时出现负载异常（load偏高），业务侧出现访问卡顿和业务数据加载缓慢等现象，随即客户侧收到大量用户投诉。

2.2 故障分析

由于故障现象有一定的误导性，以及对客户业务架构的不够了解，导致排查前期出现了偏离。即故障现象是三台虚机负载同时出现异常，我们最初怀疑是三台虚机同宿主，宿主出现异常影响了虚机，但是经过排查分析发现三台虚机宿主各不相同，且宿主各项监控指标均未发现异常，初步排除了宿主异常影响的可能性。

回归虚机本身的排查，通过现有监控，并未发现虚机有明显异常之处，进行扩容操作后，业务侧异常并未得到有效缓解。……此处省略200字

开始进入第三阶段排查，获取授权后，登录到虚机内部，top观察了一段时间，发现有大量Nginx D进程（不明白代表啥意思的，请回归伏笔篇），如下图：

明白D进程含义之后，大致可以确定是存储这块可能出现了问题，但是奇怪的是虚机磁盘IO监控指标并不是很高。经过进一步沟通，才了解到客户nginx后端请求的存文件都放在网络存储UFS上（实在没有想到虚机存储用的是文件存储UFS，光想着对虚机一顿操作猛如虎）。随后立即展开对UFS的分析，发现由于客户并发读写请求过大，已经触及当前容量UFS的吞吐瓶颈，于是立即进行UFS扩容操作，扩容后，主机负载迅速下降，业务侧异常现象也立刻消失。多么痛的领悟~

作者：UStarGao
链接：https://www.starcto.com/systemtool/164.html
来源：STARCTO
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

UCloud新用户专属注册连接

UCloud CDN超值特惠专场

UCloud全球云主机（UHost/VPS）大促页面

UCloud快杰云主机大促页面