掌握性能：Sysstat 工具集实用指南

当你只能看到当前时刻时，性能工作会变得混乱。服务器现在很慢，但十分钟前也慢吗？磁盘是在 CPU 攀升之前就开始备份了吗？问题是在 cron 任务、部署还是备份窗口之后开始的？sysstat 工具集之所以有用，是因为它既提供实时读数，也提供可供比较的历史记录。

主要工具是 sar，即系统活动报告器。当 top 过于简短、事件已经过去，或者我需要证明问题是存储、内存压力、网络流量还是 CPU 饱和，而不是根据症状猜测时，我会使用它。套件中的其他工具，特别是 iostat 和 mpstat，在 sar 指向可能的瓶颈时补充细节。

这并不能替代完整的可观测性。你仍然需要应用程序指标、日志、追踪和外部检查。但在 Linux 主机上，sysstat 是回答第一个实际问题的最快方法之一：机器实际上在做什么？

1. Sysstat 的安装和初始配置

sysstat 包通常可以在所有主要 Linux 发行版的标准仓库中找到。

1.1 安装命令

根据你的系统使用相应的包管理器命令：

Debian/Ubuntu：

sudo apt update
sudo apt install sysstat

RHEL/CentOS/Fedora：

sudo yum install sysstat
# 或在新系统上使用 dnf
sudo dnf install sysstat

1.2 启用历史数据收集

要使 sar 真正有用，它必须历史地收集数据。默认情况下，安装通常会设置一个 cron 作业或 systemd 定时器，但验证至关重要。

在现代系统上，确保 sysstat 服务处于活动状态：

sudo systemctl enable --now sysstat

配置文件

数据收集的频率由配置文件控制，通常位于 /etc/default/sysstat（Debian/Ubuntu）或 /etc/sysconfig/sysstat（RHEL/CentOS）。查找 ENABLED 或 HISTORY 设置。将 ENABLED="true" 设置为确保每日数据收集。

提示： 默认情况下，sysstat 数据文件存储在 /var/log/sa/ 中，文件名如 saXX，其中 XX 是月份中的日期。一些基于 Debian 的系统也会在 /var/log/sysstat/ 下公开报告。在假设路径之前，请检查你的包默认值。

启用收集后，等待至少一个间隔，并确认文件正在出现：

ls -lh /var/log/sa/

如果目录为空，请检查 systemd 定时器：

systemctl list-timers | grep sysstat
systemctl status sysstat-collect.timer

在较旧的系统上，收集可能仍由 cron 驱动。确切的打包因发行版而异，因此请验证，而不是依赖另一台服务器的记忆。

2. 核心工具：系统活动报告器 (`sar`)

sar 是查看统计信息的主要接口。它可以显示实时数据或分析先前收集的历史数据。

2.1 实时监控的基本语法

基本语法旨在以指定的间隔和定义的次数报告特定指标。

sar [选项] [间隔] [次数]

示例： 每 3 秒报告一次通用 CPU 统计信息，共 10 次：

sar -u 3 10

该命令在事件期间很有用，因为它提供了一个短期的移动样本，而不是一个快照。单行可能会捕捉到一个安静的秒并误导你。三十秒内的十个样本显示模式是稳定的、尖峰的还是已经消失。

选项	描述
`-u`	CPU 利用率（默认）
`-r`	内存和分页统计信息
`-d`	块设备活动（磁盘 I/O）
`-n`	网络统计信息（例如，`-n DEV` 用于接口统计）
`-q`	运行队列和负载平均值
`-W`	交换活动（分页）
`-A`	所有指标（适用于全面快照）

对于历史文件，格式相同。你添加 -f 来选择数据文件，并经常添加 -s 和 -e 来限制时间范围。这很重要，因为在中断期间读取一整天的输出既慢又嘈杂。

3. 关键性能指标和实用的 `sar` 示例

理解 sar 的输出需要了解哪些指标表示性能健康或压力。

3.1 CPU 利用率 (`sar -u`)

CPU 利用率通常是查找瓶颈的首选。跨特定类别的高利用率表明工作负载的性质。

sar -u 5 3

指标	描述	瓶颈指示器
`%user`	运行用户级进程所花费的 CPU 时间。	高表示应用程序/服务饱和。
`%system`	运行内核/系统任务所花费的 CPU 时间。	高表示密集的系统调用或驱动程序问题。
`%iowait`	等待 I/O 操作（磁盘/网络）时空闲的 CPU 时间。	高表示 I/O 瓶颈，而非 CPU 短缺。
`%idle`	空闲等待的 CPU 时间（可用）。	低（例如，< 5%）表示 CPU 饱和。

小心 %iowait。它常被误读为“CPU 忙于处理磁盘”。它实际上意味着 CPU 在至少有一个 I/O 请求未完成时空闲。高值可能指向存储延迟，但需要与磁盘指标确认。例如，在数据库服务器上，高 %iowait 加上高磁盘 await 是比单独的 %iowait 强得多的信号。

另一个有用的 CPU 视图是运行队列：

sar -q 5 5

runq-sz 显示有多少任务在等待运行。如果负载平均值很高，但 runq-sz 适中且 %iowait 很高，你可能看到的是阻塞的 I/O 而不是纯粹的 CPU 压力。如果 runq-sz 保持高位且 %idle 接近零，机器可能需要更少的可运行进程、更快的代码或更多的 CPU 容量。

3.2 内存和分页 (`sar -r` 和 `sar -W`)

内存统计信息既揭示了消耗情况，也显示了系统是否正在诉诸交换或分页。

内存利用率 (sar -r)：

sar -r 1 5

关注 kbavail（可用内存）。如果 kbmemfree 很低，但 kbcached 和 kbbuffers 很高，则内存正被内核的缓存机制有效利用。

交换活动 (sar -W)：

sar -W 1 5

查看 pswpin/s（换入的页面数）和 pswpout/s（换出的页面数）。这里的任何显著非零值都表明系统正在积极交换，表示内存压力（一个强瓶颈）。

Linux 内存输出可能看起来令人担忧，直到你记住缓存不是浪费的内存。一个 kbmemfree 非常少的服务器可能仍然健康，如果 kbavail 充足且交换活动安静。危险模式不同：可用内存下降，换入和换出活动出现，应用程序延迟攀升。这告诉你进程正在访问不再适合 RAM 的内存。

对于 Web 服务器，这可能在部署意外增加工作进程数量后发生。对于批处理主机，可能在两个大型作业重叠时发生。sar 不会告诉你哪个进程导致了它，但它提供了时间线。将其与 ps、top、服务日志或 cgroup 指标结合使用，以识别所有者。

3.3 磁盘 I/O 活动 (`sar -d`)

监控磁盘活动对于数据库服务器或高负载存储系统至关重要。

sar -d 3 5

此输出需要识别特定设备（例如，sda、vda）。关键指标包括：

tps：每秒传输次数（高值表示高 I/O 请求）。
rd_sec/s 和 wr_sec/s：每秒读取/写入的数据量。
%util：设备忙于处理请求的时间百分比。如果在传统块设备上 %util 保持在 100% 附近，存储可能已饱和。

在现代 SSD 和虚拟磁盘上，%util 需要上下文。一些设备可以很好地处理并行 I/O，而云卷可能受限于预置的 IOPS、吞吐量或突发积分。将 %util 视为进一步检查的提示，而不是完整的诊断。如果你在 AWS、Azure、GCP 或其他虚拟化环境中，请使用 iostat -xd、应用程序延迟和平台级存储指标进行确认。

一个实用的工作流程是：

sar -d -f /var/log/sa/sa24 -s 09:00:00 -e 10:00:00
iostat -xd 2 5

使用 sar 找到糟糕的小时，然后在实时复发期间使用 iostat 检查设备级延迟。

3.4 网络统计信息 (`sar -n`)

sar 可以报告跨各种网络层的活动。最常见的检查是接口活动 (DEV)。

sar -n DEV 5 1

此命令显示每个网络接口的指标，如 rxpk/s（每秒接收的数据包数）和 txkB/s（每秒传输的千字节数）。使用它来识别经历高负载或潜在错误的接口。

对于错误计数器，添加 EDEV：

sar -n EDEV 5 3

这可以显示接收错误、传输错误、丢弃和冲突（如果驱动程序支持）。当服务抱怨间歇性超时但 CPU 和磁盘看起来正常时，丢弃尤其有用。如果丢弃在流量高峰期间上升，你可能需要检查 NIC 队列、内核网络设置、容器网络或负载均衡器路径。

对于 TCP 级别的行为，尝试：

sar -n TCP,ETCP 5 3

重传、重置和失败的连接尝试可以将模糊的“网站很慢”报告转变为更具体的网络或上游问题。

4. 历史分析和基线创建

sysstat 的真正力量在于其分析长时间段内系统活动的能力，这对于建立性能基线（你的系统的正常状态）至关重要。

4.1 分析前几天的数据

要查看前一天收集的数据，请使用 -f 标志指定每日 saXX 文件的路径。

示例： 查看当前月份第 10 天的 CPU 统计信息：

sar -u -f /var/log/sa/sa10

要查看该天特定时间窗口内的统计信息，请添加 -s（开始时间）和 -e（结束时间）标志（使用 24 小时格式）。

# 查看第 10 天 14:00 到 16:30 的网络统计信息
sar -n DEV -f /var/log/sa/sa10 -s 14:00:00 -e 16:30:00

4.2 建立基线

收集数据： 在正常的高负载和低负载期间运行 sysstat。
识别常态： 分析历史数据 (sar -f) 以确定平均 CPU 利用率 (%user、%system)、峰值 I/O 延迟 (%util) 和平均内存使用量。
定义阈值： 将与你自己基线的持续偏差视为调查触发器。繁忙的数据库主机和安静的跳板机不应共享相同的阈值。

当基线与实际业务节奏相关联时，它们更有用。周一早上的批量导入、夜间备份和产品发布都会创建不同的“正常”形态。在调查时做笔记：“备份在 01:00 开始”，“新版本在 14:30 发布”，“营销邮件在 09:05 发送”。这些笔记使得以后解释历史 sar 输出变得更加容易。

5. 辅助 Sysstat 工具

虽然 sar 是总括工具，但 sysstat 套件包括提供专注、高细节报告的专业实用程序。

5.1 iostat（输入/输出统计信息）

iostat 提供专门关注设备利用率的详细指标，在诊断存储瓶颈时特别有用。

# 每 2 秒报告磁盘统计信息，共 4 次，包括扩展统计信息 (x)
iostat -xd 2 4

关键 iostat 指标：

%util：I/O 请求被发送到设备的 CPU 时间百分比（饱和的关键指标）。
await：发送到设备的 I/O 请求的平均等待时间（毫秒）。高 await 表示存储响应缓慢。

如果 await 跳升但吞吐量不高，请查找小的随机 I/O、文件系统问题、虚拟基础设施上的吵闹邻居，或执行同步密集型写入的应用程序。如果吞吐量高且延迟随之上升，设备可能只是达到了其实际极限。

5.2 mpstat（多处理器统计信息）

如果你怀疑 CPU 调度问题或跨核心的工作负载分布不均，mpstat 提供每个处理器的使用统计信息，这是 sar -u 聚合的。

# 每 2 秒显示所有 CPU (A) 的使用情况
mpstat -P ALL 2 1

这对于识别使单个核心饱和而其他核心空闲的单线程应用程序，或诊断超线程效率非常宝贵。

5.3 sadf（导出 Sysstat 数据）

sadf 读取与 sar 相同的收集数据，但可以以更易于脚本和仪表板使用的格式打印出来。

sadf -d /var/log/sa/sa24 -- -u
sadf -j /var/log/sa/sa24 -- -r

-d 输出对于分隔文本处理很有用。-j 输出在你想要 JSON 时很有用。当需要将证据附加到事件审查或比较两台主机而无需手动复制终端输出时，这很方便。

6. 一个实用的事件演练

想象一个 API 服务器在 10:15 开始超时。应用程序日志显示请求堆积，但它们没有解释原因。从历史 CPU 视图开始：

sar -u -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

如果 %user 高且 %idle 低，则应用程序可能是 CPU 密集型的。检查每个核心的使用情况：

sar -P ALL -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

如果一个核心被固定而其他核心安静，则怀疑单线程工作进程、热锁或不均匀的进程分布。如果所有核心都很忙，请查看请求率、最近的部署和昂贵的代码路径。

如果 CPU 看起来大部分空闲但 %iowait 上升，则切换到磁盘：

sar -d -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

大约在同一时间的高设备利用率或上升的队列深度指向存储。在数据库支持的服务上，下一步是数据库日志和慢查询数据。在文件服务主机上，检查备份、压缩作业或日志轮换是否同时运行。

如果 CPU 和磁盘看起来正常，请检查内存和网络：

sar -r -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -W -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -n DEV,EDEV,TCP,ETCP -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

关键不是每次都要运行每个命令。关键是遵循证据。sar 为你提供了跨资源类的时间线，这通常是你停止追逐最响亮症状所需要的。

一个简单的操作习惯

学习 sysstat 的最佳方法是在出问题之前使用它。在正常流量期间检查健康的服务器。在备份期间检查它。在部署后检查它。保存一些与你环境匹配的命令模式。

当事件发生时，你已经知道正常情况是什么样的。这就是该工具集的真正价值。sar、iostat、mpstat 和 sadf 不会神奇地为你诊断应用程序，但它们使对话基于证据：问题何时开始，哪个资源发生了变化，以及主机是否真的处于压力之下。