1. 数据是如何存放的？

sar 命令依赖于 sysstat 软件包。只要安装并启用它，系统就会在后台自动采集数据并存档。

• 存放位置： 历史数据通常保存在 /var/log/sa/（或 /var/log/sysstat/）目录下。
• 文件格式：
  • saXX： 二进制数据文件，XX 代表当月的日期。例如，sa14 文件就存储了当月 14 号的所有性能数据。
  • sarXX： 文本格式的报告文件，通常是系统每天定时从二进制文件生成的。

---

2. 核心用法示例

要查看这些历史数据，你只需要使用 -f 选项来指定数据文件，并结合其他选项来查看你想关注的指标。

以下是几个最实用的组合：

你想看什么	命令示例	说明
所有 CPU 历史数据	sar -f /var/log/sa/sa14	不加其他选项时，默认显示当天的 CPU 使用情况。
特定日期的 I/O 情况	sar -b -f /var/log/sa/sa14	-b 选项用于查看磁盘 I/O 和传输速率统计信息。
特定日期的内存情况	sar -r -f /var/log/sa/sa14	-r 选项用于查看内存和交换空间的使用统计。
查看一天中某时段的数据	sar -q -s 10:00:00 -e 14:00:00 -f sa14	-s 和 -e 指定起止时间，-q 查看系统负载历史。

---

3. 数据输出示例

21时20分00秒       tps      rtps      wtps   bread/s   bwrtn/s
21时30分00秒     73.79      2.49     71.30    100.56   1453.86
21时40分00秒     79.86      2.71     77.15    121.58   1553.42
21时50分01秒     76.80      2.83     73.97    142.83   1463.94
22时00分01秒     87.88      6.76     81.12    308.93   1661.03
22时10分00秒     92.01      8.37     83.64    374.17   1709.97
22时20分00秒     78.40      5.23     73.17    275.63   1581.53
22时30分00秒     83.13      7.84     75.28    421.07   1589.18
22时40分00秒     78.10      4.60     73.50    232.50   1567.25
22时50分00秒     79.34      3.77     75.57    195.76   1545.10
23时00分00秒     83.67      4.43     79.23    234.08   1616.84
23时10分01秒    108.57     19.80     88.77    808.72   1915.21
23时20分00秒     85.60      7.93     77.67    364.68   1563.84
23时30分00秒     85.23      6.36     78.87    290.47   1580.47
23时40分01秒     91.19      8.82     82.37    465.62   1672.08
23时50分00秒     90.89     14.64     76.25   1121.68   1665.70
平均时间:            90.69     11.32     79.37    574.27   1702.06

结论：系统的I/O负载偏高，压力较大，但还没有到完全崩溃的“不好”程度。

简单来说，硬盘已经比较忙碌了，其中“写入”（wtps）是绝对的主力。尤其是在 23:10 这个时间点，I/O出现了一个明显的波峰，值得关注。

4. 关键指标怎么看？

• tps (每秒传输次数)：核心指标，可以理解为硬盘的“忙碌程度”。普通机械硬盘（SATA HDD）的 tps 通常不建议持续超过 100-150。数据中大部分时间在 80-90 左右，属于较高负载；23:10 达到了 108.57，说明硬盘比较忙碌了。

• wtps (每秒写入次数)：最明显的特征。wtps 常年是 rtps (读) 的 10倍甚至20倍以上（比如 71.30 vs 2.49）。说明系统主要在大量写入小文件或频繁修改数据。

• bread/s (每秒读的数据量，KB)：大部分时间只有几百KB，不算高。但在 23:10 突然飙升到 808.72 KB/s，23:50 更是到了 1121.68 KB/s（约1.1MB/s）。这表示当时除了写入，还发生了一次比较明显的读操作。

• bwrtn/s (每秒写的数据量，KB)：稳定在 1.5MB/s 左右。1.5MB/s 这个速度对于现代硬盘来说非常慢，但再结合极高的 wtps (80次/秒) 来看，说明系统在频繁地执行小数据块的写入（每次大约写 20-30KB），而不是拷贝大文件。这种模式非常消耗硬盘的响应能力。

5. 综合评估：好还是不好？

结论：不算好，有风险，建议优化。

• 明显的写入瓶颈：硬盘大部分时间都在忙于处理大量的“小碎块”写入请求。这会导致依赖磁盘性能的应用程序（如数据库、Web服务等）感觉响应变慢，有卡顿感。

• 波峰值得关注：23:10 和 23:50 这两个时间点的读数据（bread/s）突然翻了好几倍。这可能是因为某个定时任务（比如日志切割、数据备份或大查询）恰好在这个时间点启动，抢占了I/O资源，导致其他服务在当时可能变慢。

6. 接下来可以做什么？

如果想进一步确认问题根源，可以用 sar 的其他选项来交叉验证：

6.1 看CPU是否在等待I/O

查看当时CPU的 iowait 百分比
sar -u -f /var/log/sa/sa14 -s 23:00:00 -e 23:59:00

如果 %iowait 数值也超过 10% 甚至 20%，那就说明CPU确实在频繁等待磁盘操作，进一步印证了I/O是当前性能瓶颈。

6.2 看具体是哪个磁盘最忙

查看单个磁盘设备的忙碌程度

sar -d -f /var/log/sa/sa14 -s 23:00:00 -e 23:59:00
这会输出 %util 列。如果 %util 接近或等于 100%，就说明那个磁盘已经满负荷运转了。

6.3 排查是什么进程在大量写入

如果这是物理服务器，当时可以用 iotop 命令直接看哪个进程的“写”操作排名最高。对于你现在的历史数据，可以检查系统日志，看看 23:10 附近是否有 crontab 定时任务或应用程序的日志在滚动。

7. 总结

这台服务器的磁盘长期处于高压力、低效率的小文件写入状态。