韩国VPS服务器OOM问题如何解决?

今年四月份的一个晚上，我正在首尔的酒店里整理文档，手机突然收到了一大串报警信息。是之前合作过的一家做韩国化妆品直邮的客户老金发来的，附带着一句语音：“哥，服务器又挂了，这个月第三次了!”

我远程连上他那台韩国VPS，看了几分钟日志，心里就有数了。OOM Killer出手了。最关键的进程被系统直接杀掉，网站彻底瘫痪，所有正在处理的订单都卡在了半路上。老金在语音里的声音带着明显的无助：“每次都是跑几天就崩，重启之后又正常，我快被搞疯了。”

老金这台服务器放在首尔的数据中心，跑的是一个韩国本地美妆电商系统，日活用户不算多，也就几千人。但最近他们在做促销活动，流量涨了不少，服务器开始频繁出现内存不足的问题。每次都是DBA或者Web服务进程被OOM Killer干掉，留下一句“Out of memory: Kill process”的内核日志，然后就没了下文。

那一晚，我帮他从根源上解决了这个问题。不只是简单地关掉OOM Killer或者加内存，而是找到了内存被吃光的真正原因。今天，我就借着这个案例，跟兄弟们好好聊聊：韩国VPS上的OOM问题，到底该怎么解决?

OOM到底是什么?别把它当成一个“神秘事件”

OOM是Out Of Memory的缩写。翻译成人话就是：系统内存用光了，撑不住了。

Linux内核里有一个机制叫OOM Killer。当系统内存耗尽的时候，它会启动一个“投票程序”，给所有正在运行的进程打分。得分最高的那个进程，会被认为是最“该死”的——通常是最占内存的那个，或者是优先级最低的那个。然后内核会毫不犹豫地把它杀掉，释放出一些内存，让系统能够继续运行。

很多人把OOM Killer当成一个bug，觉得是系统“乱杀人”。其实不然。OOM Killer是系统的最后一道防线。 如果没有它，内存耗尽之后系统会直接死锁，连键盘都敲不动，只能硬重启。OOM Killer虽然粗暴，但至少让系统还有机会活下来。

韩国VPS上的OOM问题之所以常见，跟韩国本地的业务特点有关系。韩国带宽快、网络延迟低，很多创业者喜欢在韩国部署高频率的实时服务，比如直播、游戏、聊天、证券行情等。这些业务的流量波动非常大，瞬间的内存峰值很容易触发OOM Killer。

韩国本地案例：三个“OOM翻车”现场

这一年多，我帮不少在韩国做业务的朋友处理过OOM问题。下面这三个案例，每一个都很有代表性。

案例一：首尔某直播平台的“主播一开播就崩”

这个客户做的是韩国本地的秀场直播，类似国内的直播平台。他们发现一个非常诡异的问题：每次某个人气主播开播，前几分钟服务器还好好的，大概五到十分钟之后，整个推流服务就会突然挂掉。

我们看了内核日志，发现是Nginx进程被OOM Killer杀掉了。进一步追踪内存使用情况，发现Nginx的进程在主播开播之后的几分钟内，内存占用从一百兆飙升到了好几个G。

真相是这样的： Nginx配置里打开了proxy_buffering，而且缓冲区大小设置得非常大。主播推流的数据被Nginx先缓冲起来再转发，缓冲区越积越大，最终把内存吃光了。更麻烦的是，韩国这边的网络质量很好，推流码率很高，同样的缓冲区设置，在韩国消耗的内存比在其他地方大得多。

解决方案是优化Nginx的缓冲区配置。 把proxy_buffering关掉，或者大幅减小缓冲区大小。另外给Nginx进程设置了内存上限，超过上限就自动丢弃新的连接，而不是让内存无限膨胀。改完之后，主播开播再也不会把服务器搞崩了。

案例二：釜山某游戏公司的“凌晨四点准时被杀”

这家公司在釜山，做的是手游海外发行。他们有一台韩国VPS专门跑游戏的排行榜服务。奇怪的是，这个服务每天凌晨四点左右一定会崩溃一次，非常准时。

我蹲了两天的监控数据，发现了一个规律：凌晨四点整，内存占用会突然跳升一大截，然后缓缓下降，但如果下降得不够快，OOM Killer就会介入。

后来查了定时任务，发现凌晨四点正好是数据库备份脚本运行的时间。这个备份脚本用的是mysqldump，会把整个数据库的内容导出成SQL文件。数据库有好几个G的大小，mysqldump在运行期间会占用大量内存来缓存数据，跟排行榜服务抢起了内存。

解决方案是做错峰调度。 把数据库备份的时间改到了凌晨三点，跟排行榜服务的流量低峰期错开。同时给mysqldump加了--quick参数，让它不要缓存全部结果，而是边读边写，内存占用大大降低。改完之后，凌晨四点的“准时死亡”就再也没有发生过。

案例三：仁川某跨境电商的“容器频繁被杀死”

这家公司在仁川，做的是中韩双向的跨境电商。他们把所有的服务都跑在Docker容器里，用Kubernetes管理。他们发现有一个订单处理容器经常被杀死，重启之后又能撑一段时间，但过不了多久又会死。

我们查了K8s的事件日志，发现这个容器触发了内存限额的硬限制，被cgroup的OOM给终结了。容器的内存限制是1G，但程序实际使用经常超过1G。

进一步分析，这个订单处理程序在处理某些特殊的大订单时，会把整个订单的所有历史记录一次性加载到内存里做计算。平时订单小没事，但偶尔会出现一个包含了上百件商品的超大订单，加载的记录太多，内存就爆了。

解决方案是把一次性加载改成流式处理。 不把全部历史记录都塞进内存，而是分批次从数据库读取，每次只处理一小部分。改完之后，同样的超大订单，内存占用从接近1G降到了两百兆左右，再也没触发过OOM。

实战解法：OOM问题的五个解决方向

说完了案例，咱们来点实际的。OOM问题的解决方案，我把它分成五个方向，每个方向解决不同层面的问题。

方向一：定位元凶，搞清楚谁吃了内存。

OOM发生之后，第一件事不是重启，而是查日志。执行dmesg -T | grep -i "oom"，内核会把被杀进程的信息留在这里。你会看到类似这样的输出：

Out of memory: Kill process 12345 (java) score 987 or sacrifice child

Killed process 12345 (java) total-vm:4GB, anon-rss:2GB, file-rss:0MB

这里告诉了你三件事：哪个进程被杀、它占了多少虚拟内存、它占了多少物理内存。知道了是谁，你才能去追查为什么它会吃这么多内存。

方向二：调整OOM Killer的行为，让“该死”的进程更合理。

有时候OOM Killer选错了目标，把重要的服务进程杀掉了，反而留下了一些无关紧要的进程。你可以手动调整每个进程的OOM分数。

在进程的/proc目录下，有两个文件可以控制OOM行为：

/proc/[pid]/oom_score_adj的取值范围是-1000到1000。设置成-1000，这个进程就永远不会被OOM Killer选中。设置成正数，它被选中的概率就越大。

/proc/[pid]/oom_adj是老接口，取值范围是-17到15。-17代表禁用OOM Killer对这个进程的裁决。

如果你想把数据库进程保护起来，可以在启动脚本里加上：

echo -1000 > /proc/$(pidof mysqld)/oom_score_adj

方向三：给系统设置“软保险”，别让内存用得太绝。

Linux内核有一个内存超卖机制，叫做overcommit。简单说就是，系统允许应用程序申请比实际物理内存更多的虚拟内存，因为它觉得你不会真的全部用上。但这个机制在内存紧张的时候会让OOM更容易发生。

你可以通过调整vm.overcommit_memory和vm.overcommit_ratio来控制这个行为。

vm.overcommit_memory=0是默认策略，系统会估算有没有足够的内存，但不会特别严格。vm.overcommit_memory=1是永远允许overcommit，风险最大。vm.overcommit_memory=2是最严格的，禁止overcommit，申请的内存不能超过物理内存加上交换分区的一定比例。

对于生产环境，如果你对稳定性要求很高，可以考虑设置成2，虽然可能会让某些程序内存申请失败，但总比触发OOM Killer杀掉进程要好。

方向四：程序层面加“护城河”，自己管好自己。

与其依赖内核来救你，不如在程序里自己做好防护。

Java程序可以用-Xmx限制堆内存的最大值。Go程序可以用runtime.GOMAXPROCS和debug.SetMemoryLimit。Node.js可以用--max-old-space-size限制V8堆的大小。

对于跑在容器里的服务，设置好memory.limit_in_bytes。这个限制比内核的OOM Killer更早介入，K8s会在容器接近内存上限的时候先尝试驱逐，而不是直接杀死。

方向五：增加交换分区，给内存“缓一缓”。

很多人觉得交换分区是低速的，应该关掉。这个观点不完全对。在物理内存接近耗尽的时候，交换分区可以起到一个缓冲的作用，让系统有时间去处理内存压力，而不是立刻触发OOM Killer。

特别是对于韩国VPS这种普遍使用高速固态硬盘的环境，交换分区的性能比传统机械硬盘好很多。设置一个合适的交换分区，利大于弊。

一般建议交换分区的大小等于物理内存的大小，或者至少是物理内存的一半。可以通过swapon命令查看当前的交换分区使用情况。

预防手册：不让OOM再来找你

经过了这几场“救火”，我总结了一些预防OOM的习惯，希望对在韩国做服务器的兄弟们有帮助。

习惯一：监控要看到“趋势”。 只看瞬时的内存使用率是不够的。你需要看的是内存使用的变化趋势。如果内存以一个稳定的斜率持续增长，即使现在的数值不高，过几天也会触发OOM。用Prometheus配合Grafana，画出内存使用的时间序列图，一眼就能看出问题。

习惯二：压测要覆盖“峰值”。 很多OOM问题在平常流量下根本看不出来，只有到了高峰才会暴露。上线之前，用压测工具模拟至少两倍于预期的峰值流量，看看内存会不会爆。

习惯三：内存快照要定期做。 对于Java、Python、Node.js这类有垃圾回收的语言，定期做堆转储分析，可以帮你发现那些“该回收但没回收”的对象。很多内存泄漏在早期非常隐蔽，但堆转储会让它现出原形。

习惯四：限流要到位。 OOM有时候不是程序的问题，而是流量的问题。某个接口突然涌入大量请求，每个请求都占用一些内存，积少成多就把内存吃光了。在Nginx或者网关层做好限流，是避免OOM的第一道防线。

习惯五：了解韩国的网络和业务特点。 韩国本地带宽高、延迟低、用户活跃度高，同样的程序部署在韩国，面对的压力可能比其他地方大很多。不要拿别处的配置和经验直接套用在韩国VPS上。

总结

回到最开始那个问题：韩国VPS服务器OOM问题如何解决?

我的答案是：别把OOM Killer当成敌人，把它当成一个信号。它在告诉你，你的内存管理出了问题。

那一晚在首尔的酒店里，帮老金把OOM问题彻底解决之后，他长舒了一口气：“我一直以为这台VPS配置不够，准备换更大的机器。现在看来，是我想错了方向。”

是的，很多人一遇到OOM，第一反应就是“加内存”。加内存当然有用，但它只是把水位线抬高了，并没有解决问题本身。如果你的程序存在内存泄漏或者内存管理不当的问题，加再多的内存，迟早也会被吃光。

解决OOM问题，正确的顺序是：先定位元凶，搞清楚谁吃了内存、为什么吃。然后对症下药，该改代码的改代码，该调配置的调配置。最后才考虑要不要扩容。跳过前两步直接扩容，只会让问题被掩盖，然后在更远的将来以更大的规模爆发。

最后送大家一句话：OOM Killer不是凶手，它只是执行了最后那一刀。真正的凶手，是你代码里那个一直借内存却不还的角落。 学会排查、学会预防，你的韩国VPS才能真正做到“长治久安”。希望每一个在韩国做服务器运维的朋友，都能从“手忙脚乱”走向“心里有底”。