在Gunicorn超時轉儲Django堆棧跟蹤

我試圖調試Django應用程序的罕見掛起。到目前爲止，我沒能找出問題，它發生大約每天一次的生產和Gunicorn重新啓動過程與消息：在Gunicorn超時轉儲Django堆棧跟蹤

[CRITICAL] WORKER TIMEOUT

是否有配置的Django或Gunicorn轉儲程序的堆棧跟蹤的方式這是重新啓動？

來源

2013-03-15 Jan Wrobel

嘗試設置您的Gunicorn日誌更加冗長，可能將其設置爲INFO或DEBUG，這可能會在日誌中留下更多的光線。

你也可以看看Dog Slow，它會記錄緩慢的請求。 https://pypi.python.org/pypi/dogslow。

對於一般日誌記錄勝利，請嘗試使用Sentry：https://www.getsentry.com/welcome/。

隨機問題，在當時運行的服務器上的任何cron，備份，那種東西？

來源

2013-03-17 00:23:18 krak3n

狗慢看起來不錯，我可以設置它的超時時間比Gunicorn超時低一點，並得到一個鎖定過程的痕跡。謝謝！這在Heroku上運行，所以不應該有任何沉重的後臺進程。 – 2013-03-17 07:06:44

超時並不意味着請求超時。這意味着對工人進行生命力檢查。對於同步工作者來說，這起到了請求超時的作用，因爲除了處理請求之外，工作者不能做任何事情。即使在處理長時間運行的請求時，異步工作者也會心跳，因此除非工作人員阻止/凍結，否則不會被終止。

Gunicorn有一個叫做worker_abort的函數（參見下面的gunicorn文檔）。

def worker_abort(worker): 
    worker.log.info("worker received abort signal") 
    import threading, sys, traceback 
    id2name = dict([(th.ident, th.name) for th in threading.enumerate()]) 
    code = [] 
    for threadId, stack in sys._current_frames().items(): 
     code.append("\n# Thread: %s(%d)" % (id2name.get(threadId,""), threadId)) 
     stack = traceback.extract_stack(stack) 
     for filename, lineno, name, line in stack: 
      code.append('File: "%s", line %d, in %s' % (filename, lineno, name)) 
      if line: 
       code.append(" %s" % (line.strip())) 
    worker.log.debug("\n".join(code))

當工人收到SIGABRT信號時調用。此通話通常在超時時發生。可調用需要接受初始化Worker的一個實例變量。

來源：

http://docs.gunicorn.org/en/stable/settings.html，https://github.com/benoitc/gunicorn/issues/1493，https://github.com/benoitc/gunicorn/blob/master/examples/example_config.py

來源

2017-08-17 16:48:31

在Gunicorn超時轉儲Django堆棧跟蹤

回答

相關問題