GCP: timeout de conexão Postgres durante inicialização do n8n no Cloud Run (socket Unix do Cloud SQL)

Perguntas
1

Descrição
Observamos um incidente de inicialização único no n8n no Google Cloud Run com PostgreSQL no Cloud SQL (conexão via Unix socket).

Ambiente

  • Versão do n8n: 2.32.5
  • Runtime: Google Cloud Run (Gen2)
  • Região: europe-west3
  • Banco de dados: PostgreSQL no Cloud SQL
  • Método de conexão: Unix socket em /cloudsql

O que aconteceu

  • Durante uma janela de inicialização, o n8n registrou repetidamente:
    • Error: timeout exceeded when trying to connect
    • rastreamentos de pilha apontando para caminhos de aquisição de conexão em pg-pool, @n8n/typeorm e @n8n/db.
  • Nessa mesma janela:
    • o endpoint raiz conseguiu retornar 200
    • algumas chamadas de API retornaram 500 / alta latência
    • tarefas em segundo plano dependentes de BD reportaram falhas
  • Um redeploy manual foi realizado.
  • Pouco após o redeploy, o serviço se estabilizou e vem funcionando normalmente desde então.
2

Oi @rgrzesk, enquanto você aguarda uma resposta, aqui estão algumas coisas que podem ajudar:

Recursos sugeridos

Correspondência automática com sua pergunta.

Documentação:

Fórum:

@Mayank1024, @Websensepro, @tamy.santos - vocês já ajudaram em problemas semelhantes antes, dão uma olhada?

Sugerido automaticamente pelo bot da comunidade n8n. É um piloto — compartilhe seu feedback aqui.

3

Oi @rgrzesk Parece que você está apenas reportando um bug, certo? Sua instância está tudo bem agora?

4

@rgrzesk

Parece mais um relatório de incidente para mim.
Talvez você gostaria de relatar o problema com seu provedor

5

Oi @rgrzesk
„timeout exceeded when trying to connect

6

Fico feliz que o serviço se estabilizou e vem funcionando normalmente desde então :slight_smile:

7

Obrigado! Vou ajustar o CloudRun dessa forma.
Porém, o que me preocupa é que aconteceu de repente e a instância está rodando há 6 meses, funcionando sem problemas até agora.

8

Um timeout de aquisição do pg-pool indica que nenhum cliente ficou disponível antes do prazo. Isso não prova que o pool era muito pequeno. Como isso aconteceu uma vez após seis meses estáveis, aumentar o pool pode apenas transferir a pressão para o Cloud SQL.

Alinhe a revisão afetada com o gráfico de conexão do Cloud SQL e o log de inicialização do Cloud Run para esse timestamp. Se ambas as conexões existentes estavam ocupadas enquanto as requisições ficavam na fila, um pool maior ou concorrência de container menor é razoável. Se novas conexões estavam expirando, o tamanho do pool não é a causa raiz.

Altere um limite por vez e mantenha o valor anterior registrado. Caso contrário, o próximo incidente não dirá qual mudança ajudou.