Gradio应用在OpenShift部署下60分钟后重复触发预测事件

问题概述 #

开发的Gradio应用支持CSV上传、实体批量预测及结果下载，中小型文件（处理耗时<60分钟）运行正常，但大文件（耗时>60分钟）会在首次触发make_predictions()后刚好60分钟时，被自动二次调用，导致重复处理，最终因内存过载终止进程。本地运行无此异常，应用通过Docker打包、ArgoCD部署在OpenShift平台。

关键日志片段 #

22. Jan. 2024, 12:00:53.212 Started make_predictions() for /tmp/gradio/a97ef283367a497e8647575689f49df7ed48a8cb/400000_template.csv
(...)
22. Jan. 2024, 12:59:53.941 Predicting batch number 39/49 ...
22. Jan. 2024, 13:00:54.516 Started make_predictions() for /tmp/gradio/a97ef283367a497e8647575689f49df7ed48a8cb/400000_template.csv
(...)
22. Jan. 2024, 13:03:13.334 Predicting batch number 1/49 ...
22. Jan. 2024, 13:03:23.797 INFO: Started server process [1]

特殊场景验证 #

某次预测中因网络问题断开与Gradio界面的连接，容器内进程未被二次触发，最终正常完成处理。

核心原因分析 #

1. OpenShift路由超时限制 #

OpenShift默认路由超时时间为60分钟（3600秒），当Gradio前端与后端的长连接超过该时间后，路由会主动断开连接。Gradio前端会自动重试请求，导致make_predictions()被二次调用。特殊场景中网络断开后前端无法发起重试，进程正常完成，完全符合该逻辑。

2. Gradio WebSocket长连接特性 #

Gradio依赖WebSocket实现前后端实时交互，当WebSocket连接因路由超时被断开后，前端会重新建立连接并重复触发未完成的任务。本地环境无反向代理/路由的超时限制，因此不会出现该问题。

3. 内存过载引发容器重启 #

二次触发任务后，两个并行的预测进程会大幅占用内存，最终触发OOM（内存不足）导致容器重启，日志中13:03:23的Uvicorn重启记录也验证了这一点。

解决方案建议 #

1. 调整OpenShift路由超时 #

修改路由的haproxy.router.openshift.io/timeout注解，延长超时时间：

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/timeout: 36000s  # 设置为10小时
  # 其他路由配置

2. 启用Gradio队列机制 #

将任务改为异步后台处理，避免长时间占用WebSocket连接：

import gradio as gr

def make_predictions(file):
    # 原处理逻辑
    ...

with gr.Blocks() as demo:
    file_input = gr.File(label="上传CSV")
    btn = gr.Button("开始预测")
    result = gr.File(label="下载结果")
    btn.click(make_predictions, inputs=file_input, outputs=result)

demo.queue(max_size=10)  # 启用任务队列，后台处理任务
demo.launch()

3. 优化容器探针配置 #

调整存活/就绪探针参数，避免误判容器状态：

livenessProbe:
  httpGet:
    path: /health
    port: 8000
  initialDelaySeconds: 30
  periodSeconds: 60
  timeoutSeconds: 10
  failureThreshold: 3

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