Linux系统性能瓶颈综合分析_多维指标解析【教程】

Linux 性能瓶颈需综合多指标关联分析：CPU 高但响应不卡应查 runq-sz 和 cs；iostat 中 r_await/w_await 差异定位读写瓶颈；pgpgin/pgpgout 持续>10M/ s 提示隐性内存压力；TCP 重传需 netstat 与 ss 联合分析。

Linux 系统 性能瓶颈 不能靠单个指标判断，top 看 CPU 高 ≠ 真正的瓶颈，iostat 显示 %util 100% 也不一定代表磁盘慢——关键在指标间的关联性与时间维度上的变化趋势。

CPU 高但响应不卡？先看 runq-sz 和 cs 是否同步飙升

CPU 使用率高，服务却没明显延迟，大概率是任务在就绪队列里排队，而非真正在执行。这时候要查运行队列长度和上下文切换次数：

• vmstat 1 中关注 runq-sz（就绪队列长度）：持续 > CPU 核数 × 2，说明有大量任务等待调度
• cs（context switch/sec）异常高（比如 > 50k/s），配合 pidstat -w 1 查具体进程，常指向频繁唤醒、锁竞争或短生命周期线程泛滥
• 注意区分 sy（system time）占比：若远高于 us，问题往往出在内核态，如中断处理、内存回收或驱动阻塞

iostat -x 1 里 await 和 r_await/w_await 的差异必须分清

await 是请求从发出到完成的平均耗时（含排队 + 服务时间），但它掩盖了读写行为的不对称性：

• r_await 高但 w_await 正常 → 读密集型瓶颈，可能缺缓存、随机读多、或存储介质（如 HDD）响应差
• w_await 高且 %util 接近 100% → 写限流或 后端 存储吞吐见顶；但若 %util 低而 w_await 高，更可能是文件系统层问题（如 XFS 日志阻塞、ext4 barrier 开启 + 机械盘）
• avgqu-sz 持续 > 1 表示 I/O 请求长期积压，此时 await 失去参考价值，应结合 blktrace 或 iosnoop 定位具体设备 / 请求模式

内存看似充足，pgpgin/pgpgout 却持续走高？警惕隐性换页压力

free -h 显示可用内存充足，不代表没有内存压力。真正危险的是内核频繁进行页面换入换出：

• 用 vmstat 1 观察 pgpgin（每秒换入 KB）和 pgpgout（每秒换出 KB）：持续 > 10M/s 是强信号
• 即使 si/so（swap in/out）为 0，pgpgin 高也意味着应用在反复申请 / 释放内存，触发直接回收（direct reclaim），拖慢分配路径
• 配合 slabtop 看 kmalloc-* 或 dentry 占用是否异常，常见于未关闭 vm.swappiness=0 时的脏页回写竞争，或容器环境未设 memory.limit_in_bytes

netstat -s 和 ss -i 联合看 TCP 重传，别只盯 retransmit 总数

TCP 重传率升高不等于网络丢包，可能是本地拥塞控制、接收窗口不足或应用读取延迟导致：

• netstat -s | grep -i "retransmitted" 给总量，但需结合 ss -i 查单连接的 retrans 字段，确认是否集中在少数长连接上
• 若某连接 retrans 高且 rcv_space 小（如 ss -m 可见 rcv_rtt 异常大
• tcprcvdatanotimeout（来自 /proc/net/snmp）突增，大概率是应用层 ACK 延迟，而非链路问题

watch -n 1 'echo"=== CPU ==="; vmstat 1 2 | tail -1; echo"=== IO ==="; iostat -x 1 2 | tail -1; echo"=== MEM ==="; vmstat 1 2 | tail -1 | awk"{print $9,$10,$11,$12}"; echo"=== NET ==="; ss -i | grep -v"State"| head -3'

多维指标不是堆在一起看，而是按「请求路径」串起来：用户请求 → CPU 调度 → 内存分配 → 存储 I/O → 网络收发。漏掉任一环节的时间戳对齐（比如用 perf record -e sched:sched_switch 同步抓取），就容易把果当因。