502 Bad Gateway após atualizar para a versão mais recente

Após atualizar para a versão mais recente do Discourse, temos um problema estranho com o nginx postando o erro 502.

Alguns usuários recebem o Erro 502 ao postar, outros não. Alguns perfis recebem 502, outros não.

O uso de CPU está em torno de 10 a 25%, o uso de RAM também está em cerca de 20%.

Tentei desativar nossos 5 plugins, mesmo resultado.

Em quais logs devo procurar para descobrir o que está produzindo esses erros 502?

Ao olhar em I /var/log/nginx/error.log, parece que recebo aleatoriamente muitos desses, o que produz o 502, presumo.

É apenas um timeout ou o quê?

2025/04/29 18:11:50 [error] 617#617: *419 upstream prematurely closed connection while reading response header from upstream, client: <IP>, server: _, request: "POST /posts HTTP/2.0", upstream: "http://127.0.0.1:3000/posts", host: "forum.domain.com", referrer: "https://forum.domain.com/"

Qual era a versão anterior à atualização?

Muito antigo, como um ano ou mais. Existe algum registro que eu possa ver de qual versão fiz o upgrade?

Também estou recebendo alguns destes

*2 connect() failed (111: Connection refused) while connecting to upstream,
...
upstream: "http://127.0.0.1:3000/message-bus/92fd28cbf742...

Parece aleatório, de repente tudo fica rápido e eu consigo postar novamente, e então fica lento e os 502 começam a aparecer novamente.

Olhando dentro do log do postgres/current

2025-04-29 18:48:24.709 UTC [1746] discourse@discourse LOG:  duração: 606789.911 ms  execute unnamed: SELECT COUNT(*) FROM "posts" WHERE "posts"."deleted_at" IS NULL

duração: 606789.911 ms

Temos muitas postagens, poucos usuários… por que está usando 600 mil ms nisso?

Pode ser problemas com indexação ou algo do tipo, que deixam as consultas lentas?

Selecionei a tabela de discourse no postgres e executei um REINDEX DATABASE discourse; na esperança de que isso tornasse as coisas mais rápidas.

Suponho que levará muito tempo.

Você seguiu o conselho em Atualização do PostgreSQL 15? Você também pode executar o comando VACUUM no banco de dados.

Eu não fiz isso, eu tenho a pasta postgres_data_old (embora em um diretório diferente daquele do post).

Mas então o post continua dizendo;

“Se você estiver executando uma configuração com um container de dados dedicado”, o que eu suponho que significa que o Postgres está sendo executado em um container Docker dedicado?

Nosso caso, roda na mesma instância do fórum. Então, não sei como avançar a partir daí, parece que não há uma cláusula de “se não”?

A presença da pasta significa que a conversão foi bem-sucedida ou algo assim?

Você pode verificar a versão do Postgres em /var/discourse/shared/standalone/postgres_data/PG_VERSION – Se você fez uma atualização via linha de comando, é possível que ela tenha sido concluída e você não tenha percebido (mas seria necessário executar a reconstrução duas vezes). Se você atualizou através da interface web, provavelmente deve proceder com uma reconstrução via linha de comando, se seu sistema operacional e Docker estiverem atualizados.

A versão é 15.

Parece que as coisas melhoraram muito depois que executei o comando vacuum.

A postagem funciona bem e parece ser rápida, mas quando o administrador tenta clicar em perfis de usuário, entrar em seus perfis, ainda dá 502, parece um timeout?

Existe algo que eu possa fazer para acelerar essa parte do banco de dados?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.