1. 事故背景与现象还原

那天凌晨3点17分，监控系统突然发出刺耳的警报声。我们一个日均处理2000万请求的订单服务集群，在没有任何流量突增的情况下，开始出现大面积服务不可用。登录服务器查看，发现一个诡异现象：系统物理内存明明还有12GB空闲（总内存32GB），但Java进程却不断抛出OOM（OutOfMemoryError）异常，最终导致容器崩溃重启。

更奇怪的是，这个问题只发生在生产环境的K8s集群中，而测试环境和预发布环境（配置完全相同）从未复现过。查看监控历史数据，发现每次OOM前都会出现一个共同特征：系统负载（Load Average）在10分钟内从1.5飙升到35+，同时kswapd进程的CPU占用率突破90%。

2. 排查过程全记录

2.1 第一轮排查：内存泄漏？

我们首先怀疑是内存泄漏。使用jmap导出了堆内存快照，但MAT分析显示堆内存占用仅1.2GB（Xmx设置为4GB），老年代使用率稳定在70%左右。进一步检查非堆内存（Metaspace、Code Cache等）也都在合理范围内。这完全解释不通——明明还有充足内存，为什么系统坚持认为内存不足？

2.2 关键线索发现

在检查系统日志时，一条之前被忽略的警告引起了我的注意：

kernel: [98765.432100] Out of memory: Kill process 12345 (java) score 888 or sacrifice child

这行日志暴露了真相——是Linux内核的OOM Killer机制杀死了我们的Java进程。但为什么内核会觉得内存不足？带着这个疑问，我执行了free -h命令，终于发现了问题所在：

total used free shared buff/cache available Mem: 32Gi 19Gi 12Gi 1.0Gi 1.5Gi 11Gi Swap: 0B 0B 0B

生产环境的所有节点竟然都没有配置swap分区！而测试环境默认安装了桌面环境，自动创建了swap文件。

3. 技术原理深度解析

3.1 Swap的作用机制

Swap空间本质上是磁盘上的一块特殊区域，当物理内存不足时，内核会将部分暂时不用的内存页（Page Out）交换到磁盘，腾出空间给急需的进程使用。虽然磁盘IO速度远低于内存，但这套机制能有效防止进程因内存不足被直接杀死。

在K8s环境中，swap默认是被禁用的（vm.swappiness=0），主要出于以下考虑：

1. 容器编排系统需要准确评估节点资源余量
2. 交换导致的性能抖动可能破坏SLA
3. 传统认知认为云服务器应当配置充足内存

3.2 我们的特殊场景

我们的订单服务使用了大量堆外内存（Netty的Direct Buffer、JNI调用等），这些内存不受JVM控制，但会占用系统内存。当突发流量到来时：

1. 大量网络数据包到达，Netty申请Direct Buffer
2. 物理内存充足，但内核发现swappiness=0拒绝使用swap
3. 同时kswapd疯狂尝试回收内存（导致高负载）
4. 最终触发OOM Killer选择"最胖"的Java进程杀死

4. 解决方案与实施

4.1 临时补救措施

我们立即在所有节点创建了4GB的swap文件：

# 创建swap文件 dd if=/dev/zero of=/swapfile bs=1G count=4 chmod 600 /swapfile mkswap /swapfile swapon /swapfile # 调整swappiness echo 'vm.swappiness=10' >> /etc/sysctl.conf sysctl -p

这个值经过特别计算：32GB内存 × 10% = 3.2GB，略小于swap文件大小，确保不会过度交换。

4.2 长期优化方案

1. JVM层优化：

   • 限制堆外内存使用：-XX:MaxDirectMemorySize=2g
   • 启用NIO的buffer池：-Dio.netty.allocator.type=pooled

2. 系统层加固：

   # 防止单个进程占用过多内存 echo 'vm.overcommit_memory=2' >> /etc/sysctl.conf echo 'vm.overcommit_ratio=80' >> /etc/sysctl.conf

3. 监控体系升级：

   • 增加对DirectBuffer使用量的监控
   • 对/proc/meminfo中的SwapCached指标设置告警

5. 经验总结与避坑指南

5.1 关键教训

1. 不要盲目禁用swap：特别是对于使用堆外内存的Java应用，适度的swap能提供安全缓冲

2. 内存监控要全面：不能只看JVM堆内存，必须包含：

   • /proc/meminfo中的MemAvailable
   • JDK的BufferPoolMXBean
   • Kernel的Slab内存统计

3. 压测环境要与生产完全一致：包括内核参数、swap配置等

5.2 推荐配置公式

对于Java服务，建议按以下原则配置swap：

swap_size = min(4GB, physical_memory × 20%) swappiness = max(10, min(30, 100 - (physical_memory_in_GB × 2)))

比如32GB内存的机器：

• swap文件：4GB（32×20%=6.4，取min）
• swappiness：10（100-64=36，取max(10,min(30,36))=30，但经验值建议更低）

6. 延伸思考：云原生时代的swap

这次事故引发了我们团队对云原生环境下内存管理的重新思考。现代容器化部署中，swap确实可能带来一些挑战：

• 影响调度器对Pod资源的准确判断
• 交换延迟可能导致应用超时
• 在SSD上频繁交换可能影响磁盘寿命

但完全禁用swap就像开车不系安全带——在平稳运行时毫无问题，一旦出现意外就可能造成严重后果。我们的新策略是：

• 为关键业务Pod设置requests=limits（禁用swap）
• 对弹性服务适当放宽限制，允许有限度的交换
• 在节点级保留基础swap作为最后防线