凌晨值班时，1GB VPS 的监控曲线连续三天卡在 98%，业务却只是偶发卡顿，重启后占用又立刻降到 20%。此时最危险的不是“内存高”，而是把缓存占用、容器限额、宿主机争抢和真实 OOM 混为一谈。误判会把优化方向带偏，漏判则可能在高峰时直接丢掉业务进程。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：nuyek（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
限额决定边界：先确认进程属于哪个 cgroup，并核对 memory.max、memory.high 与 swap.max 是否一致。若容器限额是 512MB，却拿宿主机 4GB 总内存计算，96% 实际可能只表示容器接近上限；若限额尚未触顶，VPS 面板里的高占用也可能来自宿主机统计口径。
水位要看 memory.current、匿名页和文件页。匿名页通常对应进程工作集，文件页多为可回收缓存。持续上涨的匿名页更值得警惕，page cache 很大但回收顺畅，未必是内存泄漏。用 rss、used 或 free 混读不同层级数据，很容易得出相反结论。
还要观察内存回收行为：正常回收应缩低文件缓存，匿名页压力高时则可能频繁换页。缓存下降后延迟恢复，属于回收后的短期抖动；若回收频率、换页量和业务延迟同步升高，说明系统正在用 CPU 与 I/O 换取内存空间。
PSI 压力指标比单点水位更能说明影响。memory 的 avg10 连续处于高位，表示任务频繁因内存回收而停顿；full 指标上升，说明连分配内存的完整操作都受到影响。判断时应同时看 60 秒、300 秒窗口，并对照请求延迟，避免把几秒钟的尖峰误当成长期超售。
OOM 证据要形成闭环：检查 cgroup 的 memory.events，重点关注 oom、oom_kill 是否持续增加，再从 systemd 日志、内核日志和应用错误记录确认被杀进程及时间。若 used 很高却没有 OOM、回收后业务稳定，可能是缓存膨胀；若 oom_kill 增长且进程栈指向应用泄漏，就是实例内部问题，换机只能暂时缓解。
宿主机超售不能仅凭内存百分比证明。VPS 内通常看不到宿主机 PSI，只能结合同节点实例同时变慢、CPU steal 升高、网络抖动及无法解释的回收停顿做旁证。若压力只发生在自己的容器，应先限制并发、修正内存泄漏；若多台实例同时异常且本机限额充足，迁机优先级才会明显上升。可用随身服务器持续记录水位、PSI、回收和 OOM 事件，再按“持续超限、压力累积、OOM 增长、同节点连带异常”四项决定迁机，避免因一次尖峰频繁搬箱。
只看 free -h 很容易误判。Linux 会利用空闲内存做页缓存，因此 available 较低并不等于内存紧张。应同时观察 内存水位监测：重点关注 MemAvailable、匿名页、页缓存、SwapIn/SwapOut，以及一段时间内缓存是否持续被回收。如果 used 很高但 available 尚可，且 SwapIn/SwapOut 很低，通常只是缓存占用；如果 available 持续下降、Swap 频繁换入换出、进程响应明显变慢，才说明系统正在经历真实压力。
PSI压力指标 能补充传统水位看不到的信息。/proc/pressure/memory 中的 some 和 full，分别表示至少部分任务和全部任务因内存资源受阻的时间比例。psi some 持续升高，说明部分任务经常在内存回收或换页上等待；psi full 明显升高，则可能已经影响业务调度。判断时应使用较短采样窗口观察趋势，并结合节点级指标，因为单次瞬时峰值未必代表持续超售。
OOM事件分析 不能只依赖 dmesg。内核日志、systemd-oomd、容器运行时事件、cgroup memory.events 以及监控平台都可能记录不同层面的 OOM。应确认被杀进程、cgroup、发生时间、当时的 PSI、Swap 和 dirty page 状态，再区分“宿主机整体 OOM”“容器限制触发 OOM”以及“应用自身申请内存失败”。同一时间出现大量 memory.events 中的 oom_kill，通常比单个日志更具代表性。
内存回收并非越快越好。正常情况下，内核会回收页缓存、清理不活跃匿名页，并在必要时执行 Swap。异常情况下可能出现高频 direct reclaim、Swap 抖动、THP 分配等待，甚至为了满足某次突发申请而触发 OOM。排查时应区分主动回收与被动回收：前者通常由分配路径触发，后者可能伴随明显延迟。还要检查是否存在内存泄漏、缓存无上限、连接数失控、容器 limit 设置过小、Swap 被禁用或宿主机与 VPS 的资源统计口径不同等问题。
容易踩的坑包括：仅凭 free 命令中的 used 判断超售；把缓存占用全部当成泄漏；忽略 PSI full 和 OOM 的时间关联；只查看当前容器，不检查宿主机；反复手动 drop_caches 制造假象；以及通过增加 Swap 来掩盖真实的内存不足。这样做虽然暂时避免进程被杀，却可能让延迟和抖动更加严重。
建议按以下顺序执行：先确认 VPS 套餐标称内存与 cgroup 限制；再连续采集 free -v、/proc/pressure/memory、vmstat、sar -W 和 memory.events；随后回溯 OOM 日志、进程重启记录及业务延迟；检查 Swap 开关、换页速率、缓存回收频率和容器限制；最后进行短时压力测试，对比 RSS、PSI、SwapIn/SwapOut 与响应时间。若发现 available 持续下降、Swap 频繁换入换出、psi some/full 升高，并伴随 OOM 或明显延迟，可基本判断存在 VPS内存超售 或资源限制不合理。处理时应优先修复泄漏和异常进程，合理设置容器内存与缓存上限，保留少量 Swap 作为缓冲，同时联系服务商确认宿主机是否存在持续的 内存水位监测 异常和资源争抢。
