一台8G内存的VPS上线监控采集后，接口延迟从80毫秒升到数秒，任务进程还可能被直接杀掉；另一台机器的Swap读入持续升高，却始终没有出现OOM记录。两者都表现为内存高，但一个关乎进程被终止，一个关乎磁盘换页拖慢响应。只盯着free或负载曲线，很容易把方向判错。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：netjett（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
随身服务器可辅助查看实例的运行时间、资源趋势和告警记录，判断异常是否与重启、发布或流量变化同步，为后续定位内存增长提供时间线。
OOM Killer触发发生在内核无法从回收缓存和Swap中取得足够内存时。它通常选择占用较高、回收代价较大的进程终止，因此整机还有剩余内存、某个服务却突然退出时，也要检查cgroup限额。可在dmesg或journalctl中搜索oom、killed process等记录，并核对被终止进程所在容器的memory.max。
交换分区抖动则是内存页频繁换入换出，磁盘随机读写把请求延迟推高。此时vmstat中的si、so持续非零，PSI的some或full压力明显，但OOM Killer未必触发。常见误区是把缓存当成泄漏：缓存可被内核回收，匿名内存持续增长才更值得警惕。OOM与Swap抖动也可能先后出现，不能只凭一次free结果下结论。
先用ps按RSS排序，再用pmap或smaps查看进程的私有映射；容器环境不能只看宿主机进程排行，还要检查cgroup的memory.current、memory.stat和memory.events。若某个Java、Node.js或Python进程的RSS不断抬升，且重启后立即恢复，应重点排查堆内存、缓存对象数量以及请求处理后的释放逻辑。
判断内存增长要同时看数值和斜率。稳定在高位后波动，多半是缓存或正常流量；匿名内存连续多个采样周期单调上升，更像泄漏；发布后瞬间跳高，则应关联任务队列、并发数和子进程数量。可按固定间隔记录/proc/PID/status的RSS、VmRSS与VmSwap，再与流量、发布记录叠加，而不是凭一次快照认定异常。
定位到根因后再调整限制。若实际工作集超过cgroup或systemd的MemoryMax、容器memory限制，应先修复泄漏，再逐步提高额度并同步设置memory.swap.max；盲目扩大Swap只会掩盖增长问题，盲目关闭OOM保护则可能让整机进入不可恢复状态。最终应以业务延迟、换页速率和进程增长趋势同时改善作为验收依据。
判断 VPS内存溢出 时，要把内存水位放回进程维度：先看 free -h 的 MemAvailable，再用 vmstat 1 观察匿名页、缓存与 si/so。持续非零的 si、so 并伴随延迟升高或吞吐抖动，才说明系统频繁换入换出；Swap Used 很大并不等于当前抖动，闲置换出页可能长期保留。
进程排行也有陷阱。多个进程共享同一库时，RSS 会重复统计，应比较 PSS 或 cgroup 用量。容器内还要核对 memory.limit_in_bytes、systemd 的 MemoryMax 或 memory.max；宿主总内存充足，不代表容器未被限额。继续拆分 memory.stat 中的 anon、file、shmem 和 slab：文件缓存通常可回收，匿名页、线程栈及页表持续增长才更可疑。突然增长的进程可用 smem -s rss 排序，再结合 /proc/PID/status、pmap 和打开文件，确认它究竟在吃私有内存、共享库还是文件缓存。
怀疑 OOM Killer触发 时，不要只找“最大进程”。依次执行 dmesg -T | grep -Ei 'oom|killed process' 和 journalctl -k --since '1 hour ago'，并检查 cgroup 的 memory.events 中 oom、oom_kill 计数及峰值。受害者可能是次要进程，因为它位于压力较大的 cgroup，或被 oom_score_adj 调整过评分。还要区分宿主全局 OOM 与容器 cgroup OOM：后者即使宿主机仍有大量空闲内存也会发生。/proc/pressure/memory 的 some avg10 持续升高，可佐证任务因回收内存而长时间停顿。
① 先留证：记录 free -h、vmstat 1、swapon --show、ps aux --sort=-rss、PSI 与容器配额，保留时间戳；对比业务低峰和高峰，判断增长是阶梯式突增、缓慢泄漏，还是与请求量、批处理同步。再用 top -H -p PID 确认增长来自进程还是线程。
② 定位异常进程：用 smem -s pss 排序，lsof -p PID 检查文件、socket 与映射，排查连接泄漏、消息积压、缓存失控或定时任务重叠。对比进程启动时间与最近发布，检查子进程数量、线程栈和 cgroup memory.stat；不要先重启，否则现场会消失。
③ 确认抖动：连续观察 vmstat 1 的 si/so，用 sar -W 1 查看 major fault，并用 iostat -x 1 看磁盘 await。si/so 为零而 CPU 正常时，应优先排查锁、I/O 或 GC；只有换入换出持续发生且业务延迟同步，才把问题归到交换分区抖动。发现 OOM 日志后，还要核对 memory.events 与限制值。
④ 修复：先停止异常任务或回滚变更，再按根因修正连接池、缓存上限、批处理并发和容器限额，最后评估扩容。增加交换分区只能延缓崩溃，不能消除泄漏或抖动；盲目 drop_caches、swapoff 或 kill -9 会破坏现场，低内存机器上 swapoff 甚至可能触发 OOM。
⑤ 验证与告警：修复后连续观察三个业务周期，确认 PSS、swap 流量、PSI、磁盘延迟和错误率回到基线。配置内存水位、swap 流量、PSI 与 OOM 告警，阈值按正常峰值加余量设置，并保留事故前后的日志和指标用于复盘。
结论：真正的根因通常藏在“哪类内存增长、哪个 cgroup 受限、何时触发回收”这条证据链里。先量化、再定位、后修复，切勿把增加 Swap 当作终点。
