简介：这是一份面向 Linux 运维人员与系统管理员的 sysstat 11.5.6 源码安装包，包含 CPU 利用率、磁盘 I/O、网络流量等性能监控所需的完整工具链，适用于服务器性能调优、故障排查与日常运行状态巡检等场景。压缩包共 177 个文件，大小约 597KB，以 c、h 源文件，in 配置模板，po 多语言翻译文件，1 手册页等类型为主，并附带 configure 配置脚本、sadc 数据收集器相关选项及安装说明文件，便于在本地编译部署。资源中还包括 isag、sargraph 等辅助图形化工具与 cron 定时采集配置示例，帮助用户实现自动化监控和报表生成。发布者为 ssxueyi，已有 470 人浏览学习，适合具有一定 Linux 基础、希望深入理解系统性能指标并动手编译部署监控工具的中高级学习者。通过编译安装这一版本，读者可以完整了解 sysstat 从源码构建到日常使用的过程，并借助 iostat、mpstat、vmstat、sadf 等核心命令定位 I/O 瓶颈、评估多核负载并分析内存与交换空间状况，进而提升服务器稳定性与运维效率。

1. 拿到 sysstat-11.5.6.tar.gz，我为什么不急着解压

sysstat-11.5.6.tar.gz 在 Linux 服务器上是个很常见的东西：它是 sysstat 这个性能监控工具集的 11.5.6 版本源码包，解开之后里面有 sar、mpstat、iostat、pidstat 这些我每天都要打交道的命令。拿到这样一个源码包，我的习惯不是第一时间解压，而是先把几个问题摆到桌面上：装在哪个前缀路径、谁来定时调用 sadc、历史日志留几天、会不会和发行版自带的 sysstat 打架。这些问题没想清楚，装完就会得到一套能和系统共存、却没法让你快速定位瓶颈的工具——只多了一个黑匣子，而不是多一双眼睛。这篇我按自己惯用的流程，把从解压到落地的完整路径走一遍。

2. sysstat 的组成结构与版本选型：为什么要留 11.5.6

sysstat 不是一个大而全的二进制，它是一条完整的链路。采集端是 sadc，负责把内核里的计数器读出来，写进二进制文件；sa1 是一个外层壳，按固定周期调用 sadc；sa2 则负责在一天结束时把多个数据点合并归档，顺便触发统计汇总。读数据这一侧是 sar 和 sadf，而 mpstat、iostat 这类命令是直接读内核统计、不走历史文件的。理解这条链路，后面所有配置才有依据。

2.1 三条命令先看懂环境：编译前自检

我一般会在解压前先做一轮环境自检，不是走形式，是为了少返工。sysstat 的编译依赖非常轻，但缺了某一样就是会卡在 configure 阶段给你看脸色。

# 检查编译链是否完整 gcc --version make --version # 检查是否有 zlib 开发库，影响 sa 文件能否压缩 ldconfig -p | grep zlib || echo "zlib 未安装" # 检查 cron 服务是否在跑，11.5.6 最常见的调度方式还是 cron systemctl is-active crond 2>/dev/null || service crond status

gcc 和 make 是硬依赖，缺了直接用发行版包管理器装上即可。zlib 不是必须，但缺了之后 configure 会关闭文件压缩支持，sa 日志文件会偏大，对磁盘紧张的小机器来说是个隐性成本。第三条检查的是调度器，如果系统里 cron 没在跑，后面就算把脚本放进 /etc/cron.d/ 也不会执行，这是很多人在最后一步才发现的坑。自检完之后，还有一步更重要：看看当前系统里是否已经装过 sysstat。

which sar sar -V

很多服务器上其实已经带了发行版预编译的 sysstat，只是版本偏低。如果不看当前路径就急着 make install，最后敲 sar 时大概率命中的还是旧版本。这个问题不解决，后面所有验证都是错的，这也是这个标题下翻车率最高的一个环节。

2.2 为什么这个版本值得留一份源码包

有人会问，直接发行版包管理器装一个 sysstat 不就行了，为什么非要留 11.5.6 的源码包？我的回答是：可预期性。下面这张对比表说的是 11.5.6 这一代和后续新版之间最明显的差异，也是我在生产上选型时实际会权衡的点。

如果你的诉求是 CPU、内存、磁盘、进程这些基础维度，11.5.6 完全够用，而且它的文档和行为在网络上沉淀时间最长，遇到问题能搜到大量真实案例。我留源码包还有一个私心：同一台服务器上用同一版本采集、同一版本读取，数据格式不会有版本错位这种玄学问题。当你想排查的是一个持续了三天、只在深夜出现的负载尖峰时，最怕的就是历史文件打不开，或读出来是一堆格式错乱的值。固定版本，等于把这类问题挡在门外。

2.3 从源码装的控制权收益

从包管理器安装省事，但它会跟随发行版升级，今天还是这个版本，某次系统更新后可能就换成了新版，行为也随之变化。监控工具最怕的不是功能少，而是行为突然变。源码安装的核心收益是控制权：装在哪个路径自己定，配置文件自己写，调度方式自己选，后续要不要升级也自己说了算。对于需要长期运维的服务器，这个确定性比省那几分钟宝贵得多。确认环境没问题、也看清了当前的版本冲突之后，就可以进入真正的安装环节了。

3. 编译安装 sysstat-11.5.6：路径冲突与三行命令验证

编译 sysstat 本身不难，难的是装完之后系统里到底跑的是哪一份。这一章我把路径决策和编译验证放在一起讲，因为这两件事是连在一起的。

3.1 决定前缀路径：隔离装还是覆盖装

我一般会做一个隔离安装，把 sysstat 安排到独立目录，再通过软链接控制对外暴露的命令，这样可以避免和发行版自带的另一套 sysstat 混淆。

# 解压源码包 tar -xzf sysstat-11.5.6.tar.gz cd sysstat-11.5.6 # 配置到独立目录，显式关闭压缩，让行为最可预期 ./configure --prefix=/usr/local/sysstat-11.5.6 \ --enable-install-cron \ --disable-compression

这里重点说三个参数。--prefix 决定安装根目录，我用的是 /usr/local/sysstat-11.5.6，这样全部文件收拢在一个目录里，之后想整体删掉也不会留垃圾。--enable-install-cron 会让 make install 同时安装 sa1、sa2 脚本到 lib 目录，省得自己手写这两个壳。--disable-compression 是我个人偏好，它把 configure 探测到的压缩支持显式关掉，让日志以最原始格式落盘。压缩能省空间，但读取时多一层解压，且一旦文件头损坏，恢复难度更高。日志大小这件事可以靠 HISTORY 控制天数来解决，不值得为此引入额外复杂度。

如果源码目录里已经有 configure 生成过的缓存，重新配置之前建议先 make distclean，避免旧配置项残留影响新的前缀设置。这个小动作能省掉很多莫名其妙的编译期报错。

3.2 make 到 install 的验证链

配置完成后就是三行命令的事。

# 并行编译，nproc 取核数 make -j"$(nproc)" # 安装到指定前缀 make install # 在公共路径建一个软链接，方便直接调用 ln -s /usr/local/sysstat-11.5.6/bin/sar /usr/local/bin/sar # 验证版本与路径 /usr/local/sysstat-11.5.6/bin/sar -V

make -j 后面的数字是并行编译的进程数，直接用 nproc 动态获取即可，避免手动写死导致编译时负载过高。make install 需要 root 权限，因为要写 /usr/local 下的目录；如果之前配置时用的非 root 用户，这一步会直接报权限不足。软链接那行是把新版本暴露到 PATH 里，避免每次敲完整路径。最后的 sar -V 是为了确认我们调用的是 11.5.6 而不是旧版。

安装完还要核对一下 sa1、sa2、sadc 的实际位置，因为不同 configure 参数下它们可能落在 lib 或 lib64 下。

# 查找采集脚本与 sadc 的位置 find /usr/local/sysstat-11.5.6 -name "sa1" -o -name "sa2" -o -name "sadc"

这一步的输出直接决定后面 cron 脚本里要填的绝对路径。常见做法是先跑一遍 find 记下路径，再写配置。如果你需要在多台同构服务器上快速铺开，还可以用 DESTDIR 打包，把安装内容先落到临时目录，再整体拷贝到其他机器，省去每台机器都编译一遍的时间。

编译期最常碰到的报错基本就三类：一是 configure 阶段提示 no acceptable C compiler found，说明缺 gcc，装上编译器组再回来；二是 make 阶段 ld: cannot find -lz，说明 zlib 开发头文件没装；三是 make install 时提示目录只读，说明当前用户权限不够，改用 root 执行安装即可。这三类问题我在不同机器上各见过不下十次，没有一次是 sysstat 本身的问题，全是环境准备不到位。

4. 配置采集链路与常用统计项：让 sar 真正干活

编译安装只是把工具放下，真正让 sysstat 产生价值的是采集链路。这一章解决两个问题：数据怎么持续进文件，以及遇到故障时用什么命令把数据捞出来。

4.1 手写 cron 采集链：sa1、sa2 与 HISTORY 的配合

源码安装不会替你把 crontab 写好，所以需要自己动手建一个 /etc/cron.d/sysstat。这是让 sysstat 每 10 分钟自动采集的关键文件，也是后续所有历史数据存在的前提。

cat > /etc/cron.d/sysstat <<'EOF' SHELL=/bin/sh PATH=/usr/local/sysstat-11.5.6/bin:/usr/local/sysstat-11.5.6/lib/sa:/usr/local/bin:/usr/bin:/bin # 每10分钟调用一次 sa1，采样间隔1秒，采样1次 */10 * * * * root /usr/local/sysstat-11.5.6/lib/sa/sa1 1 1 # 每天23:53调用 sa2 汇总当天数据 53 23 * * * root /usr/local/sysstat-11.5.6/lib/sa/sa2 -A EOF

sa1 后面的两个数字分别是采样间隔和采样次数，间隔 1 秒、次数 1 次，意思就是每个整点十分钟采一个瞬时值。cron 行里的 10 分钟由 */10 控制，sa1 本身不决定频率。sa2 -A 里的 -A 表示汇总所有统计项，生成当天的数据文件归档。这里有个容易被忽略的点：cron 环境非常干净，不会自动读取 /etc/sysconfig/sysstat，所以如果系统里存在这个配置文件，需要在 cron 脚本里显式加载，否则里面的 HISTORY 和 SADC_OPTIONS 全部不生效。

接着创建 sysstat 自己的配置文件，用来控制保留天数和采集范围。

cat > /etc/sysconfig/sysstat <<'EOF' HISTORY=14 SA_DIR=/var/log/sa SADC_OPTIONS="-S XALL" EOF

HISTORY 是保留多少天的日志文件，超过这个天数的 sa 文件会被清理。这个参数适合按磁盘空间设定，如果每天日志量在几 MB 量级，14 天是个比较舒适的起点。SADC_OPTIONS 传给 sadc，-S XALL 表示采集内核提供的全部统计组，包括中断、电源、磁盘等扩展项。没有这一项，后面 sar -A 读历史时会看到一片全是 0 的字段，这是很典型的问题，下一章会展开讲。

4.2 实时与历史：五条命令快速定位瓶颈

采集链路跑起来之后，日常排查时我用到最多的就是下面五组命令。

# CPU 总使用率，每1秒采样一次，共3次 sar -u 1 3 # 每个 CPU 核心的使用率 mpstat -P ALL 1 2 # 内存使用情况 sar -r 1 3 # 磁盘的吞吐、等待时间与使用率 iostat -x 1 5 # 按进程维度看 CPU 和内存 pidstat -u -r 1 3

sar -u 看的是整体 CPU 使用率，单核不均衡时它会掩盖问题，所以要配合 mpstat -P ALL 看每个核的分布。sar -r 看内存页换入换出，如果 pi 和 po 一直有值，说明物理内存不够用。iostat -x 里最重要的不是第一眼看到的 %util，而是 await 和 avgrq-sz，后面避坑章节单独说。pidstat -u -r 组合起来可以同时盯住 CPU 和内存两个维度，定位到具体进程再往下查。

实时数据只是其中一半，另一半是历史回放。

# 读回今天的历史数据，查看整天 CPU、内存、负载走势 sar -f /var/log/sa/sa$(date +%d) -u -r -q

-f 指定历史文件，文件名里的 sa 后跟的两位数字是当月几号。今天是 15 号就读 sa15，不会自动跨月，所以要看上个月的数据，得自己按文件名去对应目录里找。这个命令在故障复盘时价值极高，因为问题往往是过去 24 小时内某个时间点开始积累的，从历史数据里能看到拐点。

5. 避坑手册：sysstat 从安装到读取的 5 个翻车现场

这一章写的是我见过最多、也最容易反复踩的五个问题。每一条都按现象、原因、解决的顺序来，方便你在现场对照。

5.1 装完敲 sar 还是旧版本

现象：make install 结束，却提示找不到命令或版本和预期不一致。原因：系统里发行版自带的 sysstat 抢先占据了 PATH，输入 sar 时 shell 优先命中 /usr/bin/sar。解决方式：

# 看当前命中路径 which sar # 再看版本 sar -V # 优先使用隔离目录里的版本 /usr/local/sysstat-11.5.6/bin/sar -V

如果确认是路径抢占，要么把软链接放到 PATH 更靠前的目录，要么在配置文件里调整 PATH 顺序。这个问题没有技术难度，但很隐蔽，因为系统不报错，只是行为不对。

5.2 日志目录空的，一个 sa 文件都没有

现象：/var/log/sa 目录存在但里面没有任何文件，sar -f 读不到任何数据。原因一般是三个：crond 服务没在运行；cron 脚本里 sa1 的路径写错；或者 /var/log/sa 目录根本不存在，sa1 没有权限自动创建。解决方式：

# 确认 cron 服务在跑 systemctl status crond # 手动执行一次，看真实报错 /usr/local/sysstat-11.5.6/lib/sa/sa1 1 1 # 目录不存在则手动创建并设置属主 mkdir -p /var/log/sa chown root:root /var/log/sa

手动执行 sa1 是排查这类问题最快的方式，它会直接打印出缺失的路径或权限信息，比猜快得多。注意 sa1 里的所有路径都要写绝对路径，cron 的 PATH 环境非常精简，不能依赖相对路径。

5.3 HISTORY 设了 7 天，日志却留了三十天

现象：明明在 /etc/sysconfig/sysstat 里写了 HISTORY=7，但 /var/log/sa 下的文件越来越多，清理机制完全没生效。原因：cron 执行 sa2 时没有加载 /etc/sysconfig/sysstat，HISTORY 在 sa2 的环境里根本不存在。解决方式是在 /etc/cron.d/sysstat 里显式加载配置文件：

cat > /etc/cron.d/sysstat <<'EOF' SHELL=/bin/sh . /etc/sysconfig/sysstat EOF

注意这行加载必须放在调用 sa1、sa2 之前。很多发行版的自动安装脚本会替你做这一步，但源码安装时必须自己处理。这个坑的典型症状就是磁盘空间缓慢增长，往往要等到 /var 分区告警才会被发现。

5.4 iostat 的 %util 显示 100%，业务却毫无压力

现象：iostat -x 输出里磁盘 %util 长期是 100%，但应用响应正常，没有任何卡顿。原因：%util 表示的是设备在采样周期内有未完成命令的时间占比，并不直接等于磁盘忙到极限。对高速设备和某些 RAID 控制器来说，这个值很容易虚高。解决方式是把它和两个辅助指标一起看：

iostat -x -d 1 5

重点看 await（平均 IO 响应时间）和 avgrq-sz（平均请求大小）。await 保持在个位数毫秒、avgrq-sz 正常时，%util 虚高可以忽略。11.5.6 里还保留了 svctm 这一列，它反映的是命令平均执行时间，可以辅助判断设备本身是否处于饱和状态。只看 %util 单挑问题，会在排查方向上绕远路。

5.5 换服务器后历史文件读不出来或全是 0

现象：把旧服务器的 sa 文件拷贝到新环境，sar -f 直接报文件格式错误，或者能打开但读出的字段全是 0。原因：sysstat 不同版本之间的数据文件格式并不完全兼容，而且 SADC_OPTIONS 采集范围不一致也会读不出扩展统计项。解决方式是保持版本和采集选项一致：

# 对比两边的 SADC_OPTIONS cat /etc/sysconfig/sysstat # 用新环境读取时会先确认版本 sar -V

监控系统的历史数据是有延续性的，版本混用会让对比完全失效。这也是我坚持固定 sysstat 版本的原因之一。生产环境的采样配置一旦确定，就别因为某次升级顺手改掉，宁可先在新机器上并行验证一周，再切换。

6. 用 sadf 把历史数据导出 CSV：出故障后有后悔药

6.1 sadf 导出命令

sar 输出适合人眼扫，但要做故障前后对比、进监控平台二次绘图，就得把数据导出成结构化的 CSV。sadf 就是这个出口，它把 sa 二进制文件转成文本表格。

# 导出当天 09:00 到 18:00 的 CPU、内存、运行队列数据 sadf -d /var/log/sa/sa$(date +%d) -s 09:00:00 -e 18:00:00 -- -u -r -q | head -20

-d 表示输出制表符分隔的表格，-s 和 -e 限定起止时间，-- 后面跟的是 sar 的统计项参数。导出的每行有时间戳、主机名、统计类别和数值，可以直接丢进脚本或可视化工具。这个命令是我在故障复盘时最常用的，比截图留档可靠得多。

6.2 建立基线，再谈分析

我的习惯是每台新服务器装完 sysstat 后，先手动采一组 300 秒的基线数据，导成 CSV 存起来。日常运维中一旦出现负载异常，就导出同一时间窗口的 CSV，和基线拼在一起看偏差。有了基线，CPU 升高一点、内存换页增多一点都能被量化确认，而不是靠感觉判断是不是出了问题。监控工具的价值不在实时界面，而在于你能回放过去任意一刻的系统状态。

这套流程走下来，sysstat-11.5.6.tar.gz 在你手里就不只是一个压缩包，而是一条可以持续追溯系统历史状态的完整链路。固定版本、固定选项、固定保留周期，是我这几年运维下来最值得坚持的一组习惯。希望帮到你。

本文还有配套的精品资源，点击获取