从一次线上告警复盘：我是如何用stress和dd命令，定位到那台‘假空闲’的Linux服务器的
从一次线上告警复盘：我是如何用stress和dd命令，定位到那台‘假空闲’的Linux服务器的
那天凌晨三点，监控系统突然弹出一条告警：某台核心业务服务器的应用响应时间突破阈值。奇怪的是，系统监控面板上CPU使用率显示不足10%，内存空闲率高达75%，各项资源指标看起来都"健康"得反常。这种资源空闲但性能低下的矛盾现象，正是最危险的性能陷阱之一。
1. 初探矛盾：当监控数据与用户体验背道而驰
登录服务器后，我首先用uptime确认了负载情况：
$ uptime 03:15:01 up 42 days, 8:23, 2 users, load average: 15.32, 14.87, 12.56平均负载高达15（这台16核服务器），但top显示的CPU空闲率确实在90%以上。这种高负载低使用率的组合，通常指向以下几种可能：
- I/O等待：进程因磁盘或网络阻塞而处于不可中断睡眠状态
- CPU竞争：调度器或NUMA架构导致的核间资源争抢
- 内存带宽瓶颈：虽然内存充足但访问通道拥塞
为了验证这些假设，我需要一组能精确施加压力的工具链。这就是stress配合dd的黄金组合发挥作用的时候。
2. 压力测试三板斧：CPU、内存与I/O的隔离验证
2.1 CPU调度器测试：stress -c的妙用
首先验证CPU调度是否正常。通过以下命令施加可控压力：
# 启动4个CPU压力进程（我们服务器有16核） $ stress -c 4 --timeout 60同时用mpstat -P ALL 1观察各核心利用率：
03:20:00 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 03:20:01 AM all 4.32 0.00 1.15 94.42 0.00 0.03 0.00 0.00 0.00 0.08 03:20:01 AM 0 12.12 0.00 3.03 84.85 0.00 0.00 0.00 0.00 0.00 0.00 03:20:01 AM 1 11.11 0.00 2.02 86.87 0.00 0.00 0.00 0.00 0.00 0.00关键发现：虽然只启动了4个压力进程（理论上应该占用25%CPU），但实际iowait高达94%，说明进程大部分时间在等待I/O。这解释了为什么CPU使用率低但负载高。
2.2 内存带宽测试：--vm与dd的组合拳
接下来验证内存子系统。分两个阶段测试：
阶段一：纯内存压力测试
# 分配16GB内存（服务器总内存32GB） $ stress --vm 4 --vm-bytes 4G --vm-keep --timeout 120通过vmstat 1观察：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 0 0 10234076 124320 458372 0 0 2154 320 123 456 8 4 12 76 0阶段二：内存+磁盘同步写入
# 使用oflag=dsync确保直接写入磁盘 $ dd if=/dev/zero of=/data/test.bin bs=1G count=10 oflag=dsync此时iostat -x 1显示：
Device r/s w/s rkB/s wkB/s await svctm %util vda 0.00 125.00 0.00 51200.00 320.15 8.00 100.00对比发现：纯内存操作时wa为76%，加入磁盘同步写入后磁盘利用率直接100%。说明内存带宽不是瓶颈，磁盘I/O才是真正短板。
2.3 NUMA效应验证：taskset的精准打击
现代服务器普遍采用NUMA架构，跨节点访问内存会有性能损失。通过绑定核心测试：
# 绑定到第一个NUMA节点 $ taskset -c 0-7 stress -c 8 --timeout 60 # 绑定到第二个NUMA节点 $ taskset -c 8-15 stress -c 8 --timeout 60使用numastat对比：
Node 0 CPU usage: 78% Node 1 CPU usage: 22% Node 0 mem usage: 85% Node 1 mem usage: 15%数据显示明显的NUMA不平衡，第一个节点负载远高于第二个，这会导致部分CPU核心"过劳"而其他核心"闲置"的假象。
3. 真相浮现：拼图完成的时刻
综合所有测试数据，问题脉络逐渐清晰：
- 磁盘I/O瓶颈：
dd oflag=dsync测试显示实际磁盘写入速度仅有50MB/s（预期应为200MB+） - I/O等待伪装：高iowait导致CPU看似"空闲"，实则进程都在等待I/O
- NUMA失衡：内存访问局部性差加剧了性能波动
进一步检查发现：这台虚拟机所在的物理主机，其RAID卡电池故障导致write-back缓存被禁用，所有写入都直接落盘。这就是为什么监控显示"内存充足"、"CPU空闲"，但实际性能低下的根本原因。
4. 系统性排查方法论
这次排查经历提炼出的五步定位法：
- 指标矛盾分析：当监控指标与用户体验不符时，建立假设
- 压力隔离测试：用stress分模块施加可控压力
- 性能数据对比：mpstat/vmstat/iostat多维度交叉验证
- 架构影响评估：NUMA、调度器等底层因素考量
- 根因验证：通过控制变量法确认问题源头
关键工具组合：
| 工具 | 用途 | 关键参数示例 |
|---|---|---|
| stress | 生成可控负载 | -c,--vm,-i |
| dd | 磁盘性能基准测试 | oflag=dsync |
| taskset | CPU亲和性测试 | -c 0-7 |
| mpstat | 处理器级统计 | -P ALL |
| numactl | NUMA架构分析 | --hardware,--show |
5. 预防措施与优化建议
针对这类"假空闲"问题，我后来在监控系统中增加了以下指标：
- 磁盘响应延迟：而不仅仅是IOPS
# 监控磁盘await时间 $ iostat -x -d vda | awk 'NR>3 {print $10}'- NUMA平衡度：
$ numastat | grep Node | awk '{print $4/$2}'- 真实CPU利用率：
# 计算非空闲时间占比 $ mpstat 1 1 | awk '$12 ~ /[0-9.]+/ {print 100 - $12}'这些指标与传统的CPU%、内存%结合，才能真实反映系统健康状态。