2GB内存下MySQL和Redis如何合理分配内存避免OOM？

在仅 2GB 总内存 的受限环境中（如小型云服务器、树莓派或开发测试机），同时运行 MySQL 和 Redis 极易触发 OOM（Out of Memory）——尤其当两者默认配置未调优时。以下是务实、可落地的内存分配与调优策略，目标是：稳定运行 + 避免 swap/OOM + 保障基础可用性。

✅ 一、总体内存分配建议（总 2GB = 2048MB）

✅ 推荐初始分配：

• MySQL：900MB
• Redis：600MB
• OS + 缓冲：548MB（2048 − 900 − 600）

⚠️ 注意：绝不硬性划分物理内存（Linux 不支持），而是通过服务配置严格限制其最大内存使用上限，并配合系统级防护。

✅ 二、MySQL 调优（关键：禁用大内存参数）

编辑 my.cnf（通常 /etc/mysql/my.cnf 或 /etc/my.cnf），重点限制以下参数：

[mysqld]
# —— 内存相关 ——
innodb_buffer_pool_size = 600M      # ⚠️ 最大内存占用项！设为 600–700M（占 MySQL 分配的 ~70%）
key_buffer_size = 16M               # MyISAM（若不用，可设 8M）
sort_buffer_size = 256K              # 每连接临时排序内存（勿超 512K）
read_buffer_size = 128K
read_rnd_buffer_size = 256K
join_buffer_size = 256K
tmp_table_size = 32M                # 内存临时表上限（防大 GROUP BY）
max_heap_table_size = 32M
table_open_cache = 200              # 减少句柄开销
open_files_limit = 1024

# —— 连接与并发 ——
max_connections = 32                # ⚠️ 降低并发数（每连接至少额外 1–2MB 内存）
wait_timeout = 60
interactive_timeout = 120

# —— 其他安全项 ——
innodb_log_file_size = 64M          # 日志文件不宜过大（影响恢复）
innodb_flush_method = O_DIRECT      # 避免 double-buffering（Linux 推荐）
skip-log-bin                        # 关闭 binlog（开发/非主从场景）

🔍 验证命令（重启后执行）：

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW VARIABLES LIKE 'max_connections';
SELECT @@key_buffer_size, @@tmp_table_size;

✅ 预期总内存占用 ≈ buffer_pool + (max_connections × sort_buffer) < 900MB

✅ 三、Redis 调优（关键：启用驱逐 + 禁用持久化开销）

编辑 redis.conf，核心配置：

# —— 内存限制 ——
maxmemory 512mb                     # ⚠️ 强制硬上限！必须设置（单位：mb, mb, gb）
maxmemory-policy allkeys-lru        # 或 volatile-lru（推荐 allkeys-lru，简单可靠）

# —— 持久化（2GB 环境强烈建议关闭或简化）——
save ""                             # ❌ 禁用 RDB 自动快照（避免 fork 大内存进程）
# save 900 1
# save 300 10
# save 60 10000

stop-writes-on-bgsave-error no      # 即使 RDB 失败也不阻塞写入（但建议关 RDB）
rdbcompression no                   # 若必须 RDB，关闭压缩省 CPU/内存
rdbchecksum no

# —— AOF（更耗内存/IO，生产慎用）——
appendonly no                       # ✅ 默认关闭 AOF（最省内存）
# appendfilename "appendonly.aof"
# appendfsync everysec

# —— 其他 ——
tcp-keepalive 300
timeout 300
maxclients 128                      # 合理连接数（每个连接约 10KB）
hz 10                               # 降低定时任务频率（省 CPU）

💡 为什么禁用 RDB/AOF？

• fork() 创建子进程时，Linux 使用 COW（Copy-on-Write），但若 Redis 数据接近 512MB，fork 可能瞬间申请近 1GB 虚拟内存，触发 OOM Killer 杀死进程。
• 开发/缓存场景下，数据丢失可接受，可靠性让位于稳定性。

✅ 启动后检查：

redis-cli info memory | grep -E "(used_memory|maxmemory|mem_fragmentation_ratio)"
# used_memory < maxmemory * 0.95 且 mem_fragmentation_ratio < 1.5 → 健康

✅ 四、系统级防护（防 OOM Killer 误杀）

1. 设置 OOM Score 调整（让 MySQL/Redis 更“抗杀”）

# 查看当前 OOM 分数（越小越不易被 kill）
cat /proc/$(pgrep mysqld)/oom_score_adj   # 通常 0
cat /proc/$(pgrep redis-server)/oom_score_adj

# 降低被 kill 概率（范围 -1000 到 +1000，-1000=永不 kill）
echo -500 | sudo tee /proc/$(pgrep mysqld)/oom_score_adj
echo -500 | sudo tee /proc/$(pgrep redis-server)/oom_score_adj

2. 启用 vm.swappiness=1（减少 swap 依赖，避免卡顿）

echo 'vm.swappiness=1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

3. 监控告警（必备！）

# 安装 htop / glances（实时看内存）
sudo apt install htop glances  # Ubuntu/Debian

# 检查 OOM 日志
dmesg -T | grep -i "killed process"

# 简单脚本监控（加入 cron 每5分钟）
free -h | awk '/^Mem:/ {print "Used:", $3 "/" $2, "("$3*100/$2"%)"}'
redis-cli info memory | awk -F: '/used_memory:/ {gsub(/[^0-9.]/,"",$2); print "Redis Used:", $2/1024/1024 "MB"}'
mysql -e "SHOW STATUS LIKE 'Threads_connected';" | tail -1 | awk '{print "MySQL Conn:", $2}'

✅ 五、进阶建议（按需启用）

❌ 绝对禁止的操作

• ✖️ 不设 maxmemory（Redis 无上限 → 必 OOM）
• ✖️ innodb_buffer_pool_size > 700M（2GB 下极易吃光内存）
• ✖️ 同时开启 RDB + AOF（双重 fork + 日志写入 → 内存/IO 雪崩）
• ✖️ max_connections > 64（连接数翻倍，内存线性增长）
• ✖️ 忽略 swappiness 和 oom_score_adj（OOM Killer 是沉默杀手）

✅ 总结：一句话口诀

“MySQL 控 Buffer Pool，Redis 设 maxmemory，OS 留足 400M，RDB/AOF 全关掉，OOM 分数调负值，监控告警不能少。”

如需，我可为你生成：

• ✅ 完整 my.cnf 和 redis.conf 配置文件（适配 2GB）
• ✅ 一键检测内存健康度的 Bash 脚本
• ✅ Docker Compose 示例（带内存限制）

欢迎继续提问！ 🌟