Master被OOM Killer杀掉是系统内存濒临崩溃的自保行为，需立即止血、定位真凶（匿名页泄漏/Cache堆积/内核泄漏）、组合防护（cgroup限存+禁用过度分配+调低水位线）并长期免疫。
Master 进程被 OOM Killer 杀掉，不是“服务挂了”，而是系统在内存濒临崩溃时的紧急自保行为。它意味着：内存压力已突破内核安全水位线（vm.min_free_kbytes），且常规回收（page cache、swap）完全失效。恢复不能只重启进程，必须同步止血、溯源、加固——否则几分钟后它还会被杀第二次。
一、立即止血：5分钟内稳住系统
别急着 systemctl start。先确认是否还在“杀戮循环”中：
- 执行 dmesg -T | grep -i "killed process"，看最近1分钟是否有重复记录；有则说明内存仍在持续泄漏或爆发式增长
- 运行 free -h && cat /proc/meminfo | grep -E "(MemAvailable|MinFreeKbytes|SwapFree)"，重点看 MemAvailable 是否持续低于 MinFreeKbytes（如后者设为512MB，前者却只剩200MB）
- 若 Swap 几乎为 0 且未启用，立刻临时启用：swapon --noheadings --show=NAME $(swapon --show=name | head -n1 2>/dev/null || echo "/swapfile")；若无 swap，用 dd if=/dev/zero of=/tmp/swap bs=1G count=2 && mkswap /tmp/swap && swapon /tmp/swap 快速建一个应急 swap（重启即失效，但能抢出排查时间）
二、定位真凶：不是 Master 占内存，是它被连累
OOM 日志里显示 “Killed process XXX (master)” 只是结果，不是原因。真正拖垮系统的，往往是以下三类“隐形耗子”：
- 匿名页（anon-rss）暴涨：查 ps aux --sort=-%mem | head -10，重点关注 RSS 列；再进 /proc/PID/status 看 RssAnon 值。Java/Python 进程 full GC 失败、C++ 程序内存泄漏、Node.js 大对象未释放，都会让 anon-rss 持续冲高
- Page Cache 异常堆积：虽然 cache 可回收，但若大量 dirty page 滞留（cat /proc/vmstat | grep pgpgout 持续为 0）、或写回慢（磁盘 I/O 队列满），cache 就成了“假空闲”。用 vmstat 1 观察 si/so（swap in/out）是否飙升，bi/bo（块设备读写）是否卡死
- 内核内存泄漏：检查 slabtop -o | head -10，关注 dentry、inode_cache、kmalloc-* 是否异常增长；某些驱动或模块 bug 会导致 slab 内存无法释放
三、精准防护：让 Master 进程真正“免死”
仅设 OOMScoreAdjust=-1000 不够——专用服务器上，当其他进程太小、杀完也救不回内存时，内核会绕过 oom_score_adj，直取大进程。必须组合防御：
-
Systemd 服务级防护：在 /etc/systemd/system/master.service 的
[Service]段加入：
OOMScoreAdjust=-1000
MemoryLimit=4G
MemoryMax=4G
MemoryHigh=3.5G
MemoryLow=2G
其中 MemoryHigh 是软限，触发内核主动回收该 cgroup 内存；MemoryMax 是硬限，超限直接 OOM（但只杀本 cgroup 进程，不波及其他） -
禁用内存过度分配：在 /etc/sysctl.d/99-oom.conf 中设：
vm.overcommit_memory=2
vm.overcommit_ratio=80
这样 CommitLimit = 物理内存 × 0.8 + swap，malloc 超限时直接返回 ENOMEM，Master 进程可捕获错误优雅降级，而非等 kernel 来杀 - 调低内核水位线：避免因 vm.min_free_kbytes 设得过高（如误配 1GB+）导致“还有 800MB 就开杀”。合理值 ≈ 总内存的 0.5%~1%，64GB 机器建议设为 524288（512MB）
四、长期免疫：从架构层切断 OOM 链
预防比抢救重要。Master 进程本身应具备反脆弱设计：
- 限制子进程/协程内存：若 Master 启动 worker 进程（如 fork 模型），需在 fork 前用 setrlimit(RLIMIT_AS, ...) 或 cgroup v2 的 memory.max 限制单个 worker，防止单个 worker 泄漏拖垮全局
- 主动监控与熔断：在 Master 内嵌轻量监控逻辑，定期读取 /sys/fs/cgroup/memory/memory.usage_in_bytes 和 /proc/meminfo；当 MemAvailable
- 分离内存敏感组件：将缓存、日志聚合、大文件处理等高内存波动模块拆为独立服务，用 MemoryMax 单独约束；Master 只保留控制面逻辑，内存 footprint 稳定可控
