Linux内存管理：swap与oom_score调整

理解swap与OOM：Linux内存不足时发生什么

在Linux系统中，物理内存不仅用于运行进程，还会被大量分配给Page Cache以加速磁盘I/O。当可用内存低于内核水位线时，系统会优先回收Page Cache；若内存压力持续升高，内核会将不活跃的匿名页写入磁盘上的Swap分区或交换文件，从而腾出物理内存。需要明确的是，Swap并不等同于“虚拟内存”，虚拟内存是进程寻址的抽象空间，而Swap仅是物理内存不足时的后备存储介质。当Swap耗尽或系统禁用Swap且内存彻底枯竭时，内核的OOM Killer将被触发。OOM Killer会遍历所有用户态进程，根据进程的内存占用量、运行时间、优先级以及是否拥有特权等维度计算综合得分，最终选择得分最高、对系统影响相对最小的进程强制终止，以保障内核存活。

查看与调整swap：从现状检查到swappiness

检查Swap状态最直观的命令是free -h，它会清晰展示Swap的总量、已用与空闲情况；结合cat /proc/meminfo | grep -i swap可获取更底层的统计信息。若需新增Swap，可使用dd或fallocate创建文件，通过mkswap格式化，并用swapon /path/to/swapfile启用，最后执行swapon --show验证。控制Swap使用频率的核心参数是vm.swappiness（取值0-100）。临时调整执行sysctl vm.swappiness=60，持久化则需在/etc/sysctl.conf中添加对应配置并执行sysctl -p。许多运维人员误以为“Swap越少越好”甚至直接设为0，这会导致内核在内存紧张时过早触发OOM Killer，反而失去Swap提供的缓冲与容错能力。合理设置swappiness能让内核在内存压力下更平滑地过渡，避免服务瞬间雪崩。

调整oom_score_adj：控制OOM时谁更容易被杀

oom_score是内核根据当前内存状态动态计算的原始得分，而oom_score_adj是用户可手动干预的偏移量（范围-1000至1000）。查看某进程评分可执行cat /proc/<pid>/oom_score与cat /proc/<pid>/oom_score_adj。通过echo -500 > /proc/<pid>/oom_score_adj可降低该进程的OOM优先级，使其更难被选中；反之，设为正值会提高其被杀概率。该操作需root权限，且调整仅对当前运行实例生效，进程重启或系统重启后配置将自动重置。在实际生产中，常将数据库或核心网关的oom_score_adj设为负值以保护关键业务，但需注意：若系统内存彻底耗尽，即使设为-1000的进程仍可能被内核强制回收，因此该参数仅用于相对优先级排序，不能作为绝对免死金牌。

验证调整是否生效：监控内存压力与OOM事件

调整参数后必须建立可观测的验证闭环。使用vmstat 2可实时观察si与so列，若数值持续为0或极低，说明Swap压力已缓解。现代内核支持PSI，通过cat /proc/pressure/memory可查看内存阻塞的绝对时间与百分比，比传统指标更精准。若怀疑发生OOM，应使用dmesg -T | grep -i oom或journalctl -k --grep="Out of memory"检索内核日志。日志中会明确打印触发OOM的时间、被杀进程的PID、名称及其当时的oom_score。结合free -m的历史快照与监控面板趋势，可交叉验证swappiness或oom_score_adj调整是否真正改变了内存回收行为，避免盲调导致问题掩盖。

常见误区与安全实践：不要把swap和oom_score_adj当万能开关

生产环境中极易陷入配置误区：例如盲目将swappiness设为100会导致频繁磁盘I/O拖垮系统，设为0则剥夺了内核的弹性缓冲；随意给大量进程赋予负oom_score_adj会使OOM Killer失去选择空间，最终可能误杀系统守护进程甚至引发内核Panic。在容器化场景下，仅调整宿主机参数而忽略Docker或Kubernetes的cgroup内存限制，会导致调整完全失效。安全实践应遵循“先观测、再调整、最后验证”原则：部署Prometheus持续采集内存水位与Swap使用率；在变更窗口期逐步微调参数；通过压力测试模拟内存泄漏场景，确认关键进程存活且非核心进程按预期退出。内存管理没有银弹，唯有结合业务特征与可观测数据，才能实现稳定与性能的平衡。