如何防止高並發 n8n 部署中連線過多的問題？

問題
1

嗨各位
我正在用多個工作者執行 n8n，隨著並發增加，我開始思考 PostgreSQL 連接管理的問題。
我的架構大致是：負載平衡器
↓
多個 n8n 工作者
↓
PostgreSQL
我的擔憂是，如果每個工作者開啟多個資料庫連接，資料庫最終可能會達到連接限制，影響工作流效能和穩定性。
我正在考慮使用 PgBouncer 等連接池，但我想了解其他人在生產環境中如何管理這個問題。
對於運行 PostgreSQL 高並發 n8n 部署的人員：
你們如何決定正確的 max_connections 設定？
你們是否使用 PgBouncer 等連接池，還是 PostgreSQL 的預設行為就足夠了？
你們如何監控連接耗盡情況，在它成為問題之前？
你們發現增加工作者數量或優化查詢對整體資料庫效能的影響更大嗎？

描述問題/錯誤/問題

錯誤訊息是什麼（如果有的話）？

請分享你的工作流

（在你的畫布上選擇節點，使用鍵盤快捷鍵 CMD+C/CTRL+C 和 CMD+V/CTRL+V 複製並貼上工作流。）

分享最後一個節點返回的輸出

關於你的 n8n 設定的資訊

  • n8n 版本：
  • 資料庫（預設：SQLite）：
  • n8n EXECUTIONS_PROCESS 設定（預設：own、main）：
  • 執行 n8n 的方式（Docker、npm、n8n cloud、桌面應用程式）：
  • 作業系統：
2

嘿 @Keira_Becky，在等待回應的同時，這些資源可能對你有幫助：

建議資源

自動匹配你的問題。

文件：

論壇：

@Wouter_Nigrini、@Yo_its_prakash、@jcuypers — 你們之前曾協助解決過類似的問題，可以看一下嗎？

由 n8n 的社群機器人自動建議。這是試點計劃 — 請在此分享回饋。

3

嗨 @Keira_Becky 一個好的做法是在增加連接限制之前優化連接使用。

建議的方法
不要持續提高 max_connections，而是使用像 PgBouncer 這樣的連接池來有效地重複使用現有連接。

n8n Workers
↓
PgBouncer
↓
PostgreSQL

這減少了連接開銷，幫助 PostgreSQL 更有效地處理更高的並發。

最佳實踐
對多個 worker 使用連接池
根據伺服器的 CPU 和記憶體設定 max_connections
監控活躍、閒置和等待中的連接
在新增更多 worker 之前優化緩慢的查詢

密切注意：活躍連接
閒置連接
連接等待時間
查詢延遲
CPU 和記憶體使用量

在生產環境中，連接池和查詢最佳化通常比簡單地增加 PostgreSQL 的連接限制提供更好的可擴展性。

4

在標準的 n8n 部署中，公式並不只是 workers * 1。每個工作者進程都可以維護一個連接池。

計算邏輯：

  • 主實例： 需要一些連接用於 UI、API 和調度器。
  • 工作者： 每個工作者進程通常維護一個小型池。如果你有 10 個工作者，每個允許 10 個池連接，那麼僅工作者就需要 100 個連接。
  • 開銷： PostgreSQL 為每個連接分配記憶體（大約 2-10MB，取決於 work_mem）。設定 max_connections 過高（例如 5000）而沒有足夠的 RAM，將導致作業系統通過 OOM 殺手終止 PostgreSQL。

建議： 對於中等規模的部署，從 max_connections = 200-500 開始。如果超過此限制，不要簡單地繼續增加數字；改用連接池工具。

PgBouncer 適用於高並發的生產環境。

PostgreSQL 的預設行為是「每個連接一個進程」，這是昂貴的。PgBouncer 充當一個輕量級代理，管理資料庫的「真實」連接池，同時允許來自 n8n 工作者的數千個「虛擬」連接。

image
image718×197 3.03 KB

這有幫助嗎？

5

嗨 @Keira_Becky
每個程序的調整參數是 DB_POSTGRESDB_POOL_SIZE，預設值為 2，所以佔用空間大約是（主程序 + 工作者 + webhook 處理器）乘以該值，你應該根據這個數字來調整資料庫大小，而不是根據工作者數量來估計。只有當工作者實際上在等待連接池時，才應該提高每個程序的該值。
透過運行更少數量但併發度更高的工作者來擴展，而不是運行大量低併發度的工作者。n8n 建議每個工作者的併發度為 5 或更高，因為大量低併發度的工作者會耗盡連接池並造成延遲和故障：

n8n worker --concurrency=10
6

@Niffzy

你在 n8n 中使用 PgBouncer 時是用交易模式還是工作階段模式?如果你兩種都試過,你在生產環境中注意到了什麼差異?

7

這取決於你的工作負載，但對於大多數高並發應用程式，事務連接池通常是首選，因為它允許連接更有效地重複使用，並支持更多的併發客戶端。

如果你的應用程式依賴於會話特定功能（例如臨時表或會話變數），會話連接池可能是更好的選擇，因為每個客戶端在整個會話期間保持相同的資料庫連接。

在選擇模式之前，我建議在測試環境中進行測試，並驗證你的 n8n 工作流程不依賴於會話特定的行為。然後監控連接使用情況、查詢延遲和整體吞吐量，以確認其表現符合預期。

一般來說，最佳選擇取決於應用程式如何使用資料庫連接，因此在部署之前值得使用類似生產環境的工作負載進行驗證。