OOM Killer 的评判算法为何总是杀错进程？从启发式评分到生产环境的生存指南
凌晨三点，线上告警。你打开监控面板，发现主数据库进程消失了，而那个只占用几兆内存的后台日志收集进程却安然无恙。dmesg 的输出冷酷而简洁： Out of memory: Kill process 18472 (postgres) score 891 or sacrifice child 这不是电影情节，而是无数运维工程师的真实经历。Linux 内核的 OOM Killer 本应是系统安全的最后一道防线，但它那套基于启发式评分的选杀机制，在过去二十多年里"误杀"了无数关键进程。问题来了：这套机制到底是怎么工作的？为什么数据库进程总是第一个被选中？又该如何让关键服务在内存危机中存活下来？ ...