直接运行 sar -u 1 5 可实时采样 CPU 使用率，输出 %user、%system、%idle 等指标；不加参数则读取历史数据而非实时状态。
如何用 sar 实时看 CPU 使用率
直接运行 sar -u 1 5 就能每秒采样一次、共 5 次，输出用户态（%user）、内核态（%system）、空闲（%idle）等关键指标。注意默认单位是百分比，不是毫秒或 ticks。
常见错误是只跑一次 sar -u 不带参数——它会查历史数据（来自 /var/log/sysstat/），而非当前实时状态；想看“现在”，必须加时间间隔和次数。
-
sar -u ALL 1 3可展开显示软中断（%soft）、硬中断（%irq），排查中断风暴时有用 - 如果看到
%idle长期接近 0，但%iowait很高，说明不是 CPU 瓶颈，而是磁盘响应慢 - 某些容器环境或低权限账户下，
%steal值异常高（>10%），大概率是宿主机资源超卖
sar 查内存是否真缺页
sar -r 显示的是物理内存使用概况（%memused、kbmemfree），但它不等于“内存不够”。真正反映压力的是 sar -B 的分页活动：重点关注 pgpgin/pgpgout（每秒换入/换出页数）和 pgmajfault（每秒主缺页次数）。
主缺页（pgmajfault）高才说明进程在频繁从磁盘加载代码或数据段；若该值持续 >100/s，配合 free -h 发现可用内存
-
sar -r 2 10和sar -B 2 10最好同时跑，避免时间错位导致误判 -
kbmemused接近总量 ≠ 内存瓶颈：Linux 会把空闲内存用于 page cache，MemAvailable（见/proc/meminfo）才是更准的可分配量 -
sar -r不显示 swap 使用细节，要查sar -S（%swpused）和sar -W（pswpin/pswpout）
磁盘 I/O 数据里哪个字段最值得盯
别只看 sar -d 的 %util。这个值是设备忙时占比，对 NVMe 或多队列 SSD 来说，80% util 可能完全正常；而对单盘 SATA，>60% 就可能排队了。更可靠的指标是 await（I/O 平均等待毫秒数）和 svctm（实际服务时间）——如果 await >> svctm，说明请求在队列里堆着。
注意 sar -d 默认不显示设备名全称（如 nvme0n1p1），需加 -P ALL 参数才能区分多盘，否则所有数据会混成一个 DEV 行。
- 用
sar -d -p 1 5（-p启用可读设备名）避免认错盘 -
rkB/s和wkB/s是吞吐量，rrqm/s和wrqm/s是合并请求数，后者高说明 I/O 聚合做得好 - 如果
await突增但%util不高，可能是应用层小 IO 密集（如数据库随机读），而非磁盘硬件瓶颈
为什么 sar 历史数据突然没了
因为 sar 本身不采集，它只读取 sysstat 服务记录的日志，默认路径是 /var/log/sysstat/saXX（XX 是日期）。如果 sysstat 没启用、crond 任务被禁、或磁盘满导致写入失败，历史就为空。
检查三件事：systemctl is-active sysstat、ls -l /var/log/sysstat/sa*、df -h /var/log。另外，/etc/cron.d/sysstat 里定义的采集频率（通常是每 10 分钟）和保留天数（/etc/sysconfig/sysstat 中 HISTORY）直接影响你能回溯多久。
- 刚装完
sysstat，需手动执行sadf -d /var/log/sysstat/sa$(date +%d) | head确认有数据生成 -
sar -f /var/log/sysstat/sa15可指定某天文件，但 sa 文件是二进制，不能用cat直接看 - 如果业务要求秒级精度，
sysstat默认 10 分钟太粗，需改/etc/cron.d/sysstat并重启服务，但会增大磁盘压力
历史数据依赖 cron 和磁盘空间，这两点最容易被忽略，一出问题就只能看实时，没法对比趋势。
