Go Redis客户端连接池与服务核心数对请求延迟的影响

是的，这个延迟上升现象和epoll直接相关，同时也结合了Go的IO调度机制、Redis连接池大小变化的共同影响，具体拆解如下：

• epoll的IO多路复用能力受核心数限制
  Go的网络IO底层在Linux环境下依赖epoll实现多路复用。当服务核心数从4核降到1核时，Go调度器的GOMAXPROCS会同步设为1，意味着所有的goroutine（包括处理epoll事件的goroutine）都只能在单个OS线程上调度。原本4核时，epoll的事件可以被多个OS线程并行处理，IO响应的及时性很高；1核场景下，epoll事件处理会和业务逻辑goroutine抢占CPU资源，一旦有耗时的业务逻辑执行，epoll就无法及时处理Redis的响应事件，导致请求的整体RTT被大幅拉长。

• 连接池收缩放大了epoll的调度压力
  你提到Redis客户端会随核心数减少同步降低连接数（4核→40连接，1核→10连接）。连接数不足会导致大量请求在客户端侧排队等待可用连接，而这些排队的请求最终都要通过有限的10个连接发送到Redis。同时，单核心下epoll需要处理这10个连接的所有读写事件，加上业务逻辑的CPU占用，epoll的事件处理队列容易出现堆积，进一步推高单请求的延迟。2核时连接数升到20，调度压力有所缓解，延迟也随之降到20ms，正好对应这个逻辑。

• Go调度器的单核心瓶颈
  单核心场景下，Go的M:N调度无法利用多核并行优势，负责epoll的netpoller线程会被业务goroutine频繁抢占。比如当某个业务goroutine长时间占用CPU时，netpoller无法及时唤醒处理Redis的响应包，导致已经返回的Redis响应无法被及时读取并返回给上层，这部分等待时间直接体现在单请求延迟上。

验证方向 #

• 手动固定Redis客户端的连接池大小（比如1核时强制设为40），观察延迟是否回落，以此区分连接数不足和epoll调度的影响占比；
• 用Go的pprof工具分析1核场景下的goroutine阻塞情况，查看是否有大量goroutine卡在获取Redis连接的阶段；
• 监控AWS实例的CPU使用率，确认1核时是否出现CPU饱和，饱和状态会进一步加剧epoll事件处理的延迟；
• 查看系统的epoll_wait调用耗时，通过perf工具统计该系统调用的平均耗时，验证核心数减少后是否出现耗时上升。

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