Linux 针对 MySQL 专用服务器的 OOM 预防策略配置-开发者社区

对于只运行 MySQL 的服务器，如果触发 OOM，无论怎样设置，数据库进程被杀死几乎是必然的。这是因为：

为什么 MySQL 总是首当其冲？

内存占用最大
在专用 MySQL 服务器上，MySQL 通常占用 80-99% 的物理内存（包括 InnoDB Buffer Pool、Key Buffer 等），其他进程（SSH、监控等）内存使用微不足道。
OOM Killer 的计算逻辑
OOM Killer 基于oom_score选择目标，主要考虑因素包括：
- 内存使用量（RSS）：MySQL 通常最高
- 进程运行时间：虽然长时间运行的进程有保护，但抵不过内存使用量的权重
- 特权级：即使 MySQL 以 root 运行，保护作用有限
过度分配导致的"完美风暴"
MySQL 可能同时面临：
- 自身 Buffer Pool 占用大量内存
- 大量连接和临时表
- 操作系统文件缓存也占用内存
- Swap 空间不足或访问过慢

即使设置了保护也可能失效

# 常见的保护设置echo-1000>/proc/$(pgrep mysqld)/oom_score_adj

这种方法在混合负载服务器上有效，但在专用 MySQL 服务器上：

当系统内存耗尽时，必须杀死某个进程
其他进程太小，杀死它们释放的内存杯水车薪
内核会"聪明地"忽略 oom_score_adj，选择能释放大量内存的进程
MySQL 成为唯一有效目标

针对专用 MySQL 服务器的 OOM 预防策略

1.禁用 Overcommit（最关键的设置）

# /etc/sysctl.conf 或 /etc/sysctl.d/99-mysql.confvm.overcommit_memory=2vm.overcommit_ratio=95

计算CommitLimit= 物理内存 ×overcommit_ratio/100+ Swap

当申请内存超过此限制时，malloc()直接返回失败
MySQL 会收到ENOMEM错误，而不是突然被杀死

重要：需要配置 MySQL 正确处理内存分配失败。

2.合理配置 MySQL 内存使用

# my.cnf 关键配置 [mysqld] # InnoDB Buffer Pool - 不要超过物理内存的 70-80% innodb_buffer_pool_size = 物理内存的 70% # 限制全局和每个连接的内存使用 max_connections = 合理值（如 200） # 每个连接的内存限制 tmp_table_size = 32M max_heap_table_size = 32M join_buffer_size = 合理值 sort_buffer_size = 合理值 read_buffer_size = 合理值 read_rnd_buffer_size = 合理值 # 监控和限制 performance_schema = ON

3.配置 Swap 但避免过度使用

# 有一定 Swap 但不依赖它# 建议：物理内存的 25%-50%，但使用 SSD 交换分区vm.swappiness=10# 较低值，减少主动交换vm.vfs_cache_pressure=100

4.使用 cgroups 硬性限制（推荐）

# 创建 cgroup 限制 MySQL 总内存使用cgcreate -g memory:mysql# 设置内存限制为物理内存的 85%cgset -r memory.limit_in_bytes=85%物理内存 mysql cgset -r memory.memsw.limit_in_bytes=物理内存+适当Swap mysql# 将 MySQL 进程加入 cgroupcgclassify -g memory:mysql$(pgrep mysqld)

或者 systemd 服务文件配置：

[Service] MemoryMax=85% # 硬限制 MemorySwapMax=10% # 限制 Swap 使用 MemoryHigh=80% # 软限制，超过时开始回收

5.监控和预警系统

-- 监控 MySQL 内存使用SELECT*FROMsys.memory_global_by_current_bytesWHEREevent_nameNOTLIKE'memory/performance_schema%'LIMIT10;-- 查看连接内存使用SELECT*FROMsys.memory_by_thread_by_current_bytesLIMIT10;

# 监控系统内存趋势cat>/usr/local/bin/memwatch.sh<<'EOF' #!/bin/bash COMMITTED=$(grep Committed_AS /proc/meminfo | awk '{print $2}') LIMIT=$(grep CommitLimit /proc/meminfo | awk '{print $2}') PERCENT=$((COMMITTED*100/LIMIT)) echo "内存承诺使用率: ${PERCENT}%" if [ $PERCENT -gt 90 ]; then echo "警告: 内存接近过度分配极限!" # 触发警报 fi EOF

6.配置 MySQL 内存分配失败处理

# my.cnf [mysqld] # 使 MySQL 在内存不足时优雅降级 innodb_use_sys_malloc = 0 # 使用自己的内存分配器 # 定期检查内存使用 performance_schema_max_memory_classes = 320

7.硬件和内核调优

# 增加内存过量使用时的响应性vm.oom_dump_tasks=1# OOM时记录进程信息vm.panic_on_oom=0# 不要panic，让OOM killer工作vm.oom_kill_allocating_task=0# 使用透明大页可能增加内存压力风险# 对于MySQL，通常建议关闭透明大页echonever>/sys/kernel/mm/transparent_hugepage/enabled

当 OOM 不可避免时

如果即使采取上述措施仍然可能触发 OOM，配置应急措施：

1.OOM 后自动恢复

# 在 /etc/systemd/system/mysql.service.d/oom-recovery.conf[Service]Restart=on-failureRestartSec=10OOMScoreAdjust=-1000

2.配置优先杀死辅助进程

# 如果有监控或其他辅助进程，降低其优先级forpidin$(pgrep monitoring-agent);doecho1000>/proc/$pid/oom_score_adjdone

3.使用内核压力 stall 信息

# 监控内存压力早期预警echo10000>/proc/sys/vm/watermark_scale_factor

总结

对于专用 MySQL 服务器，防御 OOM 的关键顺序：

首要：禁用 overcommit (vm.overcommit_memory=2)
其次：合理配置 MySQL 内存参数，留足系统开销
再次：使用 cgroups 硬限制 MySQL 总内存
然后：配置适当的监控和预警
最后：准备 OOM 发生后的恢复方案

最根本的解决方案：确保物理内存足够，并有适当的余量（通常建议 MySQL 专用服务器上，InnoDB Buffer Pool 不超过物理内存的 75%）。

这样配置后，即使内存不足，MySQL 会收到分配失败错误（可通过应用程序处理），而不是被突然杀死导致数据损坏或复制中断。

Linux 针对 MySQL 专用服务器的 OOM 预防策略配置