查内存历史需用sar -r -f /var/log/sa/saXX，重点看kbmemavail和%memused；先确认sysstat服务active且saXX文件存在，否则无历史数据可查。
直接查 /var/log/sa/saXX 文件，用 sar -r -f 提取内存历史，重点盯 available 和 %memused 两个字段——不是 used，也不是 free。
确认 sysstat 是否已启用历史采集
没开数据收集，sar 就是空壳子，查不到任何历史。先验证：
-
ls -l /var/log/sa/sa$(date -d yesterday +%d)—— 看昨天的sa文件是否存在；如果报 “No such file”，大概率没启用自动采集 -
systemctl is-active sysstat返回active才算真正运行中；若为inactive，需执行sudo systemctl enable --now sysstat - 默认采集间隔是 10 分钟，所以历史粒度最多到 10 分钟级，别指望看到某分钟内秒级波动
用 sar -r 查内存历史，关键字段别看错
sar -r 输出里有两组内存值，但只有 kbmemfree、kbmemused、kbmemavail 和 %memused 是有效指标，其余如 kbbuffers、kbcached 已被现代内核弃用（Linux ≥ 4.0）。
-
kbmemavail是真正可用内存（含可回收 cache），单位 KB；换算成 GB 可除以 1024²，比如12582912≈ 12 GB -
%memused是更可靠的百分比，它基于total - available计算，比老式used/total更准 - 若
%memused持续 > 95% 且kbmemavail接近 0，再结合sar -W看pswpin/s、pswpout/s是否突增，基本可断定发生过 OOM 前兆 - 注意：
sar -r不显示 swap 使用量，要查 swap 占用得额外跑sar -S -f /var/log/sa/saXX
定位具体时间点：用 -s 和 -e 缩小范围
全量 sar -r -f /var/log/sa/sa15 输出可能上千行，手动翻效率低。直接切片：
-
sar -r -f /var/log/sa/sa15 -s 02:00:00 -e 04:00:00 | grep -E "(Average|^[0-9])"—— 只看凌晨 2–4 点，并过滤掉头尾说明行 - 若怀疑是某次部署后出问题，用
date -d "2026-09-28 14:30:00" +%H:%M:%S算出对应系统时区时间，再套进-s/-e -
sar -r -f /var/log/sa/sa15 | awk '$5 > 98 {print $1,$2,$5}'—— 快速筛出%memused超 98% 的时间点（$5 是字段序号，不同版本可能偏移，先sar -r -f /var/log/sa/sa15 | head -2确认列对齐）
关联进程线索：sar -q 和 sar -w 辅助判断
内存耗尽往往伴随负载飙升和频繁上下文切换，单看 sar -r 容易漏因：
-
sar -q -f /var/log/sa/sa15查runq-sz（运行队列长度）和ldavg-1（1 分钟负载）：若两者同步冲高，说明 CPU 在疯狂调度内存紧张的进程 -
sar -w -f /var/log/sa/sa15看cswch/s（每秒上下文切换数）：正常值一般 %memused 峰值重合，极可能是 OOM Killer 启动前兆 - 注意：
sar不记录具体哪个进程吃内存，要定位罪魁得结合当时dmesg | grep -i "killed process"或journalctl --since "2026-09-28 03:15:00" | grep -i oom
真正难的不是查数据，而是理解 kbmemavail 和 %memused 的计算逻辑——它们依赖内核的 memory reclaim 机制反馈，而该机制在 cgroup v2 或容器环境下可能被干扰；如果服务器启用了 memory.low 或 memory.min 限制，sar -r 显示的 available 会虚高，这时候必须交叉验证 cgroup 内存统计。
