Linux内存碎片化导致大块连续内存分配失败，核心是外部碎片而非总量不足，需通过/proc/buddyinfo监控、内核compact机制、大页配置、jemalloc及应用层池化协同治理。
Linux内存碎片化严重时，系统仍可能显示“内存充足”，但大块连续物理内存无法分配，导致OOM、DMA失败或THP降级。问题核心不在总量不足，而在空闲页分布零散——尤其是外部碎片。解决需分层干预：内核机制、运行时配置、应用习惯三者协同。
看懂碎片现状：用/proc/buddyinfo定位瓶颈
执行 cat /proc/buddyinfo 查看各阶空闲页数量（单位为页，每页4KB）。例如：
Node 0, zone DMA 1 0 1 0 2 1 0 0 0 0 0
对应 2⁰=1页、2¹=2页……2¹⁰=1024页（约4MB）的空闲块数。若高阶（如 order-8 以上）长期为0，而低阶（order-0~3）数值很高，说明外部碎片已较严重。
补充观察：cat /proc/slabinfo 可查内核对象缓存使用情况；grep -i "page\|frag" /proc/vmstat 中 pgmajfault 或 pgalloc 异常升高也可能是碎片诱发的分配延迟。
内核级主动整理：开启compact + 调整水位线
Linux 2.6.32+ 内置内存规整（compaction），但默认不自动触发。需手动启用并优化触发条件：
- 立即整理一次：echo 1 > /proc/sys/vm/compact_memory（适合维护窗口）
- 永久启用自动规整：vm.compaction_proactiveness=10（推荐值5–20），写入 /etc/sysctl.conf
- 调高最小空闲水位：vm.min_free_kbytes 设为总内存的1.5%～2.5%，避免过早触发OOM前的激进回收
- 降低 swappiness 至 10 左右，减少因换出导致的页迁移失序，间接利于碎片控制
绕过碎片：用大页与高效分配器替代默认行为
对需要连续物理内存的场景（如数据库、DPDK、GPU驱动），优先规避碎片而非清理：
- 启用透明大页（THP）：echo always > /sys/kernel/mm/transparent_hugepage/enabled，并禁用动态defrag（echo never > /sys/kernel/mm/transparent_hugepage/defrag）以稳定分配
- 预分配标准大页：echo 512 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages（按需调整）
- 用户态程序接入 jemalloc：LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libjemalloc.so.2 启动，它通过分代缓存和arena隔离显著降低小对象碎片
应用层加固：池化 + 避免高频小分配
内核无法替你管理业务逻辑中的碎片。关键在设计阶段规避：
- 对固定结构（如连接对象、消息头）实现内存池（object pool），启动时预分配一批，复用而非反复malloc/free
- 避免在循环中频繁申请释放小内存（如每次处理一个字节的buffer）；改用栈分配、静态缓冲区或批量处理
- C/C++ 程序定期调用 malloc_trim(0) 尝试归还顶部空闲内存给内核（注意：仅对sbrk系有效，mmap分配不受影响）
- Java/Go 等语言依赖GC，但应避免短生命周期大对象，防止晋升到老年代后加剧压缩压力
不复杂但容易忽略：碎片治理不是单点开关，而是从监控（buddyinfo）、内核策略（compact + watermarks）、运行时选择（THP/jemalloc）到代码习惯（池化）的连贯动作。日常运维中，定期在低峰期 echo 1 > /proc/sys/vm/compact_memory 并结合 drop_caches 清理缓存，已能覆盖多数中等负载场景。
