Linux 系统实时监控：从 htop 到 iostat、mpstat 与 ss 的性能观测工具

CPU 飙到 100%、内存吃紧、磁盘读写慢、端口连不上——服务器出问题时，运维第一件事就是"看监控"。本文用真实服务器环境，逐条实测 Linux 上最常用的实时监控命令，从最上层的总览到底层的单核、磁盘、网络逐层下钻，帮你快速定位瓶颈在哪。

先来一张总览：uptime 与 free

监控的第一步不是背参数，而是先回答两个问题：系统有多忙（负载）和内存还够不够（剩余量）。两条命令就能给出答案。

uptime && free -h

图中的 load average: 0.00, 0.00, 0.00 是 1 分钟、5 分钟、15 分钟三个时间窗口的平均负载。这台演示机是 2 核 CPU，负载低于 2 说明队列基本空闲；如果长期接近或超过核心数（2），说明 CPU 已经排满队了。负载是瞬时快照，更准确的看 5 分钟和 15 分钟两条曲线的趋势。

free -h 里要注意的不是 free 那一列，而是 available 这一列。Linux 会用空闲内存做缓存（buff/cache 那一列 1.0Gi），所以"真实可用"要看 available（1.3Gi），而不是裸的 free（506Mi）。Swap: 2.5Gi 表示交换分区总量，used 105Mi 说明有少量内存被换出，暂时不紧张。

实时看板：vmstat

如果你只能记住一个实时监控命令，那就是 vmstat。它用一行列出进程、内存、交换、IO、系统、CPU 六类指标，1 3 表示每 1 秒采集一次、共采集 3 次。

vmstat 1 3

看到这行输出，逐个字段排查：

图中前两列 r 为 0、id 为 100，说明当前几乎空闲。运算规则：先看 wa 是不是高——高则磁盘瓶颈；再看 r 是不是接近核心数——是则 CPU 瓶颈；最后看 si/so 是否频繁硬交换——是则内存不足。

磁盘 I/O 下钻：iostat

vmstat 只能告诉你"磁盘可能在忙"，具体是哪个磁盘、读写多快、队排多长，要靠 iostat。它是 sysstat 工具包的一员，-x 输出扩展（详细）统计。

iostat -x 1 2

先看顶部的 avg-cpu 一行，%idle 为 100，CPU 不忙。重点看下面的 Device 设备表，每个块设备一行（loop0~loop13 是镜像设备，可忽略，真正的数据盘看 vda 和 zram0）。看 vda 那一行的关键列：

• r/s w/s：每秒读/写请求次数（图中 vda 为 2.76，很低）
• rkB/s wkB/s：每秒读/写吞吐，反应实际流量
• r_await w_await：单次读/写请求的平均等待时间（毫秒）
• %util：设备忙碌时间占比，> 70% 通常意味着磁盘饱和

判断规矩：%util 高且 await 高，说明磁盘确实忙不过来；%util 高但 await 低，说明磁盘吞吐够、只是请求密——两者处理方向完全不同（前者考虑加盘或换 SSD，后者考虑优化应用批量读写）。

单核视角：mpstat

vmstat 是"所有 CPU 平均"的视角。但多核机器上常常只有个别核心被打满，平均数一平均就看不出问题了。这时用 mpstat -P ALL 逐个核心看。

mpstat -P ALL 1 2

-P ALL 会列出每个 CPU 核心（CPU 0、CPU 1 …）各自的占用率，all 行是所有核心平均。如果看到某几个核心 %usr 持续 100 而其他核心空闲，说明是单线程热点或进程没用好多核，而不是整机过载。日常不带 -P 运行 mpstat 1 2 只看平均，和 vmstat 的 CPU 列类似，用来确认"整体有没有瓶颈"。

内存与交换：free 的完整解读

前面 uptime && free -h 只是快照，Linux 内存判读有几个容易误解的点：

free -m          # 以 MB 显示，避免 h 取整误差
cat /proc/meminfo | head -5

第一张图里 buff/cache 占了 1.0Gi，这是 Linux 用空闲内存预读磁盘/文件缓存，可随时被回收，所以 available = free + 大部分 buff/cache。判断内存是否吃紧，主要看两处：available 是否长时间接近 0，以及 Swap 的 si/so（见 vmstat）是否频繁换页。只要 available 还有余量、没有大量硬交换，就还不能说内存不够。

端口与连接：ss 与 netstat

前面全是 CPU / 内存 / 磁盘，网络维度的第一手工具是 ss（新版推荐，替代老牌的 netstat）。服务"连不上、起了没"先从端口查起。

ss -s      # 汇总各种连接状态数量
ss -tlnp   # 列出当前监听的 TCP 端口及对应进程

ss -s 的 TCP: 14 (estab 4, …) 表示 14 条 TCP 中 4 条已建立连接；ss -tlnp 的 State=LISTEN 条目就是正在监听的端口，Process 一列能看到是谁（如 sshd、nginx）占用的。旧系统没有 ss 时用等价的 netstat -tulnp，输出大同小异。判断规则：服务端口没出现在 LISTEN 里 → 进程没起或没绑定；出现了但连不上 → 问题在防火墙（nftables/iptables）而非服务本身。

sysstat 全家桶：sar 的历史数据

上面的命令都只能看"当下"或"接下来几秒"。要回看昨天某一时刻的 CPU 占满是因为什么，需要 sar（History 历史回放）。sysstat 默认每 10 分钟自动记录一份系统快照到 /var/log/sysstat。

sar -u                       # 历史 CPU 使用率
sar -r                       # 历史内存、交换
sar -b                       # 历史磁盘 IO

这些命令在故障已经过去之后特别有用：出问题时现场没盯着，事后靠 sar 回放定位是几点、哪个指标先异常。sar -u 的输出列（%user、%system、%idle 等）和前面 vmstat、iostat 的字段一一对应，掌握了实时命令，回看历史数据零上手成本。

组合一套排查流程

把上面的命令串起来，就是一个完整的"从外到内"排查链：

uptime            # ① 负载高不高
free -h           # ② 内存 / 交换余量
vmstat 1 5        # ③ r 队列 / wa / si so，判断瓶颈大类
iostat -x 1 3     # ④ 确认是不是磁盘
mpstat -P ALL 1 3 # ⑤ 确认是不是单核热点
ss -tlnp          # ⑥ 网络层，服务端口与连接

每次 top/ps 定位出"具体是哪个进程"（可参考本博客的进程与性能排查，再用组合监控确认"整体影响面"，这样定位问题既不盲人摸象，也不漏掉波及范围。

参考资料

• vmstat 手册：各字段官方定义
• iostat 手册：块设备统计字段说明
• ss 手册：套接字统计与查询选项
• sysstat 官方文档：iostat / mpstat / sar 的来源