AWS Docker环境下Ruby应用内存泄漏，服务器无响应但OOM Killer未触发？

这种情况我之前在AWS容器环境里踩过坑，明明预期OOM Killer会干掉内存泄漏的Ruby进程，结果反而把整台服务器搞僵死了，太闹心了。咱们来一步步捋清楚问题出在哪，以及怎么解决：

首先得搞明白OOM Killer的逻辑：它会根据进程的oom_score_adj值（越低越不容易被杀）和内存占用情况，选择“性价比”最高的进程杀掉，释放内存。没触发或者没杀Ruby进程，大概率是这几个原因：

• Docker容器没设内存上限：如果你的容器没配置--memory参数，它会无限制占用宿主机内存，直到宿主机内存+swap全耗尽。这时候OOM Killer可能先杀系统关键进程（比如sshd、docker daemon），导致SSH连不上、Web服务挂掉，反而没轮到Ruby进程。
• Swap配置拖慢了OOM触发时机：AWS默认有些实例是开启swap的，当内存耗尽后系统会疯狂用swap，进入“swap thrashing”状态——CPU全用来处理内存交换，系统彻底卡死，OOM Killer根本没机会正常工作。
• Ruby进程的OOM优先级太高：如果Ruby进程的oom_score_adj值比其他进程高（比如默认是0，而系统进程是负数），OOM Killer会优先杀其他低优先级进程，直到系统彻底无响应。

先搞清楚问题根源，再动手解决：

1. 检查容器内存限制：
   用docker inspect <你的容器ID>查看HostConfig下的Memory和MemorySwap字段，如果都是0，说明没设内存限制，这就是问题核心。
2. 查看OOM Killer日志：
   重启服务器后，执行dmesg | grep -i oom或者cat /var/log/messages | grep -i oom，看看有没有OOM Killer的操作记录——说不定它之前触发过，但杀的是sshd或者docker进程，导致你连不上服务器。
3. 检查Swap使用情况：
   执行free -h，如果之前Swap被占满（Used接近Total），那就是swap拖垮了系统，OOM Killer没来得及处理Ruby进程。
4. 查看Ruby进程的OOM优先级：
   在宿主机执行ps -eo pid,comm,oom_score_adj | grep ruby，如果Ruby的oom_score_adj是0或者正数，而系统进程（比如systemd）是负数，那OOM Killer肯定先杀其他进程。

按优先级从易到难来：

• 给容器设置内存硬限制：
  启动容器时加上--memory=1.5g --memory-swap=1.5g（根据你的应用正常内存使用量调整，比如正常用1G，设1.5G）。--memory-swap设成和--memory一样，相当于禁用容器的swap，这样内存到上限时OOM Killer会立刻杀掉容器内的Ruby进程，不会拖垮宿主机。
• 调整Ruby进程的OOM优先级：
  在容器的启动脚本里，给Ruby进程设置更低的oom_score_adj，比如：

  # 启动Ruby应用后，找到进程ID并调整优先级
  RUBY_PID=$(pidof ruby)
  echo -100 > /proc/$RUBY_PID/oom_score_adj
  

  这样OOM Killer会优先考虑杀掉Ruby进程，而不是系统关键进程。
• 监控内存使用，主动重启容器：
  用AWS CloudWatch监控容器的内存使用率，设置告警规则（比如内存超过80%时触发），然后用ECS自动重启容器或者Lambda脚本触发重启，比等OOM Killer更主动，减少服务 downtime。
• 修复Ruby应用的内存泄漏：
  这才是根本解决办法。用memory_profiler或者ruby-prof工具分析应用内存使用，找到泄漏点——比如未清理的全局变量、无限追加的数组、没释放的数据库连接等。举个例子，用memory_profiler：

  require 'memory_profiler'
  
  report = MemoryProfiler.report do
    # 运行你的应用核心逻辑，比如处理一个请求
    YourApp.process_request
  end
  
  report.pretty_print(to_file: 'memory_profile.txt')
  

  然后查看memory_profile.txt里的内存增长热点，针对性修复。

内容的提问来源于stack exchange，提问作者EightyEight