Linux 内存巡检，别只盯着一个使用率

Linux 内存巡检别只盯着一个使用率服务器因为内存压力出问题时监控面板上的“内存使用率”未必很高。Linux 会把空闲内存用于页缓存容器还有各自的 cgroup 限制内核内部的 Slab 也不显示在单个业务进程的 RSS 里。只用一个百分比设告警很容易同时得到误报和漏报。巡检的目标不该是判断机器“健康”或“不健康”而是尽早看出系统是否开始等待内存、哪些层面的用量在异常增长以及出现压力后应该检查什么。指标要放在时间趋势和实际工作负载里解释不能脱离现场直接下结论。从可用内存开始而不是从空闲内存开始MemFree 很低并不必然是问题。内核会尽量用闲置内存缓存文件内容这些缓存必要时可以回收。相比简单计算已用比例MemAvailable 往往更适合判断系统还能否较平稳地分配内存但它也不是唯一信号。如果可用内存持续下降同时应用延迟、换页活动或 I/O 等待增加才更值得关注。一次短暂下降可能来自批处理、备份或正常缓存预热长时间无法恢复才说明需要进一步调查。告警阈值应通过服务自身的负载和恢复速度确定不能照搬一个固定百分比。对容器化服务还要查看 cgroup 的内存统计和事件。宿主机还有余量时某个容器仍可能因为自己的限制而被 OOM 终止。把宿主机指标当成唯一视角会漏掉这类问题。PSI 提示的是等待不是容量账本支持 PSI 的内核会提供任务因资源压力而无法继续运行的时间比例。内存 PSI 上升说明一些任务正在为内存回收或分配等待它能帮助发现“容量看似足够应用却变慢”的场景。不过 PSI 不是一个单独的根因指标仍要结合 CPU、I/O、回收活动和业务延迟分析。采集 PSI 时应说明使用的时间窗口。短窗口对瞬时抖动敏感长窗口更平滑却可能延迟发现问题。告警也适合做持续性判断例如在一段时间内连续超过团队设定的目标后再升级而不是一个样本就通知所有人。若当前内核或环境没有 PSI 接口应明确标记为未采集不能把缺失默认当作零压力。不同发行版、内核版本和容器权限会影响指标是否可见。Slab 增长要看对象和趋势内核会为目录项、inode、网络缓冲等对象分配 Slab。SUnreclaim 增长值得关注但它本身不等于泄漏有些工作负载在高峰后需要时间回收某些对象也会随缓存策略保持一段时间。排查时应看增长是否持续、哪些 slab cache 在增加、是否与特定服务、文件系统操作或网络流量同时发生。不要只根据总 Slab 量重启机器。先保存 slab 信息、内核日志、相关负载和时间线必要时在测试环境复现。若怀疑内核或驱动问题收集与当前内核版本匹配的证据再决定升级、回退或进一步跟踪。巡检日志应保留足够的摘要供趋势分析但不要每次都写出巨大的内核快照。定期轻量采样、异常时加密度采集通常更平衡。Watermark、回收与业务指标需要一起看内存分配会受到 zone、水线和碎片等因素影响。总内存尚有余量时某个 zone 也可能难以满足特定分配。对此普通日常巡检不需要试图复刻内核所有决策但应在异常时能关联到回收、换页、分配失败和 OOM 日志。业务侧指标不能缺席。数据库连接超时、应用请求尾延迟、worker 重启或磁盘写入抖动可能是内存压力最早的用户可见信号。把系统指标与服务指标放在同一时间轴上比增加更多孤立阈值更能定位问题。对会造成明显开销的检查要设置频率与超时。巡检本身不应通过大量扫描、频繁执行昂贵命令或无限保存日志给机器再添负担。采集失败也要可见避免监控静默失效。告警后要有可执行的下一步一条告警最好指出是可用内存持续降低、某个 cgroup 触发 OOM 事件、内存等待上升还是某类 Slab 对象异常增长。不同信号对应不同排查方向。压力来自单一容器时先检查其限制和请求模式全机回收变重时看负载与缓存内核对象异常时保留证据并核对模块和版本。在演练或测试环境中模拟容器接近限制、短时内存尖峰、长期缓慢增长和日志采集失败确认告警不会淹没团队也能在恢复后自动收敛。巡检真正的价值不是多报几种数而是让异常出现时能够更快找到该看的证据和该做的动作。