vm.overcommit_memory有0（启发式，默认）、1（总是允许）和2（严格禁止）三种策略：0允许适度超额但可能误判oom，1无条件分配易触发oom killer，2按commitlimit严格限制，适用于关键业务。
调整Linux服务器内核的内存分配策略，核心是配置 vm.overcommit_memory 和配套参数，它决定了系统如何判断“有没有足够内存”来满足进程申请——这不是简单的物理内存加减法，而是内核对内存承诺的风控逻辑。
明确三种分配模式的实际含义
该参数取值为 0、1 或 2，每种对应完全不同的内存管理哲学：
- 0（默认，启发式）：内核粗略估算可用内存（含可回收缓存），允许少量过量分配。适合通用场景，但高负载下可能误判，导致OOM突然触发
- 1（总是允许）：不检查实际空闲内存，一律批准分配请求。科学计算或需要大块虚拟地址空间的场景可用，但极易引发OOM Killer杀进程
-
2（严格模式）：只允许分配不超过
CommitLimit的内存（≈ 物理内存 ×vm.overcommit_ratio+ swap）。金融、数据库等关键业务首选，OOM风险最低
配套调优不可少
单独改 vm.overcommit_memory 不够，必须同步设置约束边界：
- 查看当前限制：
grep -i commit /proc/meminfo，关注CommitLimit和Committed_AS - 若设为 2，建议调整
vm.overcommit_ratio（默认 50）：比如物理内存 64GB、无swap，想支持最多约 50GB 实际分配，可设为 78：sysctl -w vm.overcommit_ratio=78 - 同时收紧
vm.swappiness=10（数据库建议设为 1），减少因内存压力被迫换出的抖动
落地操作步骤
修改后需持久化并验证，避免重启失效或配置冲突：
- 临时生效：
sysctl -w vm.overcommit_memory=2 - 永久生效：在
/etc/sysctl.conf中添加一行vm.overcommit_memory = 2，再执行sysctl -p - 验证是否生效：
sysctl vm.overcommit_memory，并观察后续Committed_AS增长是否受CommitLimit约束
结合业务类型做选择
别套模板，看实际负载特征：
- 数据库（MySQL/PostgreSQL）、消息队列（Kafka）、实时交易服务 → 必选
2，配合低 swappiness 和关闭 THP - 批处理任务、离线计算作业 → 可考虑
1，但需确保有足够 swap 或 cgroup 限流兜底 - 中小Web服务、容器平台节点 →
0可接受，但务必监控MemAvailable和 OOM 日志
