fork()会阻塞Redis主线程，因需同步完成页表复制等内核操作，内存超10GB且启用透明大页时耗时易超500ms；升级内核至4.14+并关闭THP可显著优化，SSD对fork本身无改善。
fork 子进程阶段会短暂卡住主线程
Redis 执行 bgsave 或 bgrewriteaof 时，第一步是调用 fork() 创建子进程。这个动作由内核完成，主线程会阻塞——不是“卡死”，而是暂停执行命令，等待页表复制完毕。若 Redis 占用 10GB 内存，页表项数可能达百万级；启用透明大页（THP）时，阻塞时间可能翻倍。监控时看到的“CPU 100%”往往不是主线程在算，而是 fork 后子进程正在满负荷工作。
常见错误现象：redis-cli --latency 显示 p99 延迟突增几十毫秒；INFO stats 中 latest_fork_usec 值超过 500000（即 500ms）；系统日志出现 fork() failed: Cannot allocate memory。
- 检查 THP 状态：
cat /sys/kernel/mm/transparent_hugepage/enabled，应为never - 避免在内存接近上限时触发持久化，预留至少 20% 内存余量
- 不要给 Redis 进程绑定 CPU 核心，否则 fork 出的子进程会和主线程争同一核
bgsave 的 CPU 开销集中在序列化阶段
子进程 fork 完成后，真正吃 CPU 的是遍历全部 key-value、编码压缩（如 LZF）、计算校验和、写入临时 RDB 文件的过程。这部分纯 CPU 计算，无法并行，且随数据量线性增长。2GB 数据的 bgsave 在 4 核机器上可能持续 1–3 秒，期间子进程 CPU 占用常达 90%+，但主线程不受影响（只被 fork 阻塞过一次）。
使用场景：RDB 是全量快照，适合冷备或灾备恢复；但高频触发（如每秒 save 1 1）会导致频繁 fork + 序列化，完全不可行。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
save命令绝对禁用——它在主线程执行，直接阻塞所有请求 - 生产环境只用
bgsave，且 save 配置建议设为save 60 10000这类低频策略 - 混合持久化（
aof-use-rdb-preamble yes）能减少 AOF 重写压力，但 RDB 部分仍要走同样序列化流程
bgrewriteaof 和 appendfsync everysec 的 CPU 成本差异很大
bgrewriteaof 的 CPU 消耗和 bgsave 属于同一量级：它也要 fork 子进程、遍历全量数据、生成新 AOF 文件。而日常的 appendfsync everysec 几乎不耗 CPU——每个写命令只做一次 memcpy 到 aof_buf，长度几十字节，耗时纳秒级；每秒一次 write(2) 由后台线程异步处理，不参与命令路径。
容易踩的坑：no-appendfsync-on-rewrite yes 能避免 AOF 重写时同时刷盘，但仅适用于 everysec 模式；若设为 always，Redis 启动直接报错：ERROR: Invalid argument for config 'no-appendfsync-on-rewrite'。
- AOF 日志本身不重算、不压缩，所以追加操作极轻量
- 真正高 CPU 场景是
bgrewriteaof或混合持久化中的 RDB 部分，不是日常 AOF 写入 - 如果发现 CPU 高但 QPS 不高，优先查
INFO persistence中rdb_bgsave_in_progress和aof_rewrite_in_progress是否为 1
hz 参数调太高会让过期键清理变成 CPU 杀手
hz 控制 Redis 每秒执行多少次过期键扫描，默认是 10。设成 100 后，过期检查频率提高 10 倍，但 CPU 使用率也会明显上升——尤其当大量 key 集中到期时，扫描逻辑本身就会占用可观算力。Redis 6.2+ 会动态调整 hz，但配置文件里硬写 hz 100 仍可能触发意外开销。
性能影响：对延迟敏感业务（如金融交易）可适度提高 hz，但普通服务保持默认即可；盲目调高反而可能让 CPU 被过期扫描吃掉，挤占网络 I/O 或命令执行资源。
- 运行时修改：
CONFIG SET hz 20，观察INFO stats中expired_keys和evicted_keys变化趋势 - 别在大 key 场景下调高
hz，因为每次扫描都要遍历整个过期字典桶 - 如果用了
LFU淘汰策略，hz过高还会额外加重访问计数更新负担
INFO persistence 和 INFO stats，比看 top 更准；优化时别只盯着配置参数，得清楚每个参数背后触发的是哪段实际代码路径。 
