你好工程师试图改变世界! ......以及任何愿意提供帮助的人:)
在python中添加了一个runloop代码后,uwsgi似乎需要更长的时间来杀死
停止uwsgi曾经非常快。 最近我集成了一个后台线程来定期检查数据库并在需要时每隔60秒进行一次更改。
这似乎工作得很好,除非现在每次我试图杀死uwsgi,都需要很长时间。
################################
## deploy.ini module .py file ##
################################
from controllers import runloop
from flask import Flask
from flask import request, redirect,Response
app = Flask(__name__)
runloop.startrunloop()
if __name__ == '__main__':
app.run() #app.run(debug=True)
################################
## runloop.py ##
################################
### initialize run loop ###
## code ref: http://stackoverflow.com/a/22900255/2298002
# "Your additional threads must be initiated from the same app that is called by the WSGI server.
# 'The example below creates a background thread that executes every 5 seconds and manipulates data
# structures that are also available to Flask routed functions."
#####################################################################
POOL_TIME = 60 #Seconds
# variables that are accessible from anywhere
commonDataStruct = {}
# lock to control access to variable
dataLock = threading.Lock()
# thread handler
yourThread = threading.Thread()
def startrunloop():
logfuncname = 'runloop.startrunloop'
logging.info(' >> %s >> ENTER ' % logfuncname)
def interrupt():
logging.info(' %s >>>> interrupt() ' % logfuncname)
global yourThread
yourThread.cancel()
def loopfunc():
logging.info(' %s >>> loopfunc() ' % logfuncname)
global commonDataStruct
global yourThread
with dataLock:
# Do your stuff with commonDataStruct Here
# function that performs at most 15 db queries (right now)
# this function will perform many times more db queries in production
auto_close_dws()
# Set the next thread to happen
yourThread = threading.Timer(POOL_TIME, loopfunc, ())
yourThread.start()
def initfunc():
# Do initialisation stuff here
logging.info(' %s >> initfunc() ' % logfuncname)
global yourThread
# Create your thread
yourThread = threading.Timer(POOL_TIME, loopfunc, ())
yourThread.start()
# Initiate
initfunc()
# When you kill Flask (SIGTERM), clear the trigger for the next thread
atexit.register(interrupt)
我用:
启动服务器$ nginx
并停止:
$ nginx -s stop
我开始使用uwsgi:
$ uwsgi —enable-threads —ini deploy.ini
我停止使用uwsgi进行python更改:
ctrl + c (if in the foreground)
否则我会停止使用uwsgi:
$ killall -s INT uwsgi
然后在更改python代码后,我再次使用:
启动uwsgi$ uwsgi —enable-threads —ini deploy.ini
以下是我尝试杀死时的示例nginx输出:
^CSIGINT/SIGQUIT received...killing workers...
Fri May 6 00:50:39 2016 - worker 1 (pid: 49552) is taking too much time to die...NO MERCY !!!
Fri May 6 00:50:39 2016 - worker 2 (pid: 49553) is taking too much time to die...NO MERCY !!!
非常感谢任何帮助或提示。如果我需要更清楚地了解或者我是否缺少任何细节,请告诉我。
谢谢! 埃里克
答案 0 :(得分:5)
我知道这个问题有点老了,但是我遇到了同样的问题,谷歌让我来到这里,所以我会回答那些在同一条船上来的人。
问题似乎是由“--enable-threads”选项引起的,我们有几个应用程序运行uwsgi和flask,只有带有此选项的应用程序有问题。
如果您想要的是让uwsgi进程更快死亡,您可以添加以下选项:
reload-mercy = int
worker-reload-mercy = int
它们将导致uwsgi强制进程在 int 秒后退出。
另一方面,如果您只需要重新加载uwsgi,请尝试发送SIGHUP信号。这将导致uwsgi重新加载它的孩子。
POST注意:似乎我说得太早了,使用SIGHUP有时也会挂起。我正在使用怜悯选项来避免挂起太长时间。
另外,我发现了关于uwsgi github的问题报告,如果有人想要关注它: