Rake:rebake plante avec des erreurs : PG::ConnectionBad : PQsocket

J’ai migré un forum de 200 000 messages vers un nouveau serveur. Le site en production a été mis en mode lecture seule afin d’éviter toute interruption de service.

J’ai restauré la sauvegarde sur un sous-domaine différent pour que les utilisateurs ne voient pas les écrans d’installation ou les problèmes potentiels lors de la restauration, quelque chose comme dev.example.com.

Dès que la restauration a été terminée, j’ai pointé le DNS vers le nouveau serveur et j’ai modifié le domaine dans le fichier app.yml pour qu’il pointe vers le domaine normal forum.example.com.

Ensuite, tous les smileys dans les messages de base pointaient vers le serveur dev.example.com, j’ai donc exécuté rake:rebake.

Il traite environ 1 000 à 2 000 messages avant de planter avec des erreurs de connexion à la base de données.

Voici quelques extraits :

/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/cli.rb:34:in `dispatch'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/cli.rb:28:in `start'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/exe/bundle:45:in `block in <top (required)>'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
/usr/local/lib/ruby/gems/3.2.0/gems/bundler-2.4.4/exe/bundle:33:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
     1999 / 200968 (  1.0%)
Failed to rebake (topic_id: 78730, post_id: 210607)
PG::ConnectionBad: PQsocket() can't get socket descriptor
/var/www/discourse/lib/tasks/posts.rake:108:in `rebake_posts_all_sites'
/var/www/discourse/lib/tasks/posts.rake:7:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'

Caused by:
PG::ConnectionBad: PQsocket() can't get socket descriptor

Pour le moment, je fais charger les images en redirigeant le domaine dev.example.com vers le domaine forum.example.com, mais c’est une solution temporaire.

Quelqu’un sait comment surmonter cette erreur pour que je puisse ré-analyser tous les messages ? Est-ce que cela crée trop de charge sur la base de données ?

1 « J'aime »

Tout d’abord, consultez Changer le nom de domaine ou renommer votre Discourse (bien qu’une autre solution consiste à sauvegarder puis restaurer avec le nouveau nom d’hôte).

Je suppose que vous manquez de connexions à la base de données, mais ce n’est pas l’erreur à laquelle je m’attendrais.

S’agit-il d’une installation standard ou utilisez-vous un autre serveur PG ?

1 « J'aime »

Merci pour les liens. Il s’agit d’une installation Docker standard sur un droplet DigitalOcean (« Premium AMD », 4 Go de RAM, 2 vCPUs).

J’ai suivi les instructions du lien que vous avez mentionné. J’ai trouvé des URL incorrectes dans les paramètres, je les ai donc corrigées et j’ai reconstruit le forum à nouveau pour être sûr.

Ensuite, j’ai exécuté cette commande :

discourse remap dev.example.com forum.example.com

Cette commande a planté avec ce type d’erreur :

Error: ERROR:  duplicate key value violates unique constraint "unique_post_links"
DETAIL:  Key (topic_id, post_id, url)=(78821, 207117, https://forum.example.com/t/the-slug/78946/7) already exists.

J’ai donc temporairement supprimé un message qui faisait référence à l’URL mentionnée (https://forum.example.com/t/the-slug/78946/7), j’ai réexécuté la commande, et elle a fonctionné sans planter.

Ensuite, j’ai refait rake posts:rebake.

Elle a échoué sur quelques messages comme celui-ci, mais a continué (j’ai reconstruit manuellement le HTML de ces messages) :

Rebaking post markdown for 'default'
     2273 / 200996 (  1.1%)
Failed to rebake (topic_id: 66586, post_id: 210353)
JavaScript was terminated (either by timeout or explicitly)

Finalement, elle a planté juste avant d’atteindre 11 000 messages avec des erreurs comme celle-ci :

/usr/local/bin/bundle:25:in `<main>'
    10996 / 200996 (  5.5%)
Failed to rebake (topic_id: 76678, post_id: 200988)
PG::ConnectionBad: PQsocket() can't get socket descriptor
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:69:in `exec_params'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rack-mini-profiler-3.0.0/lib/patches/db/pg.rb:69:in `exec_params'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/activerecord-7.0.4.1/lib/active_record/connection_adapters/postgresql_adapter.rb:768:in `block (2 levels) in exec_no_cache'

Le serveur entier a semblé tomber en panne car j’ai été alerté par Uptime Robot que le site était hors ligne.

Pensez-vous que le serveur n’est pas assez puissant pour exécuter cette commande ? :thinking:

Il fonctionne normalement à plus de 80 % de RAM, et atteint 100 % pendant l’exécution de la commande. Il a peut-être simplement manqué de mémoire.

Si vous avez un disque local, vous pouvez ajouter un espace d’échange (swap), ce qui éviterait l’épuisement de la mémoire (que ce soit la cause du problème ici ou non). Que vous dit la commande free ? Voyez-vous oom ou memory dans la sortie de dmesg ?

1 « J'aime »

Pour le moment, il indique :

              total        used        free      shared  buff/cache   available
Mem:           3,8Go       2,1Go       160Mo       1,0Go       1,6Go       488Mo
Swap:             0B          0B          0B

Je ne vois pas oom, mais le mot memory apparaît à quelques endroits concernant la réservation et la libération de mémoire.

Le serveur a été créé avec 4 Go de RAM, donc Discourse n’a pas créé automatiquement de fichier d’échange. Pensez-vous que cela vaille la peine d’en ajouter un ?

Si vous avez l’espace disque, cela vaut certainement la peine d’ajouter, disons, 2 Go de swap.

L’autre chose à faire est de surveiller l’utilisation pendant que votre gros travail s’exécute. J’utiliserais vmstat 5 5 et peut-être enregistrerais dans un fichier. Vous espérez ne pas voir de grandes valeurs dans les colonnes si ou so, et ne pas voir la colonne swpd s’approcher de la taille de votre swap.

Peut-être voir ce post :

(Il semble possible que le système de base de données manque de certaines ressources, mais je n’en sais rien.)

1 « J'aime »

Merci, j’essaierai ces choses plus tard aujourd’hui. J’ai 50 Go de libre pour le moment.

J’ai ajouté un fichier swap de 2 Go, et cela semble avoir résolu le problème. Le re-cuisson n’est qu’à 20 %, mais il n’y a pas eu une seule erreur, et l’utilisation de la RAM est juste en dessous de 100 %.\n\nMerci à vous deux pour votre aide.

2 « J'aime »

Très bien ! Juste pour information

  • vous pourriez ajouter plus de swap, même pendant que la tâche s’exécute, si vmstat ou free (ou top) montrent que le swap s’épuise.
  • si vous faites attention, vous pourriez probablement faire une mise à niveau temporaire et réversible vers une instance avec plus de RAM, ce qui coûtera un peu d’argent, mais ne devra être en place que pendant quelques heures. Il est important de ne pas passer à une instance avec un disque plus grand car ce n’est pas réversible. (Plus de RAM devrait permettre aux choses de fonctionner à pleine vitesse, tandis que peu de RAM et beaucoup de swap pourraient entraîner une pénalité de performance, et la tâche prendra plus de temps à se terminer.)
2 « J'aime »

J’y ai pensé, mais j’ai dû arrêter le serveur, et les utilisateurs ont déjà eu une période “lecture seule” et des temps d’arrêt agaçants lorsque j’ai déplacé les serveurs. :sweat:

Je n’ai pas pu le terminer hier soir parce que j’ai dû aller dormir, mais il fonctionne à nouveau maintenant. 30% jusqu’à présent sans aucune erreur.

1 « J'aime »

Surveillez les choses avec vmstat ou un outil similaire. Il s’agit d’un travail de longue durée, vous ne voudrez pas avoir à le redémarrer. J’ajouterais probablement 2 Go supplémentaires de swap, par mesure de sécurité.

1 « J'aime »

Merci, j’ai vérifié avec vmstat de temps en temps. Je l’ai lancé dans une session tmux pour pouvoir me détacher et fermer mon ordinateur portable pendant un moment. La commande a probablement pris 8 à 9 heures pour s’exécuter, mais tout s’est terminé sans erreur.

2 « J'aime »

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