如何使用 sar 查看服务器历史性能

当一台 Linux 节点在 02:00 变慢时，实时工具往往已经来不及了。这正是 sar 服务器历史性能发挥作用的地方。与其盯着实时快照，不如让工程师回溯机器在更早时间到底发生了什么：CPU 时间是否主要消耗在用户态，内存压力是否把系统推向了交换分区，磁盘队列是否已经形成，或者网络流量是否在同一时刻突然飙升。核心思路其实很简单：持续采集轻量级活动记录，然后在事故发生后再去读取它们。落实到实际运维中，这能把“服务器感觉很卡”这类模糊描述，变成一条真正可以验证的时间线。

为什么在实时指标不够用时 sar 依然重要

许多工程师习惯先用交互式命令，因为它们直观、即时、熟悉。但它们的弱点也很明显：时机。一旦某次过载只持续了十分钟，并且在任何人登录之前就结束了，那么屏幕上的证据也就随之消失。历史采集工具通过把周期性采样写入每日文件，弥补了这个缺口，后续还可以通过有针对性的查询进行回放。根据 Linux 的 sar 手册页，该工具不仅能显示实时样本，还能从每日活动文件中展示已保存的 CPU、内存、I/O 和网络统计信息。

这种工作方式特别适合存在定时任务、备份窗口、批处理导入、分析流水线，或者用户行为明显集中在某个时区的流量高峰场景。因为此时真正的问题通常不是“现在发生了什么”，而是“故障窗口期间发生了什么”。正是这种思路转变，让 sar 在底层运维工作中始终颇受青睐。

sar 如何存储历史数据

sar 属于 sysstat 工具集，并依赖后台数据采集机制。采集器会写入每日活动文件，常见路径是 /var/log/sa。sysstat 手册说明了其默认命名模式为 saDD，即数据文件按日期编号；同时也提到，如果需要更长的保留周期，可以切换为基于完整日期的命名格式，例如 saYYYYMMDD。

对运维人员来说，这意味着两个很实际的结论：

• 只有在事故发生前已启用采集时，历史可见性才真正存在。
• 保留策略决定了排查时最早可以追溯到什么时候。

如果一台主机已经运行了几个月，但活动采集功能始终没有启用，那么 sar 也无法凭空还原失去的过去。它读取的是已经记录下来的系统活动，而不是推断缺失的遥测数据。

在信任这个工具之前，先确认采集已启用

在把 sar 纳入事故处理流程之前，先确认节点确实在持续记录数据。一个最小化的检查流程通常包括以下几步：

1. 检查命令本身是否存在。
2. 确认每日文件是否正在持续更新。
3. 检查保留策略，避免旧记录过早消失。

一组简洁的命令通常就足够了：

• sar -V
• ls -lh /var/log/sa/
• sar -u

sysstat FAQ 也指出，sar 数据通常保存在 /var/log/sa/saDD 中，一旦这些文件存在，sar 就能够显示其中保存的统计信息。

读取 CPU 历史数据，而不是靠猜

CPU 通常是排查的第一站，但真正的陷阱在于把一切都粗暴地归结为“CPU 高”。历史分析更有效的方式，是把 CPU 状态拆开来看。通过 sar -u，最值得关注的字段通常是用户态时间、系统态时间、空闲时间以及 I/O 等待时间。手册页对这些 CPU 利用率视图有清晰说明，并明确指出 sar 就是为了从保存的每日文件中展示这类指标而设计的。([man7.org])

常见且值得关注的模式包括：

• 用户态时间偏高，通常说明应用代码本身计算密集。
• 系统态时间偏高，可能意味着内核层活动较重，例如报文处理或文件系统压力。
• I/O 等待时间偏高，往往说明真正的瓶颈不在 CPU，而在于存储延迟拖慢了执行。
• 空闲时间在较长时间窗内持续很低，则更接近真实饱和，而不是短时突发。

常用命令示例如下：

• sar -u：查看当天数据
• sar -u -s 10:00:00 -e 11:00:00：查看指定时间范围
• sar -u -f /var/log/sa/sa14：查看指定保存文件

更“极客”的做法是做关联分析。单看 CPU 数值，几乎从来都不是完整答案。如果 I/O 等待升高且吞吐下降，就应该顺着链路去看块设备数据，而不是过早把责任推给调度器或运行时环境。

检查内存压力，而不只是盯着剩余内存

内存排障之所以容易混乱，很大程度上是因为很多人过度执着于某一个“剩余内存”数字。更有价值的历史内存分析，应该关注一段时间内的压力变化。借助 sar -r 以及面向交换分区的视图，例如 sar -S，你可以观察系统是否一直保留了足够余量、缓存是否正常回收，以及在故障时段交换分区是否被卷入。sar 的相关文档也将内存报告列为其标准保存指标之一。

以下信号通常值得进一步深挖：

1. 内存占用缓慢上升，并且在工作负载结束后仍不回落。
2. 在延迟尖峰出现时，交换分区使用量同步增长。
3. 缓存缩小的同时磁盘读取增加，这往往暗示工作集正在频繁抖动。

一个很稳妥的调试习惯，是把内存和磁盘历史放在一起对照看。一旦交换分区进入问题现场，延迟就可能出现在距离原始内存消耗进程很远的地方。历史记录能帮助你把这种滞后效应拆解清楚。

利用磁盘指标解释卡顿和长尾延迟

当系统感觉很慢，但 CPU 又没有被完全打满时，存储通常就是下一个重点怀疑对象。sar 提供了块设备活动和传输统计信息，可以帮助判断机器到底是在计算，还是大多数时间都在等待读写完成。运维人员通常会使用 sar -d 查看设备活动，使用 sar -b 查看面向传输的汇总信息。

值得关注的现象包括：

• 事务速率上升，并且与某个批处理任务或归档任务的时间一致。
• 读写活动明显不对称，并且与应用行为特征吻合。
• CPU 视图中的 I/O 等待升高，同时块设备活动也在增强。

历史存储分析更关注持续性争用，而不是孤立峰值。一次短暂突发未必有害，而一段持续较长的压力平台通常就不是小事了。无论是在服务器租用环境还是服务器托管环境，这种区别都很关键，因为即便节点上的症状看起来一样，根因所在层次也可能完全不同。

跨时间窗口追踪网络行为

网络问题最擅长伪装成应用问题。一次请求超时发生后，很多人第一反应是先翻日志，而不是先看网卡历史。sar 的价值就在于，它可以通过 sar -n DEV 这类视图暴露设备级计数器。sysstat FAQ 也指出，sar 既可以从保存的数据文件中报告网络设备利用率，也可以在实时模式下进行展示。

历史网络回顾对于发现以下现象很有帮助：

• 与发布、爬虫或同步任务相吻合的流量突发。
• 故障窗口期间接收或发送流量的剧烈变化。
• 能够解释报文处理型系统态时间升高的接口级异常。

对于服务地理分布广泛用户群的工程师来说，这种视图尤其有启发性，因为用户需求往往会在本地工作时间附近高度集中。一旦这种节律变得可见，容量规划就能少一些被动补救，多一些主动设计。

查询精确的故障时间窗口

最有效率的 sar 排查通常都从一个明确时间戳开始。与其通读整整一天的数据，不如把查询范围收窄到故障发生前、发生时和恢复后的那段时间。这样做可以显著提高信号强度，减少噪声干扰。

一个实用的排查顺序通常如下：

1. 先看故障窗口内的 CPU。
2. 再看同一时间段内的内存和交换分区。
3. 接着对照相同时间戳下的磁盘和网络活动。
4. 最后才进入进程级或应用级工具。

示例命令如下：

• sar -u -s 14:00:00 -e 14:20:00
• sar -r -s 14:00:00 -e 14:20:00
• sar -d -s 14:00:00 -e 14:20:00
• sar -n DEV -s 14:00:00 -e 14:20:00

这种以时间为边界的方式，能让输出更像一份系统行为轨迹，而不是一堵随意堆叠的计数器高墙。

当今天的数据无关时，直接打开旧的每日文件

某些故障往往在事后很久才被上报，尤其是在没有全天候人工值守的环境中。此时，正确做法通常是使用 -f 选项直接打开保存好的每日文件。sysstat 文档说明，sar 可以显示此前保存在这些文件中的统计信息，而这正是回溯性分析的基础。

常见示例如下：

• sar -u -f /var/log/sa/sa13
• sar -r -f /var/log/sa/sa13
• sar -n DEV -f /var/log/sa/sa13

如果需要较长保留周期，就应检查配置的历史保留策略。sysstat 手册解释了，保留由历史设置控制，超过配置天数的文件会被自动清理。

当 sar 看起来没用时，常见的失败模式有哪些

sar 让人失望，通常不是因为工具能力不够，而是因为运维流程出了问题。最常见的陷阱往往非常规律：

• 从未启用采集，因此根本没有过去可查。
• 保留周期过短，目标文件已经轮转消失。
• 查询了错误的指标类别，从而得出错误结论。
• 一上来先看平均值，结果错过了真正藏在时间线里的尖峰模式。

sysstat FAQ 还记录了一些请求的活动类型不可用的情况，这通常发生在内核或数据文件没有提供预期数据集时。

更好的运维习惯，是把 sar 视为整个工具栈中的一层：

1. 先用 sar 重建时间轴。
2. 再用进程级工具识别是谁主导了这条时间轴。
3. 只有在搞清楚系统级模式后，再去读日志和追踪数据。

生产环境排查的最佳实践

如果能配合一套有纪律的事故处理流程，历史监控的价值会被放大许多。以下习惯通常很值得坚持：

• 记录症状开始和结束的精确分钟。
• 保留足够长的历史，以覆盖延迟上报的故障。
• 在同一时间片内同时查看 CPU、内存、磁盘和网络。
• 优先解释趋势，而不是执着于孤立峰值。
• 在需要更深层离线分析时导出记录。

更广义的 sysstat 工具集还包含用于格式化保存数据的实用程序，相关手册页也说明了这些每日文件除了直接在终端读取之外，还可以被进一步消费和处理。

结论

优秀的性能排障，始于一条清晰的时间线，而这正是 sar 服务器历史性能所能提供的价值。它把一台 Linux 主机从黑盒，变成一份关于状态转移的记录：CPU 繁忙、内存吃紧、存储拥堵，或者网络激增。对于技术团队来说，它的价值不在于花哨的仪表盘，而在于法证式的清晰度。如果节点在无人注视时出现异常，sar 就能帮你重放系统自己的叙述，让整个调查过程少一些猜测、少一些玄学，并且更高效地从症状走向根因。