GCP：n8n 在 Cloud Run 啟動期間 Postgres 連線逾時（Cloud SQL Unix socket）

問題
1

描述
我們在 Google Cloud Run 上的 n8n 觀察到一次性啟動事件，使用 Cloud SQL 上的 PostgreSQL（Unix socket 連線）。

環境

  • n8n 版本：2.32.5
  • 執行時：Google Cloud Run (Gen2)
  • 地區：europe-west3
  • 資料庫：Cloud SQL 上的 PostgreSQL
  • 連線方式：/cloudsql 下的 Unix socket

發生的情況

  • 在一個啟動時段中，n8n 記錄了重複出現的：
    • Error: timeout exceeded when trying to connect
    • 指向 pg-pool、@n8n/typeorm 和 @n8n/db 連線取得路徑的堆疊追蹤。
  • 在同一時段中：
    • 根端點可以返回 200
    • 某些 API 呼叫返回 500 / 高延遲
    • 依賴資料庫的背景工作報告失敗
  • 執行了手動重新部署。
  • 重新部署後不久，服務穩定，此後運作正常。
2

嘿 @rgrzesk，當你等待回覆時，這些資源可能會對你有幫助：

建議資源

自動符合您的問題。

文件：

論壇：

@Mayank1024、@Websensepro、@tamy.santos - 你們之前曾協助解決類似的問題，能看一下嗎？

由 n8n 社群機器人自動建議。這是試點計畫 - 請在此分享反饋。

3

嗨 @rgrzesk 看起来你只是在回报一个错误，对吧？你的实例现在都没问题了？

4

@rgrzesk

看起來更像是一份事件報告給我。
或許你會想要向你的提供商提出這個問題

5

嗨 @rgrzesk
「timeout exceeded when trying to connect」來自 pg-pool 的獲取逾時，所以連線池在 DB_POSTGRESDB_CONNECTION_TIMEOUT 內從未交付用戶端，而不是 Cloud SQL 套接字無法連線。DB_POSTGRESDB_POOL_SIZE 預設為 2，在單一 Cloud Run 執行個體上，啟動查詢加上傳入流量會排隊等待那兩個連線，這就是為什麼根端點保持 200，而資料庫支援的呼叫變成 500。在修訂版上提高兩者：

DB_POSTGRESDB_POOL_SIZE=10
DB_POSTGRESDB_CONNECTION_TIMEOUT=60000

然後將 Cloud Run 容器併發上限設定為連線池大約能服務的數量（10 到 20），這樣流量激增就不會再超出它。Cloud Run 允許每個執行個體到 Cloud SQL 有 100 個連線，所以 10 仍在範圍內。

6

我很高興服務已經穩定，從那時起一直正常運作 :slight_smile:

7

謝謝！我會用這種方式調整 CloudRun。
不過，讓我擔心的是——這是突然發生的，實例已經運行 6 個月了，到目前為止一直沒有任何問題。

8

pg-pool 獲取超時告訴你，在截止時間前沒有可用的客戶端。這並不證明連線池太小。因為這在六個月穩定運行後才發生一次，擴大連線池可能只會將壓力轉向 Cloud SQL。

將受影響的版本與 Cloud SQL 連線圖以及該時間戳的 Cloud Run 啟動日誌對齊。如果現有連線都在忙碌而請求在佇列中，更大的連線池或更低的容器並行性是合理的。如果新連線在超時，連線池大小就不是根本原因。

每次只更改一個限制，並記錄以前的值。否則下一次事件將無法告訴你哪個更改有幫助。