Redis生产环境卡顿主因是Linux内核参数未调优，必须禁用透明大页（THP）、设vm.overcommit_memory=1、同步调整文件描述符与somaxconn、将vm.swappiness设为0，四者缺一不可，否则高并发下必然失能。
Redis性能在生产环境卡顿、延迟突增、连接失败，八成不是Redis本身写得差，而是Linux内核参数没调对。关键不在“全配”，而在几个必须改的点——改错或漏掉任何一个，都可能让Redis在高并发下直接失能。
禁用透明大页（THP）是硬性前提
Redis使用大量小内存分配（如每个client结构体、键值对象），而THP会强制合并为2MB大页，导致内存碎片飙升、fork()耗时暴涨，表现为bgsave超时、latest_fork_usec持续高于100ms。
- 临时禁用：
echo never > /sys/kernel/mm/transparent_hugepage/enabled - 永久生效：把
echo never > /sys/kernel/mm/transparent_hugepage/enabled加到/etc/rc.local，并确保该文件可执行 - 验证是否生效：
cat /sys/kernel/mm/transparent_hugepage/enabled输出必须含never，不能是always或advise
vm.overcommit_memory = 1决定bgsave能否成功
Redis持久化依赖fork()创建子进程。若vm.overcommit_memory = 0（默认），内核严格检查物理内存+swap是否足够，而fork()在写时复制（COW）机制下实际并不立即占用双倍内存——结果就是明明还有空闲内存，bgsave却报Cannot allocate memory。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须设为
1：echo "vm.overcommit_memory = 1" >> /etc/sysctl.conf && sysctl -p - 不建议设为
2：它按swap + RAM × overcommit_ratio严格计算，容易误判，且需同步调overcommit_ratio，徒增复杂度 - 验证：
cat /proc/sys/vm/overcommit_memory应返回1
文件描述符与TCP队列必须匹配
Redis连接数上限由两层共同限制：系统级ulimit -n和内核级net.core.somaxconn。若只调高maxclients但没同步改底层，新连接会在内核accept队列就丢弃，客户端看到的是Connection refused或超时，而非Redis拒绝连接。
- 系统级：在
/etc/security/limits.conf加两行：* soft nofile 65535和* hard nofile 65535；重启会话或重登生效 - 内核级：在
/etc/sysctl.conf设net.core.somaxconn = 511（需与Redis配置中tcp-backlog一致）；执行sysctl -p - 注意：
net.core.somaxconn值不能高于ulimit -n，否则无效；反过来，ulimit -n也不能低于Redis预期最大连接数
vm.swappiness = 0不是可选项，是底线
哪怕你给Redis分配了专用机器，只要启用了Swap，内核就可能把Redis工作集换出到磁盘——一次换入换出就是毫秒级延迟，而Redis要求微秒级响应。这不是“偶尔慢”，而是“随机卡死”。
- 临时关闭：
sysctl vm.swappiness=0 - 永久关闭：写入
/etc/sysctl.conf后sysctl -p - 验证：
cat /proc/sys/vm/swappiness必须为0；同时检查free -h中Swap行是否全为0，否则说明Swap分区仍在启用
这些参数之间有强依赖关系：比如vm.overcommit_memory = 1不生效，maxclients再高也白搭；swappiness没关，maxmemory设再准也没意义。调优不是堆参数，而是理清这四条链路——内存分配、进程派生、连接接纳、页面交换——哪一环断了，Redis就掉链子。
