在处理高并发或计算密集型任务时，服务器内存资源经常处于满负荷状态。当系统可用内存耗尽，Linux 内核会触发 OOM (Out Of Memory) Killer 机制，以牺牲部分进程为代价来保障内核及系统的基本运行。对于运维和后端开发人员而言，OOM Killer 的介入往往意味着服务的中断。了解并干预这一机制，是保障核心业务稳定性的关键。
内核在决定“击杀”哪个进程时，会通过一个名为 oombadness 的函数为每个进程计算得分。这个分数记录在 /proc/<pid>/oomscore 中，分数越高，被 OOM Killer 选中的概率就越大。计算依据主要包括进程当前消耗的常驻内存（RSS）、页表、以及交换空间使用量。特权进程由于自带一定豁免权，得分相对较低。
开发人员无需被动接受内核的裁决。Linux 提供了 oomscoreadj 参数（有效范围 -1000 到 1000）来允许我们手动调整进程的 OOM 倾向。将其设置为 -1000，进程将完全免疫 OOM Killer（除非绝对必要），而设置正值则会增加其被优先终止的几率。
在实际工程中，数据库服务或核心网关通常需要最高的存活优先级。通过修改 Systemd 服务文件，可以方便地注入调整策略：
“`ini
[Service]
OOMScoreAdjust=-500
“`
配置生效后，即便系统遭遇内存危机，这些核心组件也能获得更大的生存空间。相对地，一些后台批处理脚本、数据同步任务或是临时分析工具，则可以配置正向的 OOMScoreAdjust。当内存吃紧时，系统会优先牺牲这些可以重试且不影响主链路的非关键任务。
橙星云技术团队在构建高可用架构时，便大量运用了这种优先级隔离策略。在承载大规模测评数据分析任务时，我们会将临时计算节点的 OOM 分数调高，而将核心的测评状态机服务分数调低。这种精细化的水位控制，使得偶发的大量突发请求不会波及到基础链路。
日常监控中，捕捉 OOM 现场同样重要。内核态的 OOM 事件会记录在系统日志中。通过在日志收集系统中配置关键字过滤（如 grep -i "Out of memory" /var/log/messages 或 dmesg | grep -i oom-killer），工程师能够快速还原事发时间、触发节点以及具体的内存消耗快照。在确认核心服务受到保护的同时，分析被杀进程的内存占用趋势，才能从根源上优化应用的资源使用。