vm.swappiness和vm.overcommit_memory分别调控内核换页倾向与内存申请策略：前者取值0–100，影响匿名页换出频率；后者取值0/1/2，决定malloc是否严格校验可用内存。
vm.swappiness 和 vm.overcommit_memory 是 Linux 内核中影响内存管理行为的关键参数，它们不直接决定“能用多少内存”，而是调控内核在内存压力下的决策倾向——何时换出匿名页、是否允许进程申请超过物理+交换空间总和的虚拟内存。选错值可能导致数据库卡顿、Java 应用频繁 GC、容器 OOM 杀死或服务响应突增延迟。
vm.swappiness：控制“多想把匿名页换到 swap”
取值范围 0–100，默认通常是 60。数值越高，内核越积极将匿名内存（如堆、栈）写入 swap；越低，则越倾向回收 page cache（如文件缓存）来腾出内存。
- 数据库类服务（MySQL/PostgreSQL/Redis）：建议设为 1 或 0。这类应用依赖内存缓存热点数据，swap 换入换出代价极高，且多数已做内存预分配或使用大页。设为 0 并不完全禁用 swap（OOM 时仍可能触发），但大幅降低常规场景下 swap 使用概率。
- 高吞吐 Web 服务（Nginx + PHP-FPM/Python WSGI）：可设为 10–30。有一定匿名内存（如 session、临时对象），但又需保留足够 page cache 加速静态文件或代理缓存。适度 swappiness 可避免因 page cache 占满导致新文件读取频繁丢弃缓存。
- 开发测试环境或内存充裕的桌面系统：保持默认 60 即可。平衡缓存与进程驻留，用户感知不明显。
vm.overcommit_memory：决定“能不能 malloc 成功”
取值 0/1/2，控制内核是否检查虚拟内存申请是否“有底可兜”。它不控制实际物理内存分配时机（那是缺页时的事），而是在 malloc() 或 mmap() 阶段就拒绝明显过量的请求。
- 值为 0（启发式检查，默认）：内核估算当前可用内存（含可回收 cache + swap），若申请远超该值则失败。适合通用服务器，兼容性好，但估算不准时可能误拒（如大量 page cache 可快速释放却未被计入）或漏判（如 swap 几乎耗尽却仍允许申请）。
-
值为 1（永远允许）：只要地址空间够，就返回成功。典型用于需要预分配大量虚拟内存但实际按需使用的场景，比如 JVM（-Xmx 设定堆上限）、某些科学计算库（如 NumPy 的 large array 预映射）。必须配合适当的
vm.overcommit_ratio或充足 swap，否则 OOM killer 容易介入。 -
值为 2（严格检查）：仅当申请总量 ≤
swap + RAM × overcommit_ratio%才允许。适合对稳定性要求极高的生产环境（如金融交易中间件），杜绝“虚假 malloc 成功”带来的 OOM 风险。注意：此时overcommit_ratio默认 50，若物理内存 64G、swap 8G，则最多允许约 40G 虚拟内存申请，需根据实际 workload 调整该比例。
组合策略参考
单个参数不能孤立调优，需结合业务内存模型看：
- OLTP 数据库（InnoDB buffer pool 占大头）：swappiness=1 + overcommit_memory=2（配合 overcommit_ratio=80–90，确保 buffer pool + 连接内存 + OS 开销不超限）。
- Java 微服务集群（多实例、堆外内存敏感）：swappiness=1 + overcommit_memory=1（JVM 自身管理堆，且 Netty 等常用堆外内存，需避免内核提前拒绝 mmap）。
- Kubernetes 节点（运行混合容器）：swappiness=1（避免 swap 干扰 QoS 分级）+ overcommit_memory=0（兼顾兼容性与基本防护，靠 kubelet 的 memory limit 和 OOM score 做更细粒度控制）。
验证与观测要点
改完参数后，不能只看 free -h，要盯真实行为：
- 查 swap 使用：
cat /proc/swaps、swapon --show，关注Priority和Used是否非零增长； - 看换页活动：
vmstat 1中si（swap in）和so（swap out）持续 > 0 表示活跃换页，需警惕； - 查 overcommit 状态：
grep -i "commit" /proc/meminfo，对比Committed_AS与MemTotal + SwapTotal； - 观察 OOM 日志：
dmesg -T | grep -i "killed process"，确认是否因 overcommit 策略不当引发误杀。
