Linux系统性能监控与瓶颈排查的核心命令汇总

知识点简介

服务器出问题，能最快定位根因的能力就是性能监控。Linux 自带了一套性能诊断工具链，覆盖 CPU、内存、磁盘 IO、网络四大维度。掌握这些命令，可以在不装任何第三方工具的情况下，快速回答：「系统到底卡在哪？」

核心命令整理

1. CPU 监控

top 关键字段说明：

• us — 用户态 CPU 占比
• sy — 内核态 CPU 占比（过高说明系统调用密集）
• wa — I/O 等待（过高 → 磁盘有瓶颈）
• id — 空闲百分比
• st — 被虚拟机偷走的 CPU（VM 环境常见）

2. 内存监控

CPU + 内存二合一： 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 123456  1024 456789    0    0    12    34  567  890 12  3 85  0  0

• r：正在运行的进程数（CPU 排队），大于 CPU 核数说明 CPU 是瓶颈
• b：阻塞在 I/O 的进程数（磁盘或网络）
• si / so：swap 换入/换出，持续不为 0 → 内存不足

3. 磁盘 I/O 监控

iostat 关键指标（关注点）：

• %util — 磁盘繁忙率（> 80% 为瓶颈）
• r/s + w/s — 每秒读写次数（IOPS）
• rkB/s + wkB/s — 每秒吞吐量
• await — I/O 平均等待时间（ms），越大越慢
• svctm — I/O 服务时间（越接近 await 说明磁盘本身慢）

4. 网络监控

5. 历史回溯（sar 神器）

sar 是 sysstat 包提供的系统活动报告器，可以回溯过去的数据。

# 查看今天整天的 CPU 使用率sar -u# 查看内存使用sar -r# 查看磁盘 I/Osar -b# 查看网络流量sar -n DEV

排查顺序建议： CPU 负载 → 内存使用 → 磁盘 I/O → 网络 → 应用日志 — 逐层排查，不要跳跃。

实操示例：5 分钟定位服务器卡顿

场景： 接到告警，某 Web 服务器响应变慢，SSH 进去操作有延迟感。

# 第一步：看整体负载uptime# 输出：load average: 8.12, 6.34, 3.21  → 8核CPU，负载超8，异常# 第二步：看 CPU 分布top -bn1 | head -5# wa 飙到 35% → I/O 瓶颈# 第三步：查磁盘 I/Oiostat -x 1 3# sda:  %util 92%, await 450ms → 磁盘扛不住了# 第四步：定位哪个进程在写磁盘iotop -o -P# 发现 mysqld 进程正在大量写数据# 第五步：确认 mysql 具体问题mysql -e "SHOW PROCESSLIST;"# 发现一条慢查询锁表导致大量写入# 结论：慢 SQL 锁表 → 数据库夯住 → 磁盘写入堆积 → 系统响应变慢

常见坑点 & 注意事项

1. free -m 看到的 used 不等于真实占用 — Linux 用空闲内存做缓存（buff/cache），当应用需要时内核会释放，所以看 available 列而不是 free 列
2. top 的 %CPU 可能超过 100% — 这是多核累加值，单进程跑满 8 核显示 800%
3. 磁盘 %util 到 100% 不一定是瓶颈 — SSD 高 IOPS 场景下 100% 持续是正常的，要结合 await 看（超过 50ms 才报警）
4. vmstat 的 r 列 > CPU 核数 × 2 — 说明 CPU 排队严重，需要扩容或优化
5. 不要只看瞬时值 — 用 sar 看趋势，或者用 vmstat 1 10 看 10 个采样点的平均值
6. 别忘了系统日志 — dmesg | tail 和 /var/log/messages 经常藏着 OOM、磁盘 I/O error 等关键线索

一句话总结： 性能排查三板斧 — uptime 看负载，top 看分布，iostat / vmstat 定维度。找到短板，对症下药。