更新于 2026-10-06

服务器内存 88% 算高吗？该查什么、怎么判断

简短回答：Linux 服务器内存使用率 88% 本身不能说明有问题，因为系统会把空闲内存拿去做页缓存。先看 free -m 的 available 列、vmstat 1 里 swap 的 si 和 so，再查内核日志有没有 OOM 记录。只有可用内存持续偏低，同时频繁换页或出现 OOM，才说明内存真的紧张。

88% 算不算问题？先看 available，别看 used

Linux 会把最近读过的文件留在内存里（页缓存，free 里显示为 buff/cache），因为闲着的内存本来就没用。应用需要内存时，这部分缓存大多会被让出来，所以“已用”“使用率”很高，往往只是缓存占满了。tmpfs 和共享内存也算在缓存里，但不能直接释放。

真正要看的是：新的程序还能拿到多少内存而不用换页。内核把这个估算值叫 MemAvailable，free 里显示为 available。监控工具的百分比可能按“已用”算，也可能按“可用”算，看到 88% 这样的数字，先弄清它是怎么算的。

下面的命令都只查看状态，只在你有权限的服务器上执行。

一步步判断

1. 看可用内存

free -h

看 Mem: 这一行的 available 列，不要看 free 或 used。free 很小、buff/cache 很大是正常现象。隔几分钟多看几次，或者对照监控历史：单次采样看不出趋势。

2. 用 /proc/meminfo 核对

grep -E 'MemTotal|MemAvailable|SwapTotal|SwapFree' /proc/meminfo

MemAvailable 是内核估算的、不换页就能给新程序用的内存，free 的 available 列就是从这里读的。SwapTotal: 0 kB 表示这台服务器没有 swap，第 3 步会一直是 0，内存不够时直接表现为 OOM。

3. 看换页活动

vmstat 1 5

第一行是开机以来的平均值，跳过。后面几行里，si 和 so 是每秒从磁盘换入、换出到磁盘的内存量。swap 有占用但 si、so 都是 0，说明现在没在换页，不是眼下的问题。available 一直偏低，同时持续换页，才说明现在内存不够用。

4. 看内存压力（PSI），如果内核支持

cat /proc/pressure/memory

支持 PSI 的内核（Linux 4.20 及以后，且已开启）里，some 行是“至少有一部分任务在等内存”的时间占比，分别按 10 秒、60 秒、300 秒平均；full 行是“所有非空闲任务同时在等内存”的时间占比。数值持续大于 0，说明内存确实在拖慢程序。没有这个文件就跳过这一步。

5. 看是谁在用内存

ps -eo pid,user,rss,comm --sort=-rss | head -n 15

RSS 是常驻内存，单位 KiB。共享的内存页会在每个用到它的进程上各算一次，所以这一列加起来可能超过总内存。用它找出占用最大的进程，再看这些进程是不是在持续变大。在 top 里按 Shift+M 可以按内存排序。

6. 查有没有 OOM

sudo dmesg -T | grep -i -E 'out of memory|oom-killer|killed process' | tail -n 20
sudo journalctl -k --since "24 hours ago" | grep -i -E 'out of memory|oom-killer|killed process'

出现 Out of memory: Killed process …，说明内核当时不得不杀掉一个进程来腾内存，这是内存不够的直接证据。如果是容器，先看 这个退出码是什么意思，137 的深入排查见 Docker 退出码 137 与 OOMKilled。

合起来看

重启某个进程、调整它的内存配置、加 swap 或换更大的服务器都属于变更，事先准备好回退办法。

真实案例：服务器内存升到 88% 时，OpsMate 记录了什么

系统上线后，开发者未必会一直盯着服务器。真正需要的是：出现值得关注的变化时，能看到异常依据、收到通知，并知道下一步该查什么。

这个案例来自 OpsMate（itops.sh）在 Google Cloud 测试环境中管理实际服务器的运行记录，不是编造的演示数据。服务器、用户与 Telegram 会话标识已隐去。这是异常发现和通知案例，不是已经完成修复的案例。

巡检首先记录了一个异常信号

2026 年 9 月 15 日，一次巡检记录了 CPU 使用率 0%、内存使用率 88%、磁盘使用率 64%，将内存情况判为异常，问题优先级为 P2。88% 是本次指标值，不是适用于所有服务器的统一阈值；单次采样也不能代表持续状态。

不把“内存高”直接写成“内存泄漏”

这条事件中的进程内存与堆分析证据均标记为不可用。因此，不能据此判断哪个进程出问题，更不能确认存在内存泄漏。

系统记录的建议包括查看内存情况、检查占用较高的进程，再判断是否需要进一步分析。下面是记录中出现的检查建议，没有证据表明它们已在这次事件中执行：

free -m
ps -eo pid,rss,comm --sort=-rss | head

对开发者而言，这把“服务器看起来不太对”变成了可以开始核查的问题。对专业运维而言，真正有用的是指标、时间与证据缺口，而不是过早下定论的答案。

Telegram 有发送记录，不等于人已读

事件时间为 07:32:35.788 UTC，Telegram 通知发送时间为 07:32:37.681 UTC，相差约 1.9 秒。通知类型为需要人工介入，投递状态记录为 sent。

这说明本次事件留下了通知发送成功的记录，不代表我们核实了手机弹窗、用户阅读或处理情况，也不是通知延迟的性能承诺。

后续是否修复？这次取证还没有答案

在读取记录时，问题仍处于异常状态，没有修复验证通过的结果。因此，不能称为自动修复成功，也不能宣称服务已经恢复。

下一步应由负责人核对可用内存、进程占用与变化趋势，判断是否需要调整应用、容量或监控规则。具体变更仍需要风险评估与验证。

这正是运维助手该做的部分

初期没有专职运维时，开发者需要帮助发现变化、整理下一步检查方向。系统规模扩大后，专业运维需要减少重复的信息收集，同时保留判断与变更控制。

这次记录能证明的范围很具体：巡检发现了一次内存异常，生成问题，并留下 Telegram 通知发送记录与后续检查建议。它不能证明诊断和修复已经完成。

可以从连接一台服务器、确认适合它的监控项开始，并实际测试通知是否到达自己的手机。参阅小团队 VPS 监控清单。

排障指南