PHP访问同容器部署Redis出现极长IO WAIT高延迟问题排查

• 容器网络命名空间loopback性能损耗：同一容器内走loopback访问Redis看似是本地通信，低版本Docker等容器运行时的默认网络配置，可能会对loopback流量做不必要的地址转换、流量统计，高QPS下会产生大量软中断开销，hypervisor层面看不到IO WAIT，因为属于CPU软中断瓶颈。可在容器内执行redis-cli --intrinsic-latency 10测试Redis原生延迟，排除网络层面影响。
• 大key/热key导致单线程阻塞：Redis采用单线程处理命令，即使总key量级小，只要存在单个value超过10KB的大key、或者单key访问QPS超过1000的热key，就会阻塞后续所有命令执行，表现为全量操作延迟升高。可通过redis-cli --hotkeys和redis-cli --bigkeys快速扫描确认。
• 容器CPU限流配置触发节流：如果容器配置了CPU配额（比如--cpus 1、CPU shares限制），高访问频率下Redis进程的CPU时间片被耗尽，内核会将进程挂起等待调度，此时hypervisor层面整体物理CPU使用率不高、也不会出现IO WAIT，但进程内部处理延迟会大幅升高。可查看容器内/sys/fs/cgroup/cpu/cpu.stat文件的throttled_time字段，确认是否存在CPU限流。
• Redis持久化策略隐性开销：如果开启了RDB快照/AOF持久化，即使IO WAIT数值不高，fork子进程的瞬间会阻塞Redis主线程，高QPS下fork耗时会被放大，且容器内PID命名空间的fork开销远高于物理机。可临时关闭持久化测试10分钟，观察延迟是否回落。
• 透明大页（THP）未关闭：Linux默认开启的透明大页会导致Redis在高QPS下出现内存分配卡顿，是Redis官方明确建议关闭的配置，若容器内未单独关闭THP，即使宿主机已关闭也可能继承内核默认配置。可执行echo never > /sys/kernel/mm/transparent_hugepage/enabled临时关闭验证效果。

内容的提问来源于stack exchange，提问作者Josh