memorymin和memoryhigh是cgroups v2下实现弹性内存保护的关键参数:memorymin锁定最小可用内存(如1g),内核优先保障不回收;memoryhigh设柔性阈值(如2g),超限即触发主动回收与节流但不杀进程,需配合memorymax兜底,依赖cgroups v2且须root权限配置。

在 systemd 中,MemoryMin 和 MemoryHigh 是 cgroups v2 下用于构建弹性内存保护的关键参数,它们不触发强制终止,而是通过内核级资源调度实现“软防护”——既保障核心进程优先获得内存,又避免突发负载导致服务被 OOM 杀死。
MemoryMin:为关键进程锁定最低可用内存
该参数设定进程组**保证可使用的最小物理内存**(单位:字节或带后缀如 512M),内核会尽量保留这部分内存不被回收。适用于数据库主进程、API 网关等不可降级的核心组件。
- 仅对 cgroups v2 生效,需确认系统已启用统一层级(
mount | grep cgroup2可验证) - 设为
MemoryMin=1G后,即使系统整体内存紧张,该服务仍能稳定保有约 1GB 物理页 - 不能单独使用:必须配合
MemoryMax或MemoryHigh才有意义,否则等于无上限 - 注意:它不阻止其他进程分配内存,只是让内核在内存回收时“绕开”这部分页
MemoryHigh:触发主动节流的柔性阈值
MemoryHigh 是真正的“第一道防线”,当进程内存使用持续接近该值时,内核会自动启动内存回收(reclaim),并对该 cgroup 内进程施加 I/O 和 CPU 节流,显著降低其内存申请速率,但不会杀死进程。
- 例如设
MemoryHigh=2G,当服务内存占用达 1.95G 并持续数秒,内核即开始后台回收匿名页与文件页 - 比
MemoryMax更友好:适合 PHP-FPM、Node.js 等存在合理内存波动的业务,避免因瞬时峰值被误杀 - 建议值 = 预估常态峰值 × 1.3~1.5;过高失去防护意义,过低会导致频繁节流影响响应
- 需搭配
MemoryMax使用(如MemoryMax=2.5G)作为最终兜底
典型配置组合与生效验证
以 MySQL 为例,在 /etc/systemd/system/mysqld.service.d/override.conf 中写入:
[Service] MemoryMin=1G MemoryHigh=2G MemoryMax=2.5G MemorySwapMax=0
执行 sudo systemctl daemon-reload && sudo systemctl restart mysqld 后验证:
- 检查是否加载:
systemctl show mysqld | grep -E "MemoryMin|MemoryHigh|MemoryMax" - 观察实时使用:
cat /sys/fs/cgroup/memory/system.slice/mysqld.service/memory.current - 模拟压力测试时,用
journalctl -u mysqld -n 20查看是否有 “memory: usage increased” 类日志,表明 MemoryHigh 已介入调控
关键注意事项
这两项能力依赖底层机制,配置前务必确认:
- 系统运行 cgroups v2(Ubuntu 22.04+/RHEL 8+/Arch 默认启用)
- 未禁用 memory controller(检查
/proc/cgroups中 memory 行是否为 1) - service 类型不能为
Type=oneshot(需长期驻留进程才能受 cgroup 管控) - 普通用户无法设置这些参数,必须由 root 或具备
CAP_SYS_RESOURCE的进程操作











