背景：你以为内存足够，其实都在碎片里

在低配 VPS 上跑 MySQL，最诡异的事莫过于：free -m 显示还有几百 MB 空闲，可 MySQL 却突然被 OOM killer 干掉。翻日志发现是 Out of memory: Killed process 2350 (mysqld)。你用 top 看 RSS 不高，但 /proc/meminfo 里 MemAvailable 比 MemFree 低得多——这就是 内存碎片 在作祟。

glibc 的 malloc 实现（ptmalloc）在高并发、长生命周期服务（典型如 MySQL）中，会因内存池管理不当产生大量碎片。VPS 内存本来就金贵，碎片一多，表面上还有空余，实际上连续大块分配会失败，导致 OOM。

实战中，我用一台 轻云互联 的 4C8G VPS 部署了 MySQL 8.0 生产库，每天凌晨跑报表查询时频繁被 kill，innodb_buffer_pool_size 只设了 4G，按理绰绰有余。后来用 jemalloc 替换默认分配器，内存利用率提升 20%，再也没有莫名 OOM。

Step 1：安装 jemalloc（别装错版本）

不要用系统自带的 libjemalloc-dev（通常太老）。从 GitHub releases 下载最新版，5.3.0+ 对 MySQL 有针对性优化。

# 安装编译依赖
apt install -y autoconf make gcc git
git clone -b 5.3.0 https://github.com/jemalloc/jemalloc.git
cd jemalloc
./autogen.sh
./configure --prefix=/usr/local/jemalloc --enable-prof --enable-stats
make -j$(nproc)
make install
# 确认库文件
ls -l /usr/local/jemalloc/lib/libjemalloc.so

注意：--enable-prof 用于 profiling，方便后续分析内存热点，生产环境可选；--enable-stats 开启统计接口，建议保留。

Step 2：让 MySQL 加载 jemalloc（双保险）

有两种方法：LD_PRELOAD 环境变量，或修改 MySQL 的 systemd 服务。

方法一：直接 LD_PRELOAD（临时测试）

systemctl stop mysql
LD_PRELOAD=/usr/local/jemalloc/lib/libjemalloc.so mysqld --defaults-file=/etc/my.cnf &
# 检查是否生效
cat /proc/$(pidof mysqld)/maps | grep jemalloc
# 应看到类似输出：
# 7f2a00000000   /usr/local/jemalloc/lib/libjemalloc.so

方法二：持久化到 systemd（生产推荐）

mkdir -p /etc/systemd/system/mysqld.service.d
cat > /etc/systemd/system/mysqld.service.d/override.conf << 'EOF'
[Service]
Environment=LD_PRELOAD=/usr/local/jemalloc/lib/libjemalloc.so
Environment=MALLOC_CONF=background_thread:true,prof:true,prof_active:false
EOF
systemctl daemon-reload
systemctl restart mysql
# 验证
systemctl show mysqld | grep Environment

注意 background_thread:true 让 jemalloc 创建独立线程做回收和背景净零，避免 MySQL 的查询线程被阻塞。 prof_active:false 关闭运行时 profiling（降低开销），需要时通过信号动态开启。

Step 3：验证效果——看 RSS 和可用内存

重启 mysql 后，运行几小时观察：

# 对比 /proc/meminfo
grep MemAvailable /proc/meminfo
# 检查 jemalloc 内部统计
MALLOC_CONF=stats_print:true LD_PRELOAD=/usr/local/jemalloc/lib/libjemalloc.so mysqld --defaults-file=/etc/my.cnf &
# 在另一终端发送信号让 mysqld 打印统计
kill -USR2 $(pidof mysqld)
# 日志中会输出类似：
# --- jemalloc statistics ---
# "allocated": 4294967296 (4 GB)
# "active": 4296003584
# "metadata": 8388608
# "resident": 4303355904
# "mapped": 4325376000

理想情况下，allocated 接近主动内存（innodb_buffer_pool等），active 略高，metadata 很小。如果 active 明显大于 allocated，说明仍有碎片，需要调优 jemalloc 参数。

进阶调优：减少“饥饿”大页分配

VPS 通常禁用透明大页（THP），但 jemalloc 默认会尝试 mmap 大页。若系统不支持，增加：

MALLOC_CONF=... ,dss:primary,lg_chunk:21 ...
# lg_chunk:21 表示 2MB 大页，适配 x86_64 默认

更极端的情况：数据库大量临时排序（sort buffer）+ join 操作，易产生碎片。这时调大 tcache_max:2048 让 jemalloc 缓存更多小对象。

风险与避坑

• 不要同时用多个内存分配器：有些 MySQL 插件（如半同步复制）可能默认加载 tcmalloc，导致符号冲突。检查 ldd /usr/sbin/mysqld，若有 libtcmalloc.so，先卸载相关的插件或重新编译 MySQL 静态链接。
• profiling 性能损耗：开启 prof:true 但 prof_active:false 几乎无开销。若需动态开启：kill -USR1 $(pidof mysqld) 激活，dump 后自动关闭。
• 与早期 MySQL 5.6 的兼容性：古早版本可能用 jemalloc 3.x 才保证不崩溃。建议升级到 MySQL 5.7+，官方已推荐 jemalloc。

实测截图（轻云互联 VPS）

在一台 轻云互联 的 4C8G VPS 上，替换前后运行 24 小时的压力测试：

# 使用 sysbench 压测：
sysbench oltp_read_write --table-size=1000000 --threads=32 --time=600 run
# 替换前：内存碎片率约 18%，MemAvailable 经常掉到 200MB
# 替换后：碎片率 <5%，MemAvailable 稳定在 1.2GB 左右
# 查看 jemalloc 统计中的“active”与“allocated”差距从 700MB 缩至 50MB

说白了，消除内存碎片就等于多给了 MySQL 几百 MB 的可用内存，对低配 VPS 是立竿见影的免费升级。

总结

别迷信“加大 innodb_buffer_pool”就是调优，内存碎片才是 VPS 上 MySQL 的隐形杀手。花 10 分钟换 jemalloc，比乱改参数靠谱得多。记住：用 MALLOC_CONF=background_thread:true 保证回收不阻塞，用 cat /proc/pidof mysqld/maps | grep jemalloc 确认生效。

附赠一个“阴间”踩坑：如果用 docker 运行 MySQL，记得把 /usr/local/jemalloc/lib/libjemalloc.so 挂载进容器，并在 Dockerfile 中设置 ENV LD_PRELOAD。否则纯宿主机换了，容器里还是 glibc 的 malloc。