systemd-oomd 默认不基于进程RSS，而是依据cgroup内存压力（memory.pressure）和使用趋势触发，仅作用于启用MemoryAccounting=yes的服务或scope单元；需确认进程在受管cgroup下、配置正确、压力达阈值且排除误杀。
systemd-oomd 默认行为偏保守，规则不生效或误杀进程，通常不是 bug，而是配置未对齐其设计逻辑——它不直接看进程内存占用，而是基于 cgroup 层级的内存压力（memory.pressure）和内存使用趋势（如 memory.current 增速），且只作用于启用了 MemoryAccounting=yes 的 scope 或 service 单元。
确认目标进程是否在受管 cgroup 下
systemd-oomd 只管理由 systemd 创建并启用内存统计的 cgroup，普通 fork 出的进程（如手动 bash 启动的程序、容器未配 memory controller）默认不受控。
- 检查进程所在 cgroup：运行
cat /proc/<pid>/cgroup | grep memory</pid>，确认路径形如/sys/fs/cgroup/memory/system.slice/myapp.service，而非/或/user.slice/...（user session 默认不启用 MemoryAccounting） - 确保服务单元启用内存统计：在
.service文件中显式设置MemoryAccounting=yes，并重载配置：systemctl daemon-reload && systemctl restart myapp.service - 对临时进程，可用
systemd-run --scope -p MemoryAccounting=yes --scope your-command手动纳入管控
理解 oomd 的触发条件不是“内存满”，而是“持续高压”
systemd-oomd 不基于绝对内存值（如 RSS > 80%），而是依赖内核提供的 memory.pressure（平均 10 秒/60 秒/300 秒的压力值）与 memory.current 趋势。若压力值未达阈值（默认 medium=5%, critical=10% 持续 10s），即使内存已近耗尽也不会触发。
审查 Remix v2 代码中的 v1 形态 meta 导出（v2 中为破坏性变更），cookie 安全漏洞（httpOnly、secure、密钥轮换），认证门位于错误层级，以及其他
- 查看实时压力：读取
/sys/fs/cgroup/<path>/memory.pressure</path>，例如some=0.5 avg10=0.2 avg60=0.1 avg300=0.05，只有avg10连续超阈值才可能触发 - oomd 日志在
journalctl -u systemd-oomd -f中，关注Pressure is high和Deciding to kill行，而非只看 “killed” 结果 - 避免误判：短时 spike（如 GC、批量加载）可能不触发；而长稳态中等压力（如 avg10=7% 持续 20s）反而更易被选中
防止误杀关键进程：用 oomd.conf 精细控制优先级
oomd 默认按 cgroup 内存占比 + 启动时间加权打分，但可通过 /etc/systemd/oomd.conf 或 per-cgroup 配置文件干预。常见误杀源于未排除系统关键服务或高内存但低压力的服务（如缓存进程）。
- 全局降低敏感度：在
[OOMDaemon]下设SwapUsedLimit=90%、MemoryAvailableLimit=10%（单位为内存总量百分比），避免过早介入 - 为特定 service 降权：在
/etc/systemd/system/myapp.service.d/oomd.conf中添加：
[Service]
OOMScoreAdjust=-500
（注意：这是 systemd 的 OOMScoreAdjust，影响 oomd 打分权重，值越低越不易被杀；-1000 完全豁免，但需谨慎） - 完全屏蔽某 cgroup：创建
/etc/systemd/oomd.conf.d/90-ignore-db.conf，内容为：
[Manager]
IgnoreCGroupPaths=/system.slice/postgresql.service
验证与调试：别只信 top，要看 cgroup 视图
top、htop 显示的是进程 RSS，而 oomd 看的是 cgroup memory.current（含 page cache、swap cache 等）。同一进程在不同 cgroup 下表现可能差异巨大。
- 对比数据：运行
systemctl status myapp.service查看 “Memory:” 行，再手动读取cat /sys/fs/cgroup/system.slice/myapp.service/memory.current，两者应基本一致 - 模拟压力测试：用
stress-ng --vm 2 --vm-bytes 1G --timeout 60s在指定 scope 下运行，配合watch -n1 'cat /sys/fs/cgroup/*/memory.pressure'观察响应 - 禁用 swap 干扰：若系统启用了 swap，oomd 可能延迟触发（因 memory.available 包含 swap 剩余），测试时可临时
swapoff -a排查
