uwsgi和nginx部署flask问题

pangforFC

在阿里云服务器上通过nginx和uwsgi部署flask项目
功能是用户上传图片，服务器进行推理后返回推理结果
但是遇到问题：
用户第二次上传图片时，uwsgi显示：
DAMN ! worker 2 (pid: 27519) died, killed by signal 9 :( trying respawn ...
Respawned uWSGI worker 2 (new pid: 27587)

搜索说是超时导致，从用户第一次访问到进程被杀死大约50秒

uwsgi的配置文件如下：
[uwsgi]
http-socket = 0.0.0.0:5000
chdir = /root/flask_518
wsgi-file = Server2.py
callable = app
processes = 2
reload-on-rss=4048
threads = 10
enable-threads=true
buffer-size = 32768
harakiri=130
socket-timeout=130
master = true
pidfile=uwsgi.pid

FishC

这个问题很可能是uwsgi超时引起的。根据你的配置文件，你设置了`harakiri=130`和`socket-timeout=130`，这意味着uwsgi将在130秒内没有收到来自客户端的请求时，会自动杀死工作进程。

如果你的图片上传和推理过程比较耗时，那么超过130秒就会导致uwsgi杀死工作进程，然后重新启动新的进程，这也解释了为什么用户第二次上传图片时会出现worker被杀死的情况。

要解决这个问题，你可以尝试增加uwsgi的超时时间。修改配置文件中的`harakiri`和`socket-timeout`的值为一个更大的数值，以适应上传和推理所需要的时间。例如：

1. harakiri=600
   
2. socket-timeout=600

复制代码

这里我将超时时间设置为600秒，你可以根据实际需要进行调整。

记得修改完配置文件后，重启uwsgi服务，使修改生效。

另外，请确保你的服务器性能足够强大，能够处理同时上传多个图片的情况。如果并发量较高，你还可以考虑增加uwsgi的工作进程数量（`processes`），或者使用负载均衡等技术来提高服务器的性能和稳定性。

希望能帮到你！

以上回复来自 FishC AI 小助理，如未能正确解答您的问题，请继续追问。

isdkz

有可能你的程序报错了

pangforFC

FishC 发表于 2024-6-2 18:06
这个问题很可能是uwsgi超时引起的。根据你的配置文件，你设置了`harakiri=130`和`socket-timeout=130`，这 ...

推理耗时顶多十多秒，没有到100秒

FishC

pangforFC 发表于 2024-06-02 20:21
推理耗时顶多十多秒，没有到100秒

抱歉，我之前的回答可能有误解。如果推理耗时只有十多秒，那么超时时间设置为130秒应该足够，不会导致uwsgi杀死工作进程。这个问题可能有其他原因引起。

首先，您可以检查nginx的错误日志和uwsgi的日志，看是否有其他错误信息提供更多的线索。

另外，您可以尝试增加uwsgi的缓冲区大小（buffer-size）。将其值调大一些，例如32768可以增加到65536，看是否能解决问题。

此外，您提到使用了两个uwsgi进程（processes = 2），您可以尝试将进程数设为1，然后再次测试上传图片，看是否问题仍然存在。如果问题消失了，那可能是由于多个进程之间的某种冲突导致的问题。

最后，还请确保您的服务器配置足够强大，能够处理并发上传图片的情况。如果服务器性能较弱，可能无法同时处理多个请求，并导致uwsgi进程超时。

希望以上建议对您有所帮助，祝您成功解决问题！

以上回复来自 FishC AI 小助理，如未能正确解答您的问题，请继续追问。

pangforFC

isdkz 发表于 2024-6-2 18:56
有可能你的程序报错了

谢谢，我检查了后端的程序，如果直接运行app.py，第二次访问后端是没有问题的；
我发现前端的第二轮操作会有一些问题，但不清楚uwsgi的进程超时被杀死是不是因为前端

FishC

pangforFC 发表于 2024-06-02 21:02
谢谢，我检查了后端的程序，如果直接运行app.py，第二 ...

如果您确定后端程序单独运行没有问题，并且问题可能出现在前端操作上，那么您可以尝试检查前端代码是否有导致超时的问题。

首先，您可以检查前端代码中的请求是否正确处理了响应。确保每次上传图片后，都正确地关闭了与服务器的连接，以便释放资源。您可以使用开发者工具或浏览器的网络面板来查看请求和响应。

此外，还请检查前端代码中是否有循环发送请求的情况，或者是否有其他可能引发超时的异步操作。这些情况下，前端可能会连续发送多个请求，导致服务器端的uwsgi进程超时。

另外，如果您的前端是基于JavaScript的，您可以考虑使用setTimeout或者setInterval函数来控制前端发送请求的频率，以免给服务器造成过大的压力。您可以适当调整时间间隔，避免发送过于频繁的请求。

最后，如果发现前端确实有问题，并且无法解决，您可以尝试寻求前端开发人员的帮助，确保前后端的交互是正确的，以避免超时的问题。

希望以上建议对您有所帮助，祝您顺利解决问题！

以上回复来自 FishC AI 小助理，如未能正确解答您的问题，请继续追问。