Rake:rebake stürzt mit Fehlern ab: PG::ConnectionBad: PQsocket

[j127]

Ich habe ein Forum mit 200.000 Beiträgen auf einen neuen Server migriert. Die Live-Seite wurde in den schreibgeschützten Modus versetzt, um Ausfallzeiten zu vermeiden.

Ich habe das Backup auf einer anderen Subdomain wiederhergestellt, damit die Benutzer die Installationsbildschirme oder Probleme, die während der Wiederherstellung auftreten könnten, nicht sehen – so etwas wie dev.example.com.

Sobald die Wiederherstellung abgeschlossen war, habe ich die DNS-Einträge auf den neuen Server umgeleitet und die Domain in der Datei app.yml auf die normale forum.example.com geändert.

Dann zeigten alle Smileys in den Basisbeiträgen auf den Server dev.example.com, also habe ich rake:rebake ausgeführt.

Es verarbeitet etwa 1.000-2.000 Beiträge, bevor es mit Fehlern bezüglich der Datenbankverbindung abstürzt.

Hier sind ein paar Auszüge:

/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

Im Moment lade ich die Bilder, indem ich die Domain dev.example.com auf die Domain forum.example.com umleite, aber das ist nur eine vorübergehende Lösung.

Weiß jemand, wie man diesen Fehler umgehen kann, damit ich alle Beiträge neu backen kann? Verursacht dies zu viel Last auf der Datenbank?

[pfaffman (Jay Pfaffman)]

Zuerst siehe Ändern des Domainnamens oder Umbenennen Ihres Discourse (obwohl eine andere Lösung darin besteht, ein Backup zu erstellen und dann mit dem neuen Hostnamen wiederherzustellen).

Ich vermute, dass Ihnen die Verbindungen zur Datenbank ausgehen, aber das ist nicht der Fehler, den ich erwarten würde.

Ist dies eine Standardinstallation oder verwenden Sie einen anderen PG-Server?

[j127]

Vielen Dank für die Links. Es handelt sich um eine Standard-Docker-Installation auf einem DigitalOcean-Droplet („Premium AMD“, 4 GB RAM, 2 vCPUs).

Ich habe die Anweisungen in dem von Ihnen genannten Link befolgt. Ich habe einige falsche URLs in den Einstellungen gefunden, diese korrigiert und das Forum zur Sicherheit erneut neu erstellt.

Dann habe ich einen Befehl wie diesen ausgeführt:

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

Dieser Befehl stürzte mit folgender Fehlermeldung ab:

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.

Ich habe dann vorübergehend einen Beitrag gelöscht, der auf die genannte URL verwies (https://forum.example.com/t/the-slug/78946/7), den Befehl erneut ausgeführt und er funktionierte ohne Absturz.

Danach habe ich rake posts:rebake erneut ausgeführt.

Er schlug bei einigen Beiträgen wie diesem fehl, fuhr aber fort (ich habe die HTML für diese Beiträge manuell neu erstellt):

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)

Schließlich stürzte er kurz vor Erreichen von 11.000 Beiträgen mit Fehlern wie diesem ab:

/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'

Der gesamte Server schien offline zu gehen, da ich von Uptime Robot benachrichtigt wurde, dass die Seite nicht erreichbar war.

Glauben Sie, dass der Server nicht leistungsfähig genug ist, um diesen Befehl auszuführen?

Er läuft normalerweise mit über 80 % RAM und erreicht Spitzenwerte von 100 %, während der Befehl ausgeführt wird. Vielleicht ging ihm einfach der Speicher aus.

[Ed_S]

Wenn Sie eine lokale Festplatte haben, können Sie Swap hinzufügen, wodurch eine Speichererschöpfung vermieden wird (unabhängig davon, ob dies hier die Ursache des Problems ist). Was sagt Ihnen free? Sehen Sie oom oder memory in der Ausgabe von dmesg?

[j127]

@Ed_S

Was sagt free aus?

Im Moment sagt es:

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

@Ed_S

Siehst du oom oder memory in der Ausgabe von dmesg?

Ich sehe kein oom, aber das Wort memory erscheint an einigen Stellen in Bezug auf das Reservieren und Freigeben von Speicher.

Der Server wurde mit 4 GB RAM erstellt, daher hat Discourse keine Swap-Datei automatisch erstellt. Glaubst du, es lohnt sich, eine hinzuzufügen?

[Ed_S]

Wenn Sie über genügend Festplattenspeicher verfügen, lohnt es sich auf jeden Fall, z. B. 2 GB Swap hinzuzufügen.

Das andere, was Sie tun sollten, ist, die Auslastung zu überwachen, während Ihr großer Job läuft. Ich würde vmstat 5 5 verwenden und vielleicht in eine Datei protokollieren. Sie hoffen, keine großen Werte in den Spalten si oder so zu sehen, und nicht, dass die Spalte swpd nahe an die Größe Ihres Swaps gelangt.

Sehen Sie sich vielleicht diesen Beitrag an:

@Ed_S

Um zu versuchen, die Situation so nah wie möglich am Versagen zu erfassen, habe ich vmstat 5 verwendet

(Es scheint möglich, dass dem Datenbanksystem eine Ressource ausgeht, aber davon weiß ich nichts.)

[j127]

Danke, ich werde diese Dinge später heute ausprobieren. Ich habe im Moment 50 GB frei.

[j127]

Ich habe eine 2 GB große Swap-Datei hinzugefügt, und das scheint das Problem behoben zu haben. Das erneute Backen ist erst zu 20 % abgeschlossen, aber es gab bisher keinen einzigen Fehler, und die RAM-Auslastung liegt knapp unter 100 %.\n\nVielen Dank euch beiden für eure Hilfe.

[Ed_S]

Klingt gut! Nur für das Protokoll:

• Sie könnten mehr Swap hinzufügen, auch während die Aufgabe läuft, wenn vmstat oder free (oder top) zeigen, dass der Swap erschöpft ist.
• Wenn Sie vorsichtig sind, könnten Sie wahrscheinlich ein reversibles temporäres Upgrade auf eine Instanz mit mehr RAM durchführen, was ein wenig Geld kostet, aber nur für ein paar Stunden erforderlich sein sollte. Es ist wichtig, nicht zu einer Instanz mit größerer Festplatte zu wechseln, da dies nicht reversibel ist. (Mehr RAM sollte es ermöglichen, dass die Dinge mit voller Geschwindigkeit laufen, während bescheidener RAM und viel Swap eine Leistungseinbuße haben könnten und die Aufgabe länger zum Abschluss braucht.)

[j127]

@Ed_S

Du könntest wahrscheinlich ein reversibles temporäres Upgrade auf eine Instanz mit mehr RAM durchführen

Ich habe darüber nachgedacht, aber ich müsste den Server herunterfahren, und die Benutzer hatten bereits eine ärgerliche „Nur-Lese“-Periode und Ausfallzeiten, als ich die Server wechselte.

Ich konnte es gestern Abend nicht beenden, weil ich schlafen gehen musste, aber es läuft jetzt wieder. Bisher 30 % ohne Fehler.

[Ed_S]

Behalten Sie die Dinge mit vmstat oder ähnlichem im Auge – das ist ein so langwieriger Job, den möchten Sie nicht neu starten müssen. Ich würde zur Sicherheit noch weitere 2 GB Swap hinzufügen.

[j127]

Danke, ich habe gelegentlich mit vmstat nachgesehen. Ich habe es in einer tmux-Sitzung gestartet, damit ich mich abkoppeln und meinen Laptop eine Weile schließen konnte. Es hat wahrscheinlich 8-9 Stunden gedauert, bis der Befehl ausgeführt wurde, aber alles wurde ohne Fehler abgeschlossen.