设置sshd的oom_adj为-17/-15防OOM Killer查杀是否合理？有何风险？

可行性判断 #

这个方案在短期应急场景下是可行的：

• oom_adj的数值越低（负数绝对值越大），OOM Killer选中该进程的概率就越低。设置为-17时，对应现代内核的oom_score_adj=-1000，意味着sshd会被完全豁免OOM Killer；设置为-15则对应oom_score_adj≈-900，能大幅降低被终止的概率。这两种设置都能达成你的核心诉求——内存泄漏导致系统内存耗尽时，仍能通过SSH连接服务器排查问题。
• 操作成本低：临时生效可以执行echo -17 > /proc/$(pidof sshd)/oom_adj；永久生效可在sshd的systemd服务文件（如/usr/lib/systemd/system/sshd.service）中添加ExecStartPre=/bin/sh -c 'echo -17 > /proc/$(pidof sshd)/oom_adj'，或在启动脚本中加入对应命令。

潜在风险 #

1. 系统兜底机制失效 #

• 若设置为-17（完全豁免），当系统内存被Ceph组件（OSD、MON等）耗尽时，OOM Killer无法终止sshd，只能选择杀死其他进程，甚至可能因找不到可终止的进程导致系统直接挂起、无响应，连本地控制台都无法操作。
• 即使设置为-15，sshd的OOM优先级远低于Ceph核心进程，OOM Killer会优先终止Ceph服务，引发集群故障、数据可用性下降，损失可能比无法SSH连接更大。

2. 掩盖内存泄漏根源问题 #

调整oom_adj只是解决了“无法SSH排查”的表象，没有修复Ceph内存泄漏的根本原因。内存泄漏会持续消耗资源，最终还是会导致系统崩溃，只是被牺牲的对象从sshd变成了更关键的业务组件，问题的影响范围反而扩大。

3. 进程优先级失衡风险 #

如果未给Ceph核心组件配置合理的OOM优先级，会加剧上述问题——OOM Killer优先终止Ceph服务而非sshd，直接影响集群稳定性。

4. 内核兼容性问题 #

现代Linux内核已逐步用oom_score_adj替代旧的oom_adj接口，虽然多数系统仍兼容oom_adj，但长期来看该接口可能被废弃，内核升级后设置可能失效。

补充建议 #

• 优先解决内存泄漏：升级Ceph到稳定新版本（多数已知内存泄漏问题已在新版本修复）、调整Ceph组件的内存限制参数（如OSD的osd_memory_target）、排查自定义脚本或第三方插件导致的泄漏。
• 若必须设置OOM优先级，优先选-15而非-17，保留一定弹性，让OOM Killer在极端情况仍有操作空间。
• 给Ceph核心组件（MON、OSD）配置合理的oom_score_adj值（如设置为-500），确保它们的OOM优先级高于非核心进程。
• 配置内存监控告警：通过Prometheus+Grafana等工具监控内存使用率，当达到阈值（如80%）时及时告警，提前介入处理，避免触发OOM。

内容的提问来源于stack exchange，提问作者lyova