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)” 只是结果，不是原因。真正拖垮系统的，往往是以下三类“隐形耗子”：

Toingg Ops Toolkit

一款AI音频处理工具，主要用于通过向 `toingg/make_campaign` API 发送 POST 请求，提交用户提供的 JSON 数据，创建并启动 Toingg 语音呼叫活动，适用于 Codex 将活动简报……，适合需要提升相关任务效率的用户。

下载

• 匿名页（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 稳定可控