Flask+Gunicorn环境下代码块运行异常缓慢问题排查

核心问题定位 #

从测试数据看，numbers列表生成的耗时在两种环境下几乎一致，但messages列表生成耗时从0.15秒暴涨到93秒，差异完全集中在消息处理循环中的get_random_string(5)调用环节，结合两种环境的运行上下文，主要原因分析如下：

可能的原因及验证方案 #

• 系统熵池不足导致随机字符串生成阻塞
  如果你使用的是Flask自带的werkzeug.security.get_random_string，它默认依赖secrets模块调用系统加密级随机源（如/dev/random）。当服务器的熵池（用于生成加密随机数的环境噪声）被耗尽时，os.urandom会阻塞等待熵积累，每次调用get_random_string都会产生大幅延迟。
  终端直接执行时，可能刚好系统熵池充足；而Gunicorn的worker进程作为后台服务，无法像终端进程一样快速获取足够的熵，尤其是当message_res长度较大时，循环中多次调用get_random_string会把阻塞时间累加，最终导致总耗时急剧上升。
  验证方法：

  1. 执行cat /proc/sys/kernel/random/entropy_avail查看当前熵值（正常应大于1000）；
  2. 临时替换get_random_string为非加密级随机生成方式，比如：

     import random
     import string
     def temp_random_string(length):
         return ''.join(random.choice(string.ascii_letters + string.digits) for _ in range(length))
     

     替换后对比两种环境下的耗时，如果耗时恢复一致，即可确认是熵池问题。

• Gunicorn worker的资源调度优先级差异
  终端进程通常拥有更高的CPU调度优先级，而Gunicorn的worker进程作为后台服务进程优先级较低。当服务器存在其他负载时，worker进程的CPU时间片被抢占，会导致字符串处理循环变慢。但此原因无法解释耗时差距达数百倍的情况，优先级差异通常只会带来数倍的性能波动。

排除项说明 #

• Nginx反向代理不会影响请求到达Gunicorn后的代码执行耗时，因为你的计时逻辑是在Flask请求内部完成的，与Nginx的转发过程无关。
• 已确认cur.fetchall()和message_res的数据一致性，排除了数据量差异导致的耗时变化。

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