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/O
sar -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/O
iostat -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 定维度。找到短板，对症下药。

到此这篇关于Linux系统性能监控与瓶颈排查的核心命令整理的文章就介绍到这了,更多相关Linux性能监控与瓶颈排查命令内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！