502 Bad Gateway après la mise à jour vers la dernière version

Soutien
1

Après la mise à jour vers la dernière version de Discourse, nous avons un problème étrange avec ngix qui affiche une erreur 502.

Certains utilisateurs obtiennent une erreur 502 lors de la publication, d’autres non. Certains profils obtiennent une erreur 502, d’autres non.

L’utilisation du processeur est d’environ 10 à 25 %, l’utilisation de la RAM est également d’environ 20 %.

J’ai essayé de désactiver nos 5 plugins, même résultat.

Quels journaux dois-je consulter pour savoir ce qui produit ces erreurs 502 ?

3

En regardant dans I /var/log/nginx/error.log, j’ai apparemment beaucoup de ces messages de manière aléatoire, ce qui produit le 502, je suppose.

Est-ce juste un problème de délai d’attente ou autre chose ?

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/"
4

Quelle était la version précédente la mise à jour ?

5

Très vieux, comme un an ou plus. Y a-t-il un journal quelque part où je peux voir de quoi j’ai mis à jour ?

6

Je reçois également certains de ces messages

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

Cela semble aléatoire, soudainement tout est rapide et je peux à nouveau publier, puis cela ralentit et des erreurs 502 commencent à apparaître à nouveau.

7

Regardons à l’intérieur du journal postgres/current

2025-04-29 18:48:24.709 UTC [1746] discourse@discourse LOG :  durée : 606789,911 ms  exécution <sans nom> : SELECT COUNT(*) FROM "posts" WHERE "posts"."deleted_at" IS NULL

durée : 606789,911 ms

Nous avons beaucoup de publications, peu d’utilisateurs… pourquoi cela utilise-t-il 600 000 ms sur cette requête ?

8

S’agit-il de problèmes d’indexation ou similaires qui ralentissent les requêtes ?

9

J’ai sélectionné la table discourse dans postgres et j’ai exécuté un REINDEX DATABASE discourse ; dans l’espoir que cela accélère les choses.

Je suppose que cela prendra très longtemps.

10

Avez-vous suivi les conseils de la mise à jour PostgreSQL 15 ? Vous pourriez également effectuer un VACUUM de la base de données.

11

Je ne l’ai pas fait, j’ai bien le dossier postgres_data_old (quoique dans un répertoire différent de celui mentionné dans ce post).

Mais ensuite, le post précise ;

“Si vous avez une configuration avec un conteneur de données dédié”, ce qui, je suppose, signifie que PostgreSQL fonctionne dans un conteneur Docker dédié ?

Les nôtres fonctionnent dans la même instance que le forum. Je ne suis donc pas sûr de comment avancer à partir de là, il ne semble pas y avoir de clause “si ce n’est pas le cas”.

La présence du dossier signifie-t-elle que la conversion s’est bien déroulée ou pas ?

12

Vous pouvez vérifier la version de Postgres à /var/discourse/shared/standalone/postgres_data/PG_VERSION – Si vous avez effectué une mise à niveau via la ligne de commande, il est possible qu’elle ait été effectuée et que vous ne l’ayez pas remarqué (mais vous auriez dû lancer le rebuild deux fois). Si vous avez mis à niveau depuis l’interface web, vous devriez probablement procéder à un rebuild en ligne de commande si votre OS et Docker sont des versions récentes.

13

La version est 15.

Il semble que les choses vont beaucoup mieux après avoir exécuté la commande vacuum.

La publication fonctionne bien et semble rapide, mais lorsque l’administrateur essaie de cliquer sur les profils des utilisateurs, d’accéder à leurs profils, cela renvoie toujours une erreur 502, un délai d’attente semble-t-il ?

Y a-t-il quelque chose que je puisse faire pour accélérer cette partie de la base de données ?

14

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