頻繁500錯誤，需要重啟Gunicorn ，這是 Flask 的問題還是 Gunicorn 的問題？

01-26

The server encountered an internal error and was unable to complete
your request. Either the server is overloaded or there is an error in
the application.

這是怎麼回事呢？我感覺用mysql的時候效率不好。
Gunicorn 沒有錯誤輸出，只有這些

2013-02-08 18:11:47 [5625] [CRITICAL] WORKER TIMEOUT (pid:5632)

2013-02-08 18:11:47 [5625] [CRITICAL] WORKER TIMEOUT (pid:5636)

看日誌的意思是request超時了。

gunicorn有一個參數timeout用於設定request超時的限制。默認是30秒。即30秒內worker不能進行返回結果，gunicorn就認定這個request超時，終止worker繼續執行，向客戶端返回出錯的信息，用於避免系統出現異常時，所有worker都被佔住，無法處理更多的正常request，導致整個系統無法訪問。

所以可以檢查一下為什麼這個request會耗那麼久的時間（超過30秒），如果是正常的話，可以適當調高gunicorn的超時限制或者使用非同步的worker，如果是系統處理速度遇到瓶頸，那可能要從資料庫，緩存，演算法等各個方面來提升速度。話說如果一個request要很久才能返回，用戶體驗可能也是一個問題。所以盡量優化速度還是很重要的。

PS：gunicorn前面很有可能還有一層nginx，如果要調高超時限制，可能需要修改nginx的配置同時調高nginx的超時限制。

看看你們的進程模式是同步還是非同步的，如果改成 gevent 非同步，會在一定程度上緩解（一些網路操作不會引起超時）

另外，托 GIL 的福，Workder 的進程時間片相當寶貴，建議將耗時操作放到單獨進程中處理（通過消息隊列方式）

問題解決了嗎，同問。

我出現500的timeout超時問題，是在中斷請求後若干時間後，再次請求就出現超時錯誤。

如果是連續請求的話，是沒有問題的，響應速度也很快。

gunicorn有默認30秒的超時設置。如果30秒內還未有response，workder則會斷開鏈接。

--time 或者 -t 配置。

當然在配置文件中加上timeout參數也是可以的。

gunicorn重入會有問題，你是不是在你的應用裡面又請求了應用自己了。調一下

threads會好點，但也不是解決方法。估計需要拆分應用。