redis 生产环境必须禁用透明大页（thp），因其干扰 fork 的写时复制机制，导致内存抖动、tlb 压力和 rss 异常飙升；应设 enabled 和 defrag 为 never，并配合 vm.overcommit_memory=1 等内核参数调优。
Redis 在执行 bgsave 或 bgrewriteaof 时触发 fork，子进程本身不立即复制物理内存，但内核需为写时复制（COW）准备页表映射。若系统启用了透明大页（THP），反而会加剧内存开销——这不是“用了大页更省”，而是大页干扰了 COW 的页粒度管理，导致页分裂、TLB 压力和额外内存扫描。
确认是否启用透明大页（THP）
这是排查的第一步，也是最关键的开关：
- 运行
cat /sys/kernel/mm/transparent_hugepage/enabled，若输出含 [always] 或 [madvise]，说明 THP 已启用 - 运行
cat /sys/kernel/mm/transparent_hugepage/defrag，若为 [always]，表示内核后台线程khugepaged持续尝试合并小页，极易在 Redis fork 期间引发内存抖动 - 注意：即使 Redis 进程未显式申请大页，
always模式下内核仍会对匿名内存（如 Redis 堆）自动升格，而 Redis 内存分布稀疏、写入频繁，恰恰是 THP 的反模式场景
禁用 THP 并验证效果
禁用不是可选项，而是 Redis 生产环境的强制建议：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 临时禁用：
echo never > /sys/kernel/mm/transparent_hugepage/enabled，同时执行echo never > /sys/kernel/mm/transparent_hugepage/defrag - 永久生效：在
/etc/rc.local或 systemd 启动脚本中加入上述两行；或通过 grub 参数transparent_hugepage=never彻底关闭 - 验证是否生效：再次检查两个文件内容，确保均为 never；重启 Redis 后观察
INFO stats中latest_fork_usec是否显著下降，used_memory_rss在持久化期间是否不再异常飙升
结合其他内存策略协同调优
单禁 THP 不够，需同步控制内核对虚拟内存的预判逻辑：
-
vm.overcommit_memory = 1：让 fork 不再被 total_vm（地址空间大小）卡死，避免因 VmSize 远大于 VmRSS 导致的假性 OOM -
vm.swappiness = 1：保留极低 swap 回退能力，又防止内核因 swappiness=0 而拒绝换出匿名页，加剧 overcommit=2 下的分配失败 -
vm.vfs_cache_pressure = 50（默认 100）：适度降低 dentry/inode 缓存回收倾向，避免持久化时因缓存竞争加剧内存压力
观察关键指标定位是否真由大页引发
不要只看内存用量，要抓内核行为证据：
- 查
dmesg | grep -i "thp\|khugepaged"，看是否有合并失败、OOM killer 触发或页表分裂告警 - 对比
/proc/<redis-pid>/status</redis-pid>中VmSize和VmRSS：若差值巨大（如 VmSize 8G、VmRSS 2G），且禁用 THP 后该差值收窄，基本锁定问题 - 监控
/proc/sys/vm/nr_hugepages和/proc/meminfo | grep Huge，确认无手动配置的大页残留影响
