14_性能监控：Linux 系统 “健康体检” 手册

性能监控：Linux 系统 “健康体检” 手册

就像人需要定期体检一样，Linux 服务器也需要 “健康监控”—— 当用户反馈 “访问变慢”“操作卡顿” 时，若能提前通过监控发现 CPU、内存、I/O 的异常，就能避免故障扩大。今天这篇 “体检手册”，从 “基础实时监控” 到 “进阶历史分析”，再到 “瓶颈定位调优”，带你掌握 Linux 性能监控的核心工具与方法，让你成为系统的 “健康管家”。

一、基础体检：用 top/htop/free/vmstat 做 “实时快照”

基础监控工具就像 “体温计”，能快速获取系统当前的 “健康指标”——CPU 使用率、内存占用、I/O 状态，适合实时排查 “当下是否有问题”。

1. top/htop：实时监控 “全能工具”

top是 Linux 自带的实时监控工具，htop是它的 “增强版”（支持鼠标操作、颜色区分），两者核心功能一致，重点关注CPU、内存、进程三大维度。

（1）top 核心用法与指标解读

\# 启动top（默认每3秒刷新一次）

top

关键界面解读（新手必看 5 列）：

区域 / 列名	含义	健康阈值	异常判断标准
顶部 CPU 行	%us（用户进程占比）、%sy（系统进程占比）、%id（空闲占比）	%id≥30%、%us≤70%、%sy≤30%	%id＜10%（CPU 繁忙）、%sy＞50%（内核占用过高）
顶部 Mem 行	total（总内存）、used（已用）、free（空闲）、buff/cache（缓存）	available（实际可用）≥总内存 10%	available＜5%（内存紧张）、buff/cache占比＞80%（缓存过多可临时清理）
进程列 PID	进程唯一 ID	-	高 CPU / 内存进程的 PID（后续定位用）
进程列 %CPU	进程占用 CPU 百分比	单个进程≤30%（非核心服务）	非核心进程持续＞50%（可能是异常进程）
进程列 %MEM	进程占用内存百分比	单个进程≤20%（非核心服务）	非核心进程持续＞40%（可能是内存泄漏）

常用操作：

• 按P：按 CPU 占用降序排序（找 “吃 CPU” 的进程）；

• 按M：按内存占用降序排序（找 “吃内存” 的进程）；

• 按k：输入 PID 后按回车，再输9（强制关闭异常进程）；

• 按q：退出 top。

（2）htop 增强体验（推荐新手使用）

htop比top更直观，支持鼠标点击排序、进程树查看，安装与使用：

\# Ubuntu安装

sudo apt install htop -y

\# CentOS安装

sudo dnf install htop -y

\# 启动htop

htop

核心优势：

• 用颜色区分 CPU 状态（蓝色：低优先级进程、绿色：用户进程、红色：系统进程）；

• 右侧实时显示 CPU 核心、内存、交换分区的使用率曲线；

• 鼠标点击 “% CPU”“% MEM” 列即可排序，无需记快捷键。

2. free/vmstat：聚焦内存与 I/O 的 “专项检查”

top是 “全能工具”，free和vmstat则是 “专项工具”—— 前者专注内存，后者兼顾内存与 I/O，适合深入分析资源瓶颈。

（1）free：读懂内存 “真实可用量”

新手常被free的 “used 高、free 低” 误导，其实关键看available（实际可用内存，含可回收缓存）：

\# 用-h参数（human-readable）显示GB/MB，更直观

free -h

输出解读（以 16GB 内存为例）：

                total        used        free      shared  buff/cache   available

Mem:           15Gi       6.2Gi       2.1Gi       384Mi       6.7Gi       8.3Gi

Swap:          15Gi          0B       15Gi

• 健康判断：available=8.3Gi（占总内存 55%），Swap used=0，内存状态健康；

• 异常信号：available＜1.5Gi（＜10%）、Swap used持续增长，需警惕内存不足。

（2）vmstat：监控内存与 I/O 的 “联动变化”

vmstat能显示内存交换（si/so）、磁盘 I/O（bi/bo）的实时变化，适合判断 “是否因 I/O 拖累内存 / CPU”：

\# 每2秒输出1次，共输出5次（观察趋势）

vmstat 2 5

核心列解读（新手重点看 4 列）：

列名	含义	健康阈值	异常判断标准
si	从 Swap 读入内存的大小（KB / 秒）	si≈0	持续＞100KB / 秒（内存不足，频繁读 Swap）
so	从内存写入 Swap 的大小（KB / 秒）	so≈0	持续＞100KB / 秒（内存不足，被迫写 Swap）
bi	从块设备读入数据（KB / 秒）	无固定阈值，看业务波动	持续＞1000KB / 秒且%util（磁盘使用率）＞80%（I/O 繁忙）
bo	写入块设备的数据（KB / 秒）	无固定阈值，看业务波动	持续＞1000KB / 秒且%util＞80%（I/O 繁忙）

二、进阶体检：用 sar/iostat/nmon 做 “历史回溯与报表”

基础工具只能看 “当下”，若要排查 “昨天下午 3 点为何卡顿”“上周内存占用峰值是多少”，就需要历史数据分析工具——sar（系统活动报告）、iostat（I/O 统计）、nmon（报表生成），帮你回溯历史数据、生成可视化报表。

1. sar：“全能历史记录者”（CPU / 内存 / I/O 全记录）

sar是 Linux 性能监控的 “瑞士军刀”，能周期性采集系统活动数据，支持事后回溯，默认安装在大部分系统中。

（1）核心用法：采集与查看历史数据

\# 1. 实时采集（每5秒采集1次，共采集10次，输出到终端）

sar 5 10

\# 2. 采集并保存数据（每5秒采集1次，共10次，保存到sar.log）

sar 5 10 -o sar.log

\# 3. 查看历史数据（从sar.log中查看CPU使用情况）

sar -f sar.log -u  # -u：查看CPU相关数据

（2）常用场景与参数组合

监控目标	命令	关键指标解读
CPU 历史占用	sar -f sar.log -u	%idle（空闲占比）：若某时段＜10%，说明当时 CPU 繁忙
内存历史占用	sar -f sar.log -r	%memused（内存使用率）：持续＞90% 需警惕内存不足
磁盘 I/O 历史	sar -f sar.log -b	tps（每秒 I/O 次数）、rtps（每秒读次数）：异常高峰对应 I/O 繁忙时段
网络流量历史	sar -f sar.log -n DEV	rxpck/s（每秒接收包数）、txpck/s（每秒发送包数）：异常增长可能是网络攻击

（3）实战：回溯 “昨天下午 3 点的 CPU 异常”

\# 1. 查看系统默认保存的sar历史数据（CentOS默认存于/var/log/sa/，Ubuntu需手动配置）

ls /var/log/sa/  # 输出如sa25（25日的数据）

\# 2. 查看25日15:00-15:30的CPU数据（-s指定开始时间，-e指定结束时间）

sar -f /var/log/sa/sa25 -u -s 15:00:00 -e 15:30:00

\# 3. 解读结果：若15:10-15:15的%idle＜5%，说明当时CPU繁忙，再结合top历史进程排查

2. iostat：I/O 性能的 “专项分析师”

sar是 “全能工具”，iostat则专注于磁盘 I/O 监控，能精准定位 “哪个磁盘最繁忙”“哪个进程在频繁读写”，适合排查 “I/O 瓶颈导致的卡顿”。

（1）基础用法：查看磁盘 I/O 状态

\# 安装iostat（属于sysstat包）

sudo apt install sysstat -y  # Ubuntu

sudo dnf install sysstat -y  # CentOS

\# 查看所有磁盘的I/O统计（-x：显示详细指标，-k：以KB为单位）

iostat -x -k

（2）关键指标解读（判断磁盘是否繁忙）

指标名	含义	健康阈值	异常判断标准
%util	磁盘繁忙百分比（I/O 时间占比）	≤60%	持续＞80%（磁盘 I/O 饱和，是卡顿主因）
rMB/s	每秒读数据量（MB）	无固定阈值，看磁盘性能	远超磁盘标称读写速度（如机械盘＞100MB/s）
wMB/s	每秒写数据量（MB）	无固定阈值，看磁盘性能	远超磁盘标称读写速度
avgqu-sz	平均 I/O 队列长度	≤2	持续＞5（I/O 请求排队过多，磁盘处理不过来）

（3）进阶：定位 “繁忙磁盘对应的进程”

当iostat发现/dev/sdb的%util=95%（I/O 饱和），用iotop找对应的读写进程：

\# 安装iotop

sudo apt install iotop -y  # Ubuntu

sudo dnf install iotop -y  # CentOS

\# 启动iotop（按P显示进程PID，按O只显示有I/O活动的进程）

sudo iotop -P -O

输出中 “DISK READ”“DISK WRITE” 列数值高的进程，就是导致磁盘繁忙的 “元凶”（如PID=1234的mysql进程频繁写数据）。

3. nmon：性能报表的 “自动生成器”

对于需要输出 “监控报表” 的场景（如给领导汇报、故障复盘），nmon是最佳选择 —— 它能实时监控 CPU、内存、I/O、网络，还能生成 CSV 格式报表，方便后续用 Excel 或 Python 分析。

（1）安装与启动 nmon

\# Ubuntu安装

sudo apt install nmon -y

\# CentOS安装

sudo dnf install nmon -y

\# 启动nmon（默认显示系统概览）

nmon

（2）核心操作：查看不同资源与生成报表

需求	操作	说明
查看 CPU 详情	按c键	显示各 CPU 核心的使用率、等待时间等
查看内存详情	按m键	显示内存使用、Swap 使用、缓存情况
查看磁盘 I/O 详情	按d键	显示各磁盘的读写速度、繁忙百分比
查看网络详情	按n键	显示各网卡的接收、发送流量
生成 CSV 报表	启动时加-f -s 5 -c 720参数	nmon -f -s 5 -c 720：每 5 秒采集 1 次，共 720 次（1 小时），生成 nmon_日期_时间.csv 文件

（3）报表分析：用 Excel 可视化

1. 找到生成的 CSV 文件（如nmon_20241025_1400.csv）；

2. 用 Excel 打开，按 “数据→分列→逗号分隔” 拆分数据；

3. 选中 CPU 使用率、内存使用率列，插入 “折线图”，即可直观看到 1 小时内的性能趋势（如 14:30-14:40 CPU 使用率骤升）。

三、调优实战：CPU / 内存 / I/O 瓶颈定位与解决

监控的最终目的是 “解决问题”—— 当发现 CPU、内存、I/O 异常时，需结合进程、内存、网络管理知识，定位瓶颈根源并优化。

1. 瓶颈 1：CPU 使用率 100%（系统卡顿、响应慢）

定位步骤：

1. 找高 CPU 进程：用top按P排序，找到%CPU持续＞80% 的进程（如PID=4567的java进程）；

2. 看进程是否异常：用ps aux | grep 4567查看进程命令（如java -jar app.jar，是业务应用还是异常脚本）；

3. 查线程级占用：若进程是多线程（如 Java、Nginx），用pidstat -t -p 4567 2 3查看线程占用，定位到具体繁忙线程（%CPU高的线程 ID）；

4. 分析线程用途：Java 进程可结合jstack 4567查看线程栈，判断是否有死循环、频繁 GC（垃圾回收）。

解决方法：

• 若为异常进程（如病毒、测试脚本）：sudo kill -9 4567强制关闭；

• 若为业务进程（如 Java 应用）：

  • 临时：重启进程（sudo systemctl restart app）缓解；

  • 长期：优化代码（如修复死循环、减少 CPU 密集型操作）、升级 CPU 或增加核心数。

2. 瓶颈 2：内存泄漏（内存占用持续增长、Swap 频繁使用）

定位步骤：

1. 确认内存趋势：用sar -f sar.log -r查看内存使用率，若%memused从 50% 持续涨到 90%，且无下降，怀疑内存泄漏；

2. 找泄漏进程：用top按M排序，找到%MEM持续增长的进程（如PID=7890的python脚本）；

3. 验证泄漏：用ps aux --sort=-%mem | grep 7890观察进程内存变化，1 小时后VSZ（虚拟内存）、RSS（物理内存）明显增长，确认泄漏。

解决方法：

• 临时：重启泄漏进程（sudo kill -15 7890，正常关闭避免数据丢失）；

• 长期：排查代码（如 Python 脚本未释放数据库连接、Java 静态集合未清理），或用valgrind（C/C++）、jmap+jhat（Java）分析内存泄漏点。

3. 瓶颈 3：磁盘 I/O 饱和（%util＞90%、读写卡顿）

定位步骤：

1. 找繁忙磁盘：用iostat -x -k找到%util高的磁盘（如/dev/sdc）；

2. 找对应进程：用iotop -P -O找到读写该磁盘的进程（如PID=3456的rsync备份进程）；

3. 分析 I/O 类型：用sar -f sar.log -b查看是 “读多” 还是 “写多”（rtps高是读瓶颈，wtps高是写瓶颈）。

解决方法：

• 若为临时任务（如rsync备份）：调整任务时间（避开业务高峰）；

• 若为业务进程（如 MySQL）：

  • 优化存储：将机械盘换成 SSD（提升读写速度 10 倍以上）；

  • 优化 I/O 操作：MySQL 开启缓存（innodb_buffer_pool_size调大）、减少频繁小文件读写（合并成大文件）；

  • 分散 I/O：将数据分散到多块磁盘（如用 LVM 或 RAID 10）。

四、避坑指南：3 个监控常见误区

1. 误区 1：只看单一指标，忽略联动分析

表现：看到 CPU 使用率 100%，直接杀死高 CPU 进程，却没发现是磁盘 I/O 饱和导致 CPU 等待（%wa高）。

正确做法：CPU 异常时，结合vmstat看%wa（I/O 等待时间占比），若%wa＞20%，先解决 I/O 瓶颈（如优化磁盘读写），再看 CPU 是否恢复。

2. 误区 2：过度依赖实时监控，不存历史数据

表现：故障发生后，才发现没保存历史数据，无法回溯 “故障前的指标变化”。

正确做法：配置sar自动采集历史数据（CentOS 默认开启，Ubuntu 需编辑/etc/cron.d/sysstat，设置5-59/10 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1，每 10 分钟采集 1 次）。

3. 误区 3：用 “默认阈值” 判断所有系统

表现：认为 “CPU% idle＜10% 就是异常”，但数据库服务器正常业务下%idle常＜5%。

正确做法：结合 “业务场景” 定阈值 —— 数据库服务器 CPU 繁忙是常态，重点看%wa（I/O 等待）；Web 服务器则需%idle≥30%，避免用户访问卡顿。

总结：Linux “健康体检” 核心流程

1. 日常巡检：用htop看实时状态，用nmon生成日报表，重点关注 CPU% idle、内存 available、磁盘 % util；

2. 故障排查：

• 卡顿先看top（找高 CPU / 内存进程）；

• 慢响应查iostat（看 I/O 是否饱和）；

• 历史问题用sar回溯（定位故障时段指标）；

1. 瓶颈调优：CPU 看线程、内存查泄漏、I/O 找磁盘，结合业务场景优化（临时重启 vs 长期代码 / 硬件优化）。

掌握这套 “体检手册”，你就能从 “被动救火” 变成 “主动预防”，让 Linux 服务器始终保持 “健康状态”，减少因性能问题导致的业务中断。