频繁触发oom killer说明swap未被精准使用，关键在通过调低vm.swappiness（如设为1）、合理配置oom_score_adj（如核心进程设-500）及监控pswpout等指标，使swap成为可控的最后防线而非日常调剂。
当系统频繁触发 OOM Killer，说明物理内存与 Swap 的协同已濒临失效——不是 Swap 开得不够大，而是它没被用在刀刃上。关键不在于“多换”，而在于“换得准、换得少、换得可控”。精准调优 Swap 边界，本质是控制内核何时开始换出、换什么、换多少，从而为核心服务争取缓冲时间，避免被误杀。
明确 Swap 的真实边界：别把 Swap 当内存补丁
Swap 不是内存扩容，而是内存压力的“泄压阀”。它的有效边界由三者共同定义：
- 物理内存总量：决定基础承载力；
- vm.swappiness 值：控制内核换出匿名页的激进程度（0～100）；
- 可用 Swap 容量 + I/O 能力：SSD 上 2GB Swap 比 HDD 上 8GB 更有效。
例如，一台 8GB 内存的 Redis 服务器，若 swappiness=60 且 Swap 设为 4GB，内核可能在内存仅剩 1.5GB 时就大量换出 Redis 的匿名页（如 AOF rewrite 缓冲），导致延迟飙升、触发 fork 失败，最终仍走向 OOM。此时降低 swappiness 到 1，并非“禁用 Swap”，而是让 Swap 只在真正濒临崩溃（如剩余内存＜512MB）时才介入。
用 swappiness 锁定换出时机，保护关键进程内存热区
swappiness 不是开关，而是调节器。对核心服务（如数据库、消息队列主进程），应主动收窄 Swap 触发窗口：
- 设 vm.swappiness=1：内核几乎只回收 page cache，保留匿名页（堆、栈）在 RAM 中；
- 配合 vm.vfs_cache_pressure=50：减缓 dentry/inode 缓存回收，避免因缓存抖动引发连锁内存申请；
- 禁止 overcommit（
vm.overcommit_memory=2）+ 设置 vm.overcommit_ratio=80：确保总虚拟内存（RAM + Swap）有硬上限，防止 optimistic allocation 过度透支。
这样配置后，Swap 不再是“日常调剂”，而成为真正的最后防线——只有当所有可回收缓存耗尽、且匿名内存持续增长逼近物理极限时，才会启用，大幅降低误伤概率。
用 oom_score_adj 把核心进程“移出 Swap 影响圈”
Swap 换出行为本身不直接决定谁被杀，但它抬高了进程的 RSS+Swap 综合占用，间接推高其 badness 分数。因此，必须双管齐下：
- 对 Redis、PostgreSQL 主进程等，设 oom_score_adj = -500：显著压低其 OOM 优先级，即使它占用了较多内存，评分也远低于普通进程；
- 对短时高内存任务（如日志压缩、备份脚本），设 oom_score_adj = +300：主动将其列为“可牺牲对象”，避免它们拖累全局；
- 通过 systemd 服务文件固化（如
OOMScoreAdjust=-500），确保重启后策略不丢失。
注意：这不能替代内存治理。若 Redis 自身内存泄漏，-500 也挡不住最终 OOM——它只是争取时间给你定位问题。
监控 Swap 活动与 OOM 关联性，识别真瓶颈
频繁 OOM 往往伴随 Swap 活动异常，但二者未必因果。需交叉验证：
- 查
cat /proc/vmstat | grep -E "pgpgin|pgpgout|pswpin|pswpout"：若pswpout持续每秒数百次，说明 Swap 正高频写入，I/O 成瓶颈； - 用
pidstat -r -w 1观察进程 RSS 与 %mem，再结合awk '/^Swap:/ {print $2}' /proc/[pid]/smaps看实际 Swap 占用； - 比对
dmesg -T | grep "Killed process"时间戳与free -h历史快照（如 via sar -r），确认 OOM 是否发生在 Swap 耗尽前（说明 Swap 未起作用）或紧随其后（说明 Swap 已撑到极限）。
若发现 Swap 使用率长期＞90% 且 pswpout 暴涨，说明边界已失守——此时扩容 Swap 文件只是延缓死亡，必须回归应用层：限制 Redis maxmemory、调小 JVM 堆、关闭容器内存无限制等。
