一. 问题描述

[2021-09-11 07:22:33 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:12)
[2021-09-11 07:22:35 +0000] [12] [INFO] Worker exiting (pid: 12)
 
Gunicorn 'Green Unicorn’是UNIX的Python WSGI HTTP服务器。它是一个从Ruby的Unicorn项目移植过来的预分叉worker模型。Gunicorn服务器广泛兼容各种web框架，实现简单，服务器资源使用少，速度相当快。
 
二. 原因分析
 
从报错信息可以看出，gunicorn 的 worker 进程超时导致进程退出重启。
 查阅 gunicorn 官方文档，有下图所示的描述：
 
 翻译如下：
 
timeout
 
命令行：-t INT 或 --timeout INT
 
默认： 30
 
默认超过这么多秒的 worker 进程将被杀死并重新启动。
 
值为正数或 0。将其设置为 0 会通过完全禁用所有 worker 的超时来实现无限超时。
 
通常，默认值 30 秒就足够了。如果您确定对同步 worker 的影响，则仅将此设置更高。对于非同步 worker，这仅意味着工作进程仍在通信，并且与处理单个请求所需的时间长度无关。
 
三. 解决方法
 
从官网的文档说明我们可以知道，gunicorn 默认的超时时间为 30s ，如果超过 30s，则 worker 进程将被杀死并重新启动。
 
所以解决这个问题只需要设置较大的超时时间即可：
 
 
使用 gunicorn 的命令行设置超时时间
 
gunicorn -w 2 -b 0.0.0.0:4343  manage:app --timeout 120 
 
在 gunicorn 的启动命令中加上：--timeout 120 表示超时时间设置为 120 秒。
 
 
在 gunicorn 的配置文件 gunicorn.conf.py 文件中配置超时时间
 
workers = 4  # 定义同时开启的处理请求的进程数量，根据网站流量适当调整
worker_class = "gevent"  # 采用gevent库，支持异步处理请求，提高吞吐量
bind = "0.0.0.0:8500"  # 监听IP放宽，以便于Docker之间、Docker和宿主机之间的通信
timeout = 120  # 设置超时时间为 120 秒
   
关于 gunicorn.conf.py 文件的更多配置查看官网
 
参考文档：
 gunicorn 官方文档
                    一. 问题描述在使用 Gunicorn +  flask 搭建的一个 web 项目中，由于使用了机器学习模型，在第一次请求接口的时候需要加载模型，在本地运行的时候加载模型很快所以正常运行，将应用使用 docker 的方式部署到服务器上面（模型是通过 volume 的方式挂载到容器中的）， 第一次请求加载模型耗时比较长，报出如下错误：[2021-09-11 07:22:33 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:12)[2021-09-11 07:22:35
				
gunicorn 超时报错： WORKER TIMEOUT
一 问题描述：
在某一个上午，开发突然报障容器莫名重启，经过查看业务容器日志发现 worker timeout字段
二 分析报错原因：
从报错信息可以看出，gunicorn 的 worker 进程超时导致进程退出重启，查看了官网 官网解释gunicorn 默认的超时时间为 30s ，如果超过 30s，则 worker 进程将被杀死并重...
Python 2.7，所有辅助类
Python 3.4 +， thriftpy_sync和thriftpy_gevent工作者类（Python 3不支持使用Thrift工具包生成的代码）
thrift
 生成节俭文件： 
% thrift --out tests/pingpong_sdk --gen py:new_style,utf8strings tests/pingpong.thrift
 写节俭的应用程序。
 #! /usr/bin/env python
# tests/app.py
# -*- coding: utf-8 -*-
from pingpong
您将在树目录中找到如何使用此脚本的示例。
 例如， CONF_DIR目录（默认为/etc/gunicorn ）中的每个文件都代表一个 Web 应用程序。 对于每个配置文件，主 Gunicorn 进程的 PID 存储在/var/run/gunicorn/<conf>.pid ，日志打印到/var/log/gunicorn/<conf>.log 。
脚本配置文件是/etc/default/gunicorn 。 您需要设置以下变量：
 RUN <yes> ，脚本应该在系统启动时运行吗？
 CONF_DIR ，web 应用程序配置文件在哪里？
 CONFIGS ，要加载哪个配置文件？
 USE_VIRTUALENVS ，要加载哪个配置
				
问题描述：[2017-04-05 10:54:41 +0000] [3384] [CRITICAL] WORKER TIMEOUT (pid:3625) 
[2017-04-05 10:54:41 +0000] [3625] [INFO] Worker exiting (pid: 3625) 
[2017-04-05 10:54:41 +0000] [3630] [INFO] Booting wor
print('home:'+home)
bind = '0.0.0.0:8000'      #绑定ip和端口号
backlog = 512                #监听队列
chdir = home+'/server/bin'  #gunicorn要切换到的目的工作目录
timeout = 30      #超时
worker_.
				
@TOC解决Pytorch模型在Gunicorn部署无法运行或者超时问题
训练出了一个Pytorch 文本生成模型，想要用Flask+Gunicorn的方法部署。但是请求模型进行生成的接口时，一直没有结果，最后导致timeout。
我的模型生成接口大概长这样：
model = load_model() #load_model会返回一个pytorch模型
@app.route('/generate')
def generate_texts():
    text = model.generate(
				
Docker Python基础
一个简单的python Docker设置，可从一个ops基地支持本地和生产开发。 app/目录中包含一个超级简单的Flask应用app/用于演示，但是可以轻松地将其切换到任何WSGI兼容的应用程序。
对于本地开发，只需运行make run-local 。 构建完成后，容器将在http://<container>:5000上运行Flask演示应用程序。
 要在生产容器中运行make run-deploy ，请运行make run-deploy 。 构建完成后，容器将在http://<container>上运行Flask演示应用程序。
 除了run命令之外，还make build-local和make build-deploy来构建容器而不运行它们。
有用的Docker命令（谨慎使用）
 查看Docker图像
 docker images
				
支持的标签和相应的Dockerfile链接
 注意：注意：都有。 如果您需要“固定”使用的Docker映像版本，则可以选择这些标签之一。 例如tiangolo/uvicorn-gunicorn:python3.7-2019-10-15 。
葡萄干-独角兽
与图像设法在高性能的Web应用程序的Python 3.6及以上，性能自动调整。 可以选择是苗条版本或基于Alpine Linux。
 GitHub存储库： https : //github.com/tiangolo/uvicorn-gunicorn-docker
 Docker Hub映像： https : //hub.docker.com/r/tiangolo/uvicorn-gunicorn/
根据第三方基准测试，使用Uvicorn （使用Python异步Web应用程序的“ ASGI”规范）运行的Python Web应用程序已
这是使用Nginx + Gunicorn服务于Flask应用程序的示例配置。
设置python环境
下面显示了如何设置环境并假定您具备bash / RHEL的知识。 以下内容已在RHEL 6.8 (Santiago)上进行了测试，并假定您正在重新安装操作系统（即，不假定您已经安装了所有这些依赖项）。
 让我们创建一些bash变量以开始使用。 在这里，我们假设flask应用程序将安装在/opt/apps目录中，Python环境将命名为myenv并且我们正在手动设置PATH变量以包括该环境。 如果您已经有一个环境并使用source activate myenv激活了该环境，则无需手动设置PATH变量。 
APPS_DIR=/opt/apps
PYTHON_ENV=myenv
PATH=/usr/local/envs/ $PYTHON_ENV /bin:/us
				创建自定义ingress报错：Internal error occurred: failed calling webhook “validate.nginx.ingress.kubernetes.io
					13092
                创建自定义ingress报错：Internal error occurred: failed calling webhook “validate.nginx.ingress.kubernetes.io
                    汤同学丶: 
                    所以是因为我装了好几次ingress-nginx, 删除的时候没有删掉validatingwebhookconfigurations下面的这个ingress-nginx-admission对吗