Linux系统性能监控与调优实战：从top、vmstat到iostat的全链路诊断

为什么需要系统性能监控？

在生产环境中，服务器响应变慢、CPU 占用飙升、内存不足等问题时有发生。面对这些情况，与其盲目重启服务或扩容，不如先依靠 Linux 自带的系统性能诊断工具快速定位瓶颈。本文将围绕 top、vmstat、iostat 三大核心工具，带你掌握一套系统化的性能分析方法：如何读懂各项指标、如何找出异常进程、如何给出针对性的优化方案。

一、top —— 实时全局态势感知

1.1 常用交互操作

# 按 P 键：按 CPU 使用率排序
# 按 M 键：按内存使用率排序
# 按 1 键：展示每个 CPU 核心的负载
top

1.2 关键指标解读

读到 top 输出时重点关注 load average 三个值：

load average: 0.15, 0.10, 0.05

含义：分别代表系统 1 分钟、5 分钟、15 分钟内平均处于可运行与不可中断等待状态的进程数。

• 若 1 分钟值远大于 15 分钟值 → 负载正在上升（需警惕）
• 若 15 分钟值持续大于 CPU 核心数 → 存在长期过载

关键数据行说明：

• %id (idle)：空闲百分比，持续低于 20% 需排查 CPU 瓶颈
• %wa (iowait)：I/O 等待占比，持续高于 30% 意味着磁盘读写成为瓶颈
• RES (resident)：进程实际占用的物理内存

1.3 实战：找出异常进程

# 观察单个进程
top -p 12345
# 批量观察 Web 工作进程
top -p $(pgrep -d',' php-fpm)
# 快速拍下当前进程快照供复盘
top -b -n 3 > /tmp/top_snapshot.txt

1.4 输出重定向与日志

由于 top 默认使用 ncurses 交互模式，更适合短期观察。长期监控可以改用 sar（sysstat 包提供，可每小时采集并晨报汇总）、pidstat（针对单个进程的详细采样）或 glances（面向 Web 的可视化监控界面）。

二、vmstat —— 内存/交换/中断的综合快照

2.1 命令格式

vmstat 2 10

2.2 核心列解读

procs  -----memory-----   --swap--   -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si  so    bi    bo   in   cs us sy wa id
 2  0      0 512000 200000 1500000   0   0     5    10  200 1500 10  2  1 87

• r (running)：等待 CPU 的进程数，长期大于 CPU 核心数说明 CPU 不够用
• b (blocked)：不可中断睡眠（通常等待磁盘 I/O），反映磁盘压力
• si/so (swap in/out)：非零即说明物理内存开始使用交换分区，性能将急剧下降
• bi/bo (block in/out)：磁盘读写块数，结合 b 列判断是否为磁盘瓶颈

2.3 实战场景：判断服务器是否内存不足

持续采样并观察 si/so 两列：

vmstat 5 12 | awk '{print $3, $4}' > /tmp/vmstat_swap.log

若 si 与 so 持续大于 0，可进一步通过 free -h 看剩余可用内存，再用 top 定位消耗内存最多的进程。

三、iostat —— 磁盘 I/O 专项诊断

3.1 安装与基本用法

apt install sysstat    # Debian/Ubuntu
yum install sysstat    # CentOS/RHEL
iostat -xz 2

3.2 关键指标解读

• r/s、w/s：每秒读/写请求数（IOPS）
• rkB/s、wkB/s：每秒读/写千字节数
• avgqu-sz：平均 I/O 队列长度，持续大于 1 说明磁盘繁忙
• await：单个 I/O 请求从发出到完成的总时间
• %util：磁盘资源利用率，接近 100% 表示磁盘已饱和

3.3 实战：MySQL 写库 I/O 100% 排查

现象: iostat 显示 sdb 设备 %util 持续 99%，avgqu-sz 大于 50，而 MySQL 慢查询明显增多。

排查思路：

1. 确认是读瓶颈还是写瓶颈：iotop 按 kB_write 排序，定位是否为大范围写入进程
2. 检查 MySQL 缓冲池：查看 Innodb_buffer_pool 命中率，应大于 99%
3. 检查 redo log：适当调大 innodb_log_file_size（例如 1G），减少刷盘频率
4. OS 层级调整：对 HDD 使用 deadline 调度器，SSD 用 none 或 mq-deadline

四、综合诊断五步流程

1. 确认瓶颈类别：top 看 CPU/内存，iostat 看磁盘 I/O
2. 确定可疑进程：top 按 P/M 排序，找到占用资源最高的进程
3. 细化读/写模式：vmstat + iostat 判断是 CPU 不够用还是磁盘跟不上
4. 定位根因语句：针对应用层开启慢日志
5. 给出优化方案：调参数、改索引、扩容、加缓存、换硬件

五、实战优化案例

5.1 案例：4 核 8G Web 服务器 CPU 突升排查

现象: top 中 load average 瞬间达到 12，CPU 使用率 100%。

• top 按 P 排序，发现 8 个 php-fpm 进程 CPU 均超过 80%
• netstat 发现大量 TCP TIME_WAIT
• strace 跟踪发现某个 PHP 脚本陷入死循环
• 修复循环条件后，load 恢复正常

5.2 案例：MySQL 从库同步延迟飙升

• iostat 显示从库磁盘 avgqu-sz 飙升
• 发现业务端一次性写入 5 万行，引发 relay log 回放拥堵
• 拆分大事务为 500 行/批，并行复制 worker 设置为 8
• 延迟恢复到 1 秒以内

六、常用一键脚本

#!/bin/bash
echo '--- CPU / Load ---'  > /tmp/sys_check.log
uptime                     >> /tmp/sys_check.log
echo '--- Memory ---'      >> /tmp/sys_check.log
free -h                    >> /tmp/sys_check.log
echo '--- Disk I/O ---'    >> /tmp/sys_check.log
iostat -xz 1 1             >> /tmp/sys_check.log
echo '--- Top Processes ---' >> /tmp/sys_check.log
top -b -n 1 | head -20     >> /tmp/sys_check.log
echo '--- Connection ---'   >> /tmp/sys_check.log
ss -s                      >> /tmp/sys_check.log
cat /tmp/sys_check.log

七、学习资源推荐

• 《性能之巅》（Systems Performance）—— Brendan Gregg
• Brendan Gregg 博客：火焰图、bcc 工具链
• Linux 内核文档（Documentation/sysctl/）
• sysstat 项目（github.com/sysstat/sysstat）

小结

Linux 性能监控没有万能公式。本文提供的 top / vmstat / iostat 三件套，覆盖了 CPU、内存、磁盘 I/O 三大维度的实时观测。掌握它们之后，你可以再进一步学习 pidstat、perf、tcpdump、bpftrace 等高级工具。记住：监控不是为了好看，而是为了缩短排障时间。把每次性能复盘的结论整理成文档，逐步建立团队的性能基线，才是价值最高的事。