1. 事故背景与现象还原那天凌晨3点17分监控系统突然发出刺耳的警报声。我们一个日均处理2000万请求的订单服务集群在没有任何流量突增的情况下开始出现大面积服务不可用。登录服务器查看发现一个诡异现象系统物理内存明明还有12GB空闲总内存32GB但Java进程却不断抛出OOMOutOfMemoryError异常最终导致容器崩溃重启。更奇怪的是这个问题只发生在生产环境的K8s集群中而测试环境和预发布环境配置完全相同从未复现过。查看监控历史数据发现每次OOM前都会出现一个共同特征系统负载Load Average在10分钟内从1.5飙升到35同时kswapd进程的CPU占用率突破90%。2. 排查过程全记录2.1 第一轮排查内存泄漏我们首先怀疑是内存泄漏。使用jmap导出了堆内存快照但MAT分析显示堆内存占用仅1.2GBXmx设置为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.swappiness0主要出于以下考虑容器编排系统需要准确评估节点资源余量交换导致的性能抖动可能破坏SLA传统认知认为云服务器应当配置充足内存3.2 我们的特殊场景我们的订单服务使用了大量堆外内存Netty的Direct Buffer、JNI调用等这些内存不受JVM控制但会占用系统内存。当突发流量到来时大量网络数据包到达Netty申请Direct Buffer物理内存充足但内核发现swappiness0拒绝使用swap同时kswapd疯狂尝试回收内存导致高负载最终触发OOM Killer选择最胖的Java进程杀死4. 解决方案与实施4.1 临时补救措施我们立即在所有节点创建了4GB的swap文件# 创建swap文件 dd if/dev/zero of/swapfile bs1G count4 chmod 600 /swapfile mkswap /swapfile swapon /swapfile # 调整swappiness echo vm.swappiness10 /etc/sysctl.conf sysctl -p这个值经过特别计算32GB内存 × 10% 3.2GB略小于swap文件大小确保不会过度交换。4.2 长期优化方案JVM层优化限制堆外内存使用-XX:MaxDirectMemorySize2g启用NIO的buffer池-Dio.netty.allocator.typepooled系统层加固# 防止单个进程占用过多内存 echo vm.overcommit_memory2 /etc/sysctl.conf echo vm.overcommit_ratio80 /etc/sysctl.conf监控体系升级增加对DirectBuffer使用量的监控对/proc/meminfo中的SwapCached指标设置告警5. 经验总结与避坑指南5.1 关键教训不要盲目禁用swap特别是对于使用堆外内存的Java应用适度的swap能提供安全缓冲内存监控要全面不能只看JVM堆内存必须包含/proc/meminfo中的MemAvailableJDK的BufferPoolMXBeanKernel的Slab内存统计压测环境要与生产完全一致包括内核参数、swap配置等5.2 推荐配置公式对于Java服务建议按以下原则配置swapswap_size min(4GB, physical_memory × 20%) swappiness max(10, min(30, 100 - (physical_memory_in_GB × 2)))比如32GB内存的机器swap文件4GB32×20%6.4取minswappiness10100-6436取max(10,min(30,36))30但经验值建议更低6. 延伸思考云原生时代的swap这次事故引发了我们团队对云原生环境下内存管理的重新思考。现代容器化部署中swap确实可能带来一些挑战影响调度器对Pod资源的准确判断交换延迟可能导致应用超时在SSD上频繁交换可能影响磁盘寿命但完全禁用swap就像开车不系安全带——在平稳运行时毫无问题一旦出现意外就可能造成严重后果。我们的新策略是为关键业务Pod设置requestslimits禁用swap对弹性服务适当放宽限制允许有限度的交换在节点级保留基础swap作为最后防线
1. 事故背景与现象还原那天凌晨3点17分监控系统突然发出刺耳的警报声。我们一个日均处理2000万请求的订单服务集群在没有任何流量突增的情况下开始出现大面积服务不可用。登录服务器查看发现一个诡异现象系统物理内存明明还有12GB空闲总内存32GB但Java进程却不断抛出OOMOutOfMemoryError异常最终导致容器崩溃重启。更奇怪的是这个问题只发生在生产环境的K8s集群中而测试环境和预发布环境配置完全相同从未复现过。查看监控历史数据发现每次OOM前都会出现一个共同特征系统负载Load Average在10分钟内从1.5飙升到35同时kswapd进程的CPU占用率突破90%。2. 排查过程全记录2.1 第一轮排查内存泄漏我们首先怀疑是内存泄漏。使用jmap导出了堆内存快照但MAT分析显示堆内存占用仅1.2GBXmx设置为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.swappiness0主要出于以下考虑容器编排系统需要准确评估节点资源余量交换导致的性能抖动可能破坏SLA传统认知认为云服务器应当配置充足内存3.2 我们的特殊场景我们的订单服务使用了大量堆外内存Netty的Direct Buffer、JNI调用等这些内存不受JVM控制但会占用系统内存。当突发流量到来时大量网络数据包到达Netty申请Direct Buffer物理内存充足但内核发现swappiness0拒绝使用swap同时kswapd疯狂尝试回收内存导致高负载最终触发OOM Killer选择最胖的Java进程杀死4. 解决方案与实施4.1 临时补救措施我们立即在所有节点创建了4GB的swap文件# 创建swap文件 dd if/dev/zero of/swapfile bs1G count4 chmod 600 /swapfile mkswap /swapfile swapon /swapfile # 调整swappiness echo vm.swappiness10 /etc/sysctl.conf sysctl -p这个值经过特别计算32GB内存 × 10% 3.2GB略小于swap文件大小确保不会过度交换。4.2 长期优化方案JVM层优化限制堆外内存使用-XX:MaxDirectMemorySize2g启用NIO的buffer池-Dio.netty.allocator.typepooled系统层加固# 防止单个进程占用过多内存 echo vm.overcommit_memory2 /etc/sysctl.conf echo vm.overcommit_ratio80 /etc/sysctl.conf监控体系升级增加对DirectBuffer使用量的监控对/proc/meminfo中的SwapCached指标设置告警5. 经验总结与避坑指南5.1 关键教训不要盲目禁用swap特别是对于使用堆外内存的Java应用适度的swap能提供安全缓冲内存监控要全面不能只看JVM堆内存必须包含/proc/meminfo中的MemAvailableJDK的BufferPoolMXBeanKernel的Slab内存统计压测环境要与生产完全一致包括内核参数、swap配置等5.2 推荐配置公式对于Java服务建议按以下原则配置swapswap_size min(4GB, physical_memory × 20%) swappiness max(10, min(30, 100 - (physical_memory_in_GB × 2)))比如32GB内存的机器swap文件4GB32×20%6.4取minswappiness10100-6436取max(10,min(30,36))30但经验值建议更低6. 延伸思考云原生时代的swap这次事故引发了我们团队对云原生环境下内存管理的重新思考。现代容器化部署中swap确实可能带来一些挑战影响调度器对Pod资源的准确判断交换延迟可能导致应用超时在SSD上频繁交换可能影响磁盘寿命但完全禁用swap就像开车不系安全带——在平稳运行时毫无问题一旦出现意外就可能造成严重后果。我们的新策略是为关键业务Pod设置requestslimits禁用swap对弹性服务适当放宽限制允许有限度的交换在节点级保留基础swap作为最后防线
技术解析：从Transformer架构到实战应用)
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
