最稳妥见效快的组合方案是直接加swap并限制备份进程内存使用：先用dd创建2gb swapfile并启用，再用ulimit或systemd限制备份命令内存上限，辅以oom_score_adj调优。
直接加 swap + 限制备份进程内存使用，是最稳妥、见效最快的组合方案。大数据备份本身是短时高内存消耗行为，不是持续泄漏，没必要大改架构或重写工具。
先快速止血：立即启用 swap 缓冲
云服务器（如阿里云、腾讯云）默认常不配 swap，而大数据备份（如 mysqldump 全库、pg_dump 大表、rsync --delete 同步海量小文件）会瞬间申请大量页缓存和匿名内存，一旦 free -h 显示 MemAvailable 接近 0 且 Swap=0，OOM Killer 几乎必然触发。
执行以下命令临时启用 2GB swap（适合 4–8GB 内存的服务器）：
- sudo dd if=/dev/zero of=/swapfile bs=1G count=2
- sudo chmod 600 /swapfile
- sudo mkswap /swapfile
- sudo swapon /swapfile
验证：运行 free -h，确认 Swap 行出现数值（如 2.0G）。这能显著延缓 OOM 触发时机，给内核留出回收 page cache 的时间窗口。
控制备份进程内存上限，避免“吃光”系统
备份工具本身不设内存限制（如 mysqldump 默认全表加载、tar 配合 gzip 可能缓冲暴涨），需从运行层强制约束：
- 对单个备份命令，用 ulimit -v 限制其虚拟内存总量（单位 KB）：
ulimit -v 1572864; mysqldump -u root db_name > backup.sql（即限制为 1.5GB） - 若用 systemd 启动备份服务，添加内存限制：
在 service 文件中加入：
MemoryMax=1.5G
MemorySwapMax=1.5G - 对 rsync 等工具，加 --max-size=100M 或分批处理，避免单次读取超大文件导致 anon-rss 突增
调低该进程被杀优先级（辅助手段）
即使做了以上两步，若备份进程仍被选中（例如日志显示 Killed process 12345 (mysqldump)），可临时降低其 OOM 权重，让内核更倾向杀其他非关键进程：
- 启动备份前，获取其 PID 并设置：
echo -500 | sudo tee /proc/$(pidof mysqldump)/oom_score_adj - 注意：-1000 表示免疫，但不建议设到 -1000（可能影响系统稳定性）；-500 是安全且有效的折中值
- 也可在启动脚本中统一设置：
echo -300 > /proc/self/oom_score_adj && exec mysqldump ...
检查并微调内核内存水位（进阶）
如果服务器长期跑备份任务，且总内存 ≥16GB，可适当下调 vm.min_free_kbytes，避免因保守水位过早触发 OOM：
- 查当前值：cat /proc/sys/vm/min_free_kbytes
- 合理值 ≈ 总内存的 0.5%–1%（如 32GB 内存，设为 196608 ~ 327680）
- 临时调整：sudo sysctl vm.min_free_kbytes=262144
- 永久生效：写入 /etc/sysctl.conf 并运行 sudo sysctl -p
⚠️ 不要盲目设高（如 1GB+），否则会大幅压缩可用内存空间，反而加剧问题。
