GCP: tiempo de espera agotado en conexión Postgres durante inicio de n8n en Cloud Run (socket Unix de Cloud SQL)

Preguntas
1

Descripción
Observamos un incidente de inicio único en n8n en Google Cloud Run con PostgreSQL en Cloud SQL (conexión de socket Unix).

Entorno

  • Versión de n8n: 2.32.5
  • Entorno de ejecución: Google Cloud Run (Gen2)
  • Región: europe-west3
  • Base de datos: PostgreSQL en Cloud SQL
  • Método de conexión: Socket Unix bajo /cloudsql

Qué sucedió

  • Durante una ventana de inicio, n8n registró repetidamente:
    • Error: timeout exceeded when trying to connect
    • trazas de pila apuntando a rutas de adquisición de conexión en pg-pool, @n8n/typeorm y @n8n/db.
  • En esa misma ventana:
    • el punto de entrada raíz podía devolver 200
    • algunas llamadas a API devolvieron 500 / alta latencia
    • las tareas en segundo plano dependientes de la BD reportaron fallos
  • Se realizó un redeploy manual.
  • Poco después del redeploy, el servicio se estabilizó y ha funcionado normalmente desde entonces.
2

Hola @rgrzesk, mientras esperas una respuesta, aquí hay algunas cosas que podrían ayudarte:

Recursos sugeridos

Coincidencia automática con tu pregunta.

Documentación:

Foro:

@Mayank1024, @Websensepro, @tamy.santos - ya han ayudado con problemas similares antes, ¿pueden echar un vistazo?

Sugerido automáticamente por el bot de la comunidad de n8n. Es un proyecto piloto - comparte tu opinión aquí.

3

Hola @rgrzesk Parece que solo estás reportando un error, ¿verdad? ¿Tu instancia está bien ahora?

4

@rgrzesk

Me parece más bien un informe de incidente.
Quizás te gustaría plantear el problema a tu proveedor

5

Hola @rgrzesk
„timeout exceeded when trying to connect

6

Me alegra que el servicio se estabilizó y ha funcionado normalmente desde entonces :slight_smile:

7

¡Gracias! Voy a ajustar CloudRun de esta manera.
Sin embargo, lo que me preocupa es que sucedió de repente y la instancia lleva 6 meses activa, funcionando sin problemas hasta ahora.

8

Un timeout de adquisición de pg-pool te indica que ningún cliente estuvo disponible antes del plazo. No prueba que el grupo sea demasiado pequeño. Debido a que esto sucedió una sola vez después de seis meses estables, aumentar el grupo solo puede trasladar la presión a Cloud SQL.

Alinea la revisión afectada con el gráfico de conexión de Cloud SQL y el registro de inicio de Cloud Run para esa marca de tiempo. Si ambas conexiones existentes estaban ocupadas mientras las solicitudes estaban en cola, un grupo más grande o una concurrencia de contenedor más baja es razonable. Si las conexiones nuevas se agotaban por timeout, el tamaño del grupo no es la causa raíz.

Cambia un límite a la vez y mantén registrado el valor anterior. De lo contrario, el siguiente incidente no te dirá qué cambio ayudó.