对于 CloudCone 这类内存有限的 VPS，调整 OOM killer 优先级只能暂时保护关键进程，根本解决需要增加 Swap 或升级配置。
先说结论：调整 OOM 分数是应急手段，长期稳定需结合 Swap 与服务优化
- 先确认：查看 dmesg 日志确认是否触发 OOM
- 先处理：调整关键进程 oom_score_adj 或添加 Swap
- 再验证：监控内存使用与系统日志不再出现杀进程记录
命令速用版
# 查看是否有 OOM 记录
dmesg | grep -i "out of memory"# 查看进程 OOM 分数（以 nginx 为例）
cat /proc/$(pidof nginx)/oom_score_adj# 临时降低进程被杀概率（设为 -500）
echo -500 > /proc/$(pidof nginx)/oom_score_adj# 添加 1G Swap 文件
dd if=/dev/zero of=/swapfile bs=1M count=1024
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile为什么会这样
Linux 内核在物理内存不足且无法回收页面时，会触发 OOM Killer 机制。它会计算每个进程的 oom_score，分数越高越容易被杀。默认情况下，占用内存多或运行时间短的进程分数较高。VPS 因物理内存固定，一旦应用内存泄漏或突发流量高峰，容易触及内核保护线，导致数据库或 Web 服务被强制终止。
分步处理
1. 确认杀进程原因
登录 SSH，执行 dmesg -T | grep -i "killed process"。如果看到类似"Out of memory: Kill process"字样，说明是内存不足触发。若没有此类日志，可能是服务自身崩溃，需检查应用日志。
2. 保护关键进程
找到需要保护的进程 PID，例如 MySQL。执行 echo -500 > /proc/
3. 增加 Swap 空间
如果磁盘空间充足，可创建 Swap 文件作为缓冲。注意 Swap 读写速度远低于内存，仅用于防止进程被杀，不可视为性能提升方案。执行速用版中的 Swap 创建命令，并将 swapon 写入 /etc/fstab 实现开机挂载。
4. 固化配置（可选）
Proc 文件系统中的设置重启失效。若需永久生效，可通过 systemd 服务单元文件配置 MemoryLimit，或编写启动脚本在应用启动时调整 oom_score_adj。
怎么验证是否生效
调整后持续观察内存状态。使用 free -h 确认 Swap 是否激活。运行压力测试或等待业务高峰，再次执行 dmesg | grep -i "oom"。若不再出现杀进程记录，且系统未死机，说明调整有效。同时使用 top 命令观察内存使用率，确认没有异常泄漏。
常见坑
1. 不要将所有进程 oom_score_adj 设为 -1000。如果所有进程都不可杀，内存耗尽时内核将无法释放资源，导致系统完全无响应，只能硬重启。
2. Swap 不是万能药。频繁使用 Swap 会导致磁盘 I/O 飙升，拖慢整体响应速度，仅作为防崩溃底线。
3. 注意容器环境。如果在 Docker 或 LXC 中，宿主机与容器内的 OOM 策略可能冲突，需在宿主机层面调整或限制容器内存上限。
4. 公开资料中没有看到可靠的量化数据表明调整 OOM 分数能提升性能，这仅是稳定性策略。
参考来源
- Linux Kernel Documentation - OOM Killer, https://www.kernel.org/doc/html/latest/admin-guide/mm/oom.html
- proc(5) - Linux man page, https://www.man7.org/linux/man-pages/man5/proc.5.html
原文链接：https://www.zjcp.cc/ask/10199.html