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

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

为什么 MySQL 总是首当其冲？

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

# 常见的保护设置
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.conf
vm.overcommit_memory = 2
vm.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 进程加入 cgroup
cgclassify -g memory:mysql $(pgrep mysqld)

或者 systemd 服务文件配置：

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

5. 监控和预警系统

— 监控 MySQL 内存使用
SELECT * FROM sys.memory_global_by_current_bytes
WHERE event_name NOT LIKE 'memory/performance_schema%'
LIMIT 10;

— 查看连接内存使用
SELECT * FROM sys.memory_by_thread_by_current_bytes
LIMIT 10;

# 监控系统内存趋势
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，通常建议关闭透明大页
echo never > /sys/kernel/mm/transparent_hugepage/enabled

当 OOM 不可避免时

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

1. OOM 后自动恢复

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

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

# 如果有监控或其他辅助进程，降低其优先级
for pid in $(pgrep monitoring-agent); do
echo 1000 > /proc/$pid/oom_score_adj
done

3. 使用内核压力 stall 信息

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

总结

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

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

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