Endlos laufende Postgres-Prozesse & schlechte Leistung nach Neuinstallation/Wiederherstellung

Unterstützung
1

Um unser Forum zu aktualisieren, habe ich am Wochenende eine Neuinstallation von VPS + Wiederherstellung durchgeführt.

Dies sollte mehrere Probleme für uns lösen:

  • Veraltetes Ubuntu erneuern
  • Discourse aktualisieren
  • Upgrade auf Postgres 15

Obwohl im Allgemeinen alles gut lief, traten danach Probleme mit Postgres-Prozessen auf, die 100 % eines Kerns beanspruchten. Die Anzahl der Prozesse variierte jedoch. Ich habe ein paar Dinge ausprobiert, von einem Rebuild bis hin zu Neustarts. Derzeit versuche ich einen rake db:validate_indexes, der bereits seit einigen Stunden ohne Rückmeldung läuft. Ich bin mir nicht sicher, ob ich das schon einmal gemacht habe und ob es schneller gehen sollte.

Die Nutzung des Forums funktioniert im Grunde gut, ist aber definitiv langsamer geworden. Einige länger laufende Aufgaben, wie das Aufrufen von Benutzerprofilen von aktiveren Benutzern, dauern merklich länger als üblich.

Ich bin mir ziemlich sicher, dass es einige Probleme mit der Datenbank gibt, aber ich habe Schwierigkeiten herauszufinden, welche.

Ich muss sagen, unsere Datenbank ist ziemlich riesig – wir sind nach der Wiederherstellung und nach der Indexerstellung bei etwa 150 GB. Bei der Überwachung des Wiederherstellungsprozesses habe ich keine Fehler gesehen und die Indexerstellung verlief meiner Meinung nach reibungslos.

Screenshot 2025-02-17 @ 10.46.20@2x
Screenshot 2025-02-17 @ 10.46.20@2x1690×638 209 KB

Gibt es eine Idee, wie man das angehen kann? Es sind derzeit 3 Postgres-Prozesse – es waren 6 vor einem Neustart, den ich vor ein paar Stunden durchgeführt habe – ich habe auch gesehen, dass alle 16 Kerne nach der Wiederherstellung ausgelastet waren.

EDIT: Ich habe gerade bemerkt, dass 3 Sidekiq-Prozesse mit „Indizierung von Kategorien für die Suche“ beschäftigt sind. Könnte dies alles nur die Neuerstellung des Suchindex sein? Wenn ja, kann dies anders gelöst werden? Wenn wir die Live-Systemwiederherstellung durchführen, wird dies ein großes Problem sein, wenn die Leistung über mehrere Stunden oder sogar Tage hinweg so stark beeinträchtigt wird.

2

Derzeit läuft nur ein Sidekiq-Task mit „Jobs::BackfillBadge“, aber immer noch blockieren 7 Postgres-Prozesse ständig 100 % CPU. Ich bin wirklich neugierig, was da los ist.

Screenshot 2025-02-17 @ 14.59.12@2x
Screenshot 2025-02-17 @ 14.59.12@2x1920×804 197 KB

3

Nach solchen Umzügen ist es eine gute Idee, einen vacuum für die Datenbankstatistiken auszuführen.

1 „Gefällt mir“
4

Wie viel RAM und CPU hast du?

Wie viel Speicher gibst du PostgreSQL?

5

Der Testserver hat 32 GB RAM, 16 Kerne, die Konfiguration ist auf 64 MB Arbeitsspeicher eingestellt.

EDIT: Gemeinsame Puffer sind bei 8 GB

Ich führe gerade ein VACUUM durch, das festzustecken scheint

Screenshot 2025-02-17 @ 17.00.32@2x
Screenshot 2025-02-17 @ 17.00.32@2x1110×204 26.5 KB

Ich bin mir nicht sicher, ob es etwas tut, aber es ist schon seit über 30 Minuten da.

Ich habe das Forum auf schreibgeschützt gesetzt und die VM neu gestartet, um die 7 Postgres-Prozesse zu beenden, die dort vorher „festgesteckt“ waren. Kurz nach dem Neustart waren 2 dieser Postgres-Prozesse wieder da und haben sich nicht verändert. Derzeit läuft nichts in Sidekiq.

6

Sie wollen wirklich keinen vollständigen VACUUM ausführen. Alles, was Sie brauchen, um die Leistung wiederherzustellen, ist ein VACUUM VERBOSE ANALYZE. Sie können kein FULL auf einer laufenden Website ausführen.

1 „Gefällt mir“
7

Ich bin kein Experte für riesige Datenbanken, aber ich würde die Puffer zwei- oder dreimal so groß machen.

Ich bin sicher, Sie haben Indizes, die 8 GB groß sind.

8

:thinking: Postgres empfiehlt, shared_buffers nie über 40 % des internen Speichers einzustellen?

Das gesagt,

Ihr Server könnte unterdimensioniert sein.

2 „Gefällt mir“
9

Aha! Vernünftiger Rat von einem Experten! Dann lag ich vielleicht richtig, dass 8 GB/25 % nicht ausreichen, und obwohl 16 GB mehr als 40 % sind, könnte es trotzdem ein guter Vorschlag sein, weil …

1 „Gefällt mir“
10

Leute. Wie gesagt, dies ist ein Testserver – es gibt keinen Traffic darauf. Dieser Server ist definitiv nicht gut genug für den Produktionseinsatz, aber das ist hier nicht das Problem. Die Frage ist, warum wir Postgres-Prozesse sehen, die so hängen (mit 100 % CPU-Auslastung) und die Dinge drastisch verlangsamen. Wir haben den Testserver bis vor ein paar Tagen sogar mit geringerer Kapazität betrieben – er wurde nur wegen des fehlenden Festplattenspeichers für ein Restore hochskaliert.

Die Produktionsmaschine läuft mit 128 GB RAM mit den gleichen Shared Buffer-Einstellungen ohne Probleme – daher glaube ich nicht, dass es ein allgemeines Problem mit diesen Einstellungen und der Shared Buffer-Größe gibt – schon gar nicht auf einem privaten Testrechner ohne Traffic.

Aber egal – ich werde das Restore einfach wiederholen und sehen, ob vielleicht etwas schief gelaufen ist, da es anscheinend keine gute Erklärung für das Verhalten gibt.