燒瓶SQLAlchemy的TimeoutError

的Ubuntu 12.04
的Python 2.7
瓶0.9
燒瓶SQLAlchemy的
的Postgres 9.2

我已經得到這個錯誤信息：

TimeoutError: QueuePool limit of size 5 overflow 10 reached, connection timed out, timeout 30

我是否需要明確關閉db.session？會話超出範圍時不應將連接返回池中？

來源

2013-05-19 Massimo Fazzolari

@app.teardown_request 
def checkin_db(exc): 
    try: 
     g.db.close() 
    except AttributeError: 
     pass

來源

2013-05-20 14:58:31

這是默認SQLAlchemy的方法，但Flask-SQLAlchemy會爲您執行此操作。如果你正在使用Flask-SQLAlchemy，這應該不需要**。 –

Flask-SQLAlchemy爲您管理連接池，所以一般來說，不應該這樣做。但是，有些情況下無法控制這種情況，特別是如果您在請求上下文之外執行查詢或在某處使用with app.app_context()。

當我將Flask-SQLAlchemy與apscheduler配對時，我發現自己必須顯式關閉調度程序執行的作業中的會話，或者運行幾個小時後我會得到此錯誤。

來源

2015-02-18 03:02:00

注意：我知道這個問題已經兩年了，但是如果您使用Flask-SQLAlchemy搜索此錯誤並且可用信息已過期（即其他答案錯誤），則這是您從Google獲得的問題。 –

如果您在應用程序中使用了debug=True，並且您已加載出現多個錯誤頁面或API端點，則可能會發生這種情況。

原因是運行該應用程序的調試版本會在錯誤頁面中打開實時調試器。這個實時調試器保留處理請求的所有資源，以便您可以檢查它們。這意味着數據庫連接不能被回收。

您不應該爲您的應用程序的生產版本使用調試模式（除了像這樣的問題，這是一個安全風險），調試器往往不會工作（它被設計用於燒瓶測試服務器，而不是gunicorn）。因此，解決方案是關閉調試。

如果你在使用調試模式的開發中有這個問題 - 這是一個限制。你不應該如此難以擊中開發者服務器，或者你可以增加限制。請注意，15個連接通常足以在大量併發請求正確回收時提供服務。只有在調試時纔會用完。

來源

2016-06-29 11:06:27 jwg

我有這個相同的問題，但改變debug = False並沒有幫助我避免超時錯誤。如果我只是重新加載頁面15次，它會崩潰。我在工廠模式中使用Flask-Sqlalchemy，似乎沒有做任何不尋常的事情。但在這一點上，我的應用程序可以通過重新加載頁面而崩潰。 – bmjjr

@bmjjr在不同的問題中發佈你的代碼，我會看看它。 – jwg

謝謝，我終於想出了更多關於這個錯誤的信息，在我的情況下，當我用'SELECT * FROM pg_stat_activity查詢posgresql;'我發現很多與'idle in transaction'狀態有關的連接鏈接到角色/能力訪問檢查，主要來自我的模板。我使用flask-login並解決了問題，主動緩存flask-login user_loader用戶對象。也許有一個簡單的解決方案，但是這似乎運作良好，消除了我的情況下TimeoutErrors：https://stackoverflow.com/a/44612181/1493069 – bmjjr

燒瓶SQLAlchemy的TimeoutError

回答

相關問題