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的进程操作
