Docker容器中使用Gunicorn+PaddleOCR遇随机请求Worker超时崩溃问题

可能原因 #

• Gunicorn默认超时时间过短，PaddleOCR处理复杂图片耗时超出阈值，主进程发送SIGABRT终止worker进程
• 多worker进程间的GPU/CPU资源竞争，导致内存溢出或底层资源冲突
• PaddlePaddle、PaddleOCR及依赖库版本不兼容，触发C++层异常

解决方案 #

1. 调整Gunicorn超时配置 #

修改启动命令，延长worker超时时间（根据实际处理耗时调整，示例设为60秒）：

gunicorn --timeout 60 --workers 4 --bind 0.0.0.0:8000 your_app:app

• --timeout：设置worker超时秒数
• --workers：根据服务器硬件配置调整，GPU环境建议设为1-2，CPU环境设为核心数的1-2倍

2. 优化PaddleOCR资源分配 #

• GPU环境：指定单GPU并启用显存自动回收，避免多worker抢占显存：

import paddle
paddle.set_device('gpu:0')
paddle.fluid.core._set_eager_deletion_mode(True)

• CPU环境：减少worker数量，避免CPU资源耗尽导致进程崩溃

3. 对齐依赖版本兼容性 #

安装官方推荐的版本组合（根据CUDA版本调整PaddlePaddle版本）：

pip install paddlepaddle-gpu==2.4.1 paddleocr==2.6.0.1

更新基础依赖库：

pip install --upgrade numpy opencv-python

4. 开启调试日志定位问题 #

增加Gunicorn日志级别，同时在应用中记录请求细节：

gunicorn --timeout 60 --workers 4 --bind 0.0.0.0:8000 --log-level debug your_app:app

在代码中添加请求日志，记录图片大小、处理时长、请求参数等信息，便于定位异常请求特征

5. 捕获崩溃信号（可选） #

添加信号处理函数，捕获SIGABRT并打印堆栈信息，定位底层错误：

import signal
import traceback

def sigabrt_handler(signum, frame):
    traceback.print_stack(frame)
    exit(1)

signal.signal(signal.SIGABRT, sigabrt_handler)

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