内存运维的核心，是分清「账面空闲」与「实际可分配」之间的差距。
凌晨三点，某连锁便利店的收银系统卡死，店长对着黑屏发愁——这种场景对 SMB 运维并不陌生。服务器在业务高峰期频繁触发 OOM（Out of Memory，内核层面的内存溢出），运维第一时间登录机器敲下 free -h，却往往被表面的数字误导。问题不在命令本身，而在于看错了字段。
一、free -h 真正该看的是 available
许多运维新手会盯着 free 列，内存空闲越小越紧张。但在 Linux 内存管理机制中，buff（块设备缓存）与 cache（页缓存）虽然占内存大头，但属于可回收内存——内核在需要时可主动释放它们。
available 字段给出的才是「应用实际可申请到的内存估算值」，已经把可回收的 buff/cache 算进去。判断内存是否紧张，第一步是看 available 是不是趋近于 0，而不是看 free 是不是很小。如果只看 free，往往会得出「内存爆了」的误判，而实际系统中可回收缓存可能还有好几个 G。
据 Linux 系统 free 命令的官方说明，free 字段反映的是「完全未被使用的内存」，available 反映的是「在不进行额外交换的情况下可被新进程申请的内存估算」。两者之间存在显著差距，这是内存排障的常识地基。
二、真实缺内存的信号：在 vmstat 里盯 si/so
free -h 看到 available 充足，并不代表万事大吉。当物理内存不足时，内核会触发内存回收，先回收 buff/cache，回收不到就动用 swap（交换分区）——这时在 vmstat 输出中，si（swap in，从磁盘换入）和 so（swap out，换出到磁盘）会出现持续非零的值。
si/so 持续非零是内存压力的硬指标：它意味着系统已经在用磁盘模拟内存，速度比物理内存慢几个数量级，业务响应会明显变慢。如果 si/so 偶发出现然后归零，可能是短时高峰过后的正常波动；但如果长时间持续，就需要警惕——下一步可能就会触发 OOM Killer。
排查常用 `vmstat 1 10`，每秒采样一次连续 10 次，观察 si/so 列的变化趋势。配合 free -h 的 available 趋势、top 的进程内存占用，能拼出比较完整的内存画像。
三、OOM Killer 与 dmesg：定位「谁被杀了」
当内核物理内存和 swap 全部耗尽，会激活 OOM Killer（内存溢出终结者），按照一套评分算法挑选进程强制 kill，以保全系统整体。
事后定位的关键在 dmesg 日志。`dmesg | grep -i oom` 可以筛出内核的 OOM 记录，典型输出包含被 kill 进程的 PID、名称、消耗的内存、当时的内存水位。据 Linux 内核文档关于 OOM Killer 的说明，这条日志是事后复盘的一手证据——没有它，OOM 往往只能靠经验猜。
拿到 OOM 记录后，要看被 kill 的进程是不是「替罪羊」。某些进程占用内存大、存活时间长、贡献了较多「内存税」，会被评分算法优先选中。处理思路通常有两种：调高关键进程在 OOM 评分中的权重，或扩容物理内存。临时缓解可以调整内核 vm 相关参数，但属于风险较高的操作，必须有回滚预案。
四、AI 运维智能体怎么管这件事
内存排障看似是几条命令的组合，实际在生产环境里往往是凌晨告警、信息分散、决策路径不清的复合事件。AI 运维智能体的价值，是把这条证据链串成可审计的剧本。
以 OmegaBrain 为例，它的 L0-L3 分级闸门针对这类场景的设计是：L0 阶段持续采集 free、vmstat、dmesg 关键指标，识别 available 趋势与 si/so 异常；L1 阶段触发主动体检，生成内存画像与近期变更对比报告；L2 阶段在出现 OOM 前兆时，给出「扩容建议」或「重启服务」等剧本，推送设备负责人审批；L3 阶段针对涉及内核参数调整等高危操作，要求先建立回滚点，剧本失败自动转人工兜底。
这套机制的本质是「证据链先看，你批准后才动手」。对家庭多设备用户而言，OmegaHome 守护电视、平板、电脑与客厅电视的稳定性；对门店和企业来说，OmegaBusiness 覆盖服务器与收银机，半夜出事先顶着、高峰前先调好。
内存是服务器最敏感的资源之一。把它当账本看（看 free）还是当水管看（看 available 和流量），决定了排障的方向。让这些判断不再是某个工程师凌晨三点的灵光一现，而是有据可查、有迹可循的标准化流程，这是 AI 运维智能体该做的事。
> 内容来源：公开信息整理；本文部分由OmegaBrain AI助手改写，仅供行业参考。