HD-Sättigung aufgrund der verspäteten Erstellung von PostgreSQL-Dateien

[Sophie]

Guten Morgen,
Zuallererst die besten Wünsche für das neue Jahr.

Seit Montag, im Anschluss an einen 15-tägigen Feiertag, ist unser Wapt-Server abgestürzt und hat die Festplatte mit PostgreSQL-Dateien in /var/lib/postgresql/9.6/main/base/16385/ überflutet
Die Dateien erreichen eine Größe von 1048576 KB, bis die Festplatte voll ist.

Nachfolgend die Konfiguration unseres virtuellen Servers:

• Wapt Version 1.7.4.6165

• Betriebssystem Debian 4.9

• 4 GB RAM

• 40 GB Festplatte

Wir haben etwa 1800 Maschinen in unserem Bestand.

Beim Start der Konsole wird folgende Fehlermeldung angezeigt:
Fehler beim Abrufen der Hostliste: Serverfehler:
OperationalError('Verbindung zum Server konnte nicht hergestellt werden: Datei oder Verzeichnis nicht gefunden\n\tls Der Server läuft lokal und akzeptiert\n\tVerbindungen über den Unix-Domain-Socket "/var/run/postgresql/.s.PGSQL.5432."?\n',)

Nachfolgend das Ergebnis waptserver-Dienststatus
waptserver.service - WAPT Server Startskript
Geladen: geladen (/usr/lib/systemd/system/waptserver.service; aktiviert; Standardeinstellung des Anbieters: aktiviert)
Aktiv: aktiv (wird ausgeführt) seit Di. 2020-01-07 12:17:02 CET; Vor 8 Stunden
Haupt-PID: 664 (python)
Aufgaben: 1 (Limit: 4915)
CGroup: /system.slice/waptserver.service
└─664 /opt/wapt/bin/python /opt/wapt/waptserver/server.py

07. Jan. 20:40:36 srv-wapt15 python[664]: conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
07. Jan. 20:40:36 srv-wapt15 python[664]: OperationalError: Verbindung zum Server konnte nicht hergestellt werden: Datei oder Verzeichnis nicht gefunden
07. Jan. 20:40:36 srv-wapt15 python[664]: Läuft der Server lokal und akzeptiert er Anfragen?
07. Jan. 20:40:36 srv-wapt15 python[664]: Verbindungen über Unix-Domain-Socket "/var/run/postgresql/.s.PGSQL.5432"?
07. Jan. 20:40:36 srv-wapt15 python[664]: , Instanz: 07.
Jan. 20:40:36 srv-wapt15 python[664]: 2020-01-07 20:40:36,449 KRITISCH SocketIO-Pong-Fehler für UUID 4C4C4544-004B-3710-8059-B1C04F4D3632 und SID b270e
07. Jan. 20:40:36 srv-wapt15 python[664]: Datei "/opt/wapt/waptserver/server_socketio.py", Zeile 278, in on_wapt_pong
07. Jan. 20:40:36 srv-wapt15 python[664]: with wapt_db.atomic() as trans:
Jan 07 20:40:36 srv-wapt15 python[664]: File "/opt/wapt/lib/python2.7/site-packages/peewee.py", line 3533, in __enter__
Jan 07 20:40:36 srv-wapt15 python[664]: return self._helper.__enter__()

Das Wiederherstellen des vorherigen Zustands dieser VM löst das Problem nicht: Nach wenigen Minuten tritt das Phänomen erneut auf.

Irgendwelche Ideen?
Vielen Dank für Ihr Feedback

[dcardon]

Hallo Sophie,

Zuallererst die besten Wünsche für das neue Jahr.

Seit Montag, im Anschluss an einen 15-tägigen Feiertag, ist unser Wapt-Server abgestürzt und hat die Festplatte mit PostgreSQL-Dateien in /var/lib/postgresql/9.6/main/base/16385/ überflutet
Die Dateien erreichen eine Größe von 1048576 KB, bis die Festplatte voll ist.

Nachfolgend die Konfiguration unseres virtuellen Servers:

• Wapt Version 1.7.4.6165

• Betriebssystem Debian 4.9

• 4 GB RAM

• 40 GB Festplatte

Wir haben etwa 1800 Maschinen in unserem Bestand.

Beim Start der Konsole wird folgende Fehlermeldung angezeigt:
Fehler beim Abrufen der Hostliste: Serverfehler:
OperationalError('Verbindung zum Server konnte nicht hergestellt werden: Datei oder Verzeichnis nicht gefunden\n\tls Der Server läuft lokal und akzeptiert\n\tVerbindungen über den Unix-Domain-Socket "/var/run/postgresql/.s.PGSQL.5432."?\n',)

Es scheint, dass die Größe der JSON-Inventare (lokale WMI-Abfragen + dmidecode auf lokalen Rechnern) deutlich zugenommen hat und die PostgreSQL-Datenbank VACUUM-Aufrufe nicht schnell genug verarbeitet. Sehen Sie in Ihren Protokollen Meldungen wie die unten stehenden?

Code: Alle auswählen

ERROR: canceling autovacuum task CONTEXT: automatic vacuum of table "segmentation.pg_toast.pg_toast_237738400" LOG: checkpoints are occurring too frequently (8 seconds apart) HINT: Consider increasing the configuration parameter "max_wal_size

Sie können etwas Speicherplatz auf dem Rechner freigeben, damit Postgres neu gestartet werden kann (allerdings nicht der WAPT-Dienst zunächst), und anschließend ein VACUUM FULL auf der Wapt-Datenbank durchführen, um zu überprüfen, ob dadurch Speicherplatz freigegeben wird.

Code: Alle auswählen

df -h 
systemctl stop waptserver
rm quelques_fichiers_inutiles_pour_recupere_un_peu_despace
systemctl restart postgresql
sudo -u postgres psql wapt -c "VACUUM FULL"
df -h

Das löst das Problem zwar nicht, bestätigt aber zumindest, dass es tatsächlich daran liegt. Wir haben einen Kunden mit einem ähnlichen Problem und arbeiten derzeit mit ihm an der Fehlersuche. Vermutlich hat ein kürzliches Windows-Update etwas an den WMI-Anfragen geändert.

Aufrichtig,

Denis

[dcardon]

Hallo nochmal,

nur zur Information: Haben Sie zufällig ein Audit-Paket, das regelmäßig WAPT.register() auslöst?

Viele Grüße,

Denis

[stephaneB]

Hallo,
vielen Dank für Ihre Antwort (ich bin ein Kollege von Sophie, die diesen Thread gestartet hat).

Wir haben tatsächlich PostgreSQL-Logs wie diesen:
„Checkpoints werden zu häufig ausgeführt
(alle 25 Sekunden)
... Erwägen Sie, den Parameter 'max_wal_size' zu erhöhen.“

Die VACUUM-Funktion hat den Speicherplatz freigegeben und die Dienste neu gestartet.

Wäre es in der Zwischenzeit sinnvoll, einen Cronjob für PostgreSQL VACUUM einzurichten?

Bezüglich eines möglichen Pakets mit einer wapt.register()-Funktion: Ich glaube nicht, dass es dafür geeignet ist, werde es mir aber ansehen.

[dcardon]

Hallo StephaneB,

Hallo,
vielen Dank für die Antwort (ich bin ein Kollege von Sophie, die diesen Thread gestartet hat).

Wir haben tatsächlich PostgreSQL-Logs wie diesen:
„Checkpoints werden zu häufig ausgeführt
(alle 25 Sekunden)
... Erwägen Sie, den Parameter 'max_wal_size' zu erhöhen.“

Die Vacuum-Funktion hat es uns ermöglicht, Speicherplatz freizugeben und die Dienste neu zu starten.

Wäre es in der Zwischenzeit sinnvoll, einen PostgreSQL-Vacuum-Cronjob einzuplanen?

Bezüglich eines möglichen Pakets mit einer wapt.register()-Funktion: Ich glaube nicht, aber ich werde es mir ansehen.

Das von uns identifizierte ähnliche Problem hängt mit einer übermäßigen Anzahl vollständiger Inventaraktualisierungen zusammen (etwa 100 bis 150 pro Sekunde). Die Datenbank hat nicht genügend Zeit, ihre Kerndateien zu bereinigen (AUTOVACUUM). Um Speicherplatz freizugeben, ist ein vollständiges VACUUM erforderlich, das die Tabelle sperrt (und somit andere Verbindungen blockiert, um die Bereinigung abzuschließen). Normalerweise sollte die exklusive Sperre nicht länger als einige Sekunden dauern. Während dieser Zeit können jedoch keine Schreibvorgänge in die Tabelle erfolgen.

Während Sie darauf warten, die Ursache für die unnötigen vollen Lagerbestände zu finden, können Sie einen Cronjob mit VACUUM FULL einrichten.

Aufrichtig,

Denis

Anmerkung: Genauer gesagt, tritt das VACUUM-Problem nicht bei der Hosts-Tabelle selbst auf, sondern bei der entsprechenden TOAST-Tabelle, die die bjson- und TEXT-Blobs speichert.

[dcardon]

Okay, im anderen Fall liegt die übermäßige Anzahl an Inventaraktualisierungen an einem Paket mit einer Steuerdatei, die einen falschen Wert für den Parameter `forced_install_on` enthält. Haben Sie diesen Parameter in Ihrer Steuerdatei verwendet?

[Sophie]

Okay, im anderen Fall liegt die übermäßige Anzahl an Inventaraktualisierungen an einem Paket mit einer Steuerdatei, die einen falschen Wert für den Parameter „forced_install_on“ enthält. Haben Sie diesen Parameter in Ihrer Steuerdatei verwendet?

Guten Morgen,
Nein, wir nutzen diese Einstellung nie, da wir noch nicht genau wissen, wofür sie gedacht ist.

[stephaneB]

Hallo, anscheinend hat noch niemand den Parameter „forced_install_on“ in unseren Paketverwaltungsdateien verwendet. Bei rund 200 Paketen wäre die Überprüfung jedes einzelnen sehr aufwendig. Gibt es eine Möglichkeit, ihn schnell zu finden, beispielsweise durch eine Abfrage? (Ein grep im Paketverzeichnis brachte erwartungsgemäß keinen Erfolg.)
Ich habe die zuletzt geänderten Pakete (innerhalb des letzten Monats) bearbeitet und keinen Wert für diesen Parameter gefunden. (Einige Pakete erwähnen ihn nicht; bei den meisten ist er als wertlos aufgeführt.)

[dcardon]

Hallo stephaneB,

das Problem liegt nicht unbedingt an dem fraglichen Parameter. Es liegt vielmehr daran, dass die lokale Abhängigkeitsberechnung aus irgendeinem Grund fehlerhaft arbeitet und das Inventar neu startet, um die Paketfilterparameter zu überprüfen. Die Schleife von `update-status` verursacht dann das von Ihnen beschriebene Problem.

Sie müssten die betroffenen Rechner finden (suchen Sie nach Rechnern, deren letzte Verbindung immer innerhalb der letzten Minuten stattfand) und den Dienst anschließend lokal im Debug-Modus neu starten. Alternativ könnten Sie alle Pakete vom betroffenen Rechner entfernen und sie einzeln wieder hinzufügen, um das problematische Paket zu finden. Sobald Sie das Paket gefunden haben, können Sie die Kontrolldatei in diesem Thread posten, um die Ursache des Problems zu ermitteln.

Viele Grüße,

Denis

[vCardon]

Hallo, anscheinend hat noch niemand den Parameter "forced_install_on" in unseren Paketverwaltungsdateien verwendet. Bei rund 200 Paketen ist es sehr mühsam, sie einzeln zu überprüfen. Gibt es eine Möglichkeit, ihn schnell zu finden, z. B. durch eine Abfrage? (Ein grep im Paketverzeichnis bringt erwartungsgemäß nichts.)
Ich habe die zuletzt im letzten Monat geänderten Pakete bearbeitet und keinen Wert für diesen Parameter gefunden. (Manche Pakete erwähnen ihn nicht, und bei den meisten ist er als wertlos aufgeführt.)

Hallo stephaneB,

Wir bieten Ihnen im Rahmen eines Supportvertrags interaktiveren telefonischen Support. Dieser ist sehr günstig, und Sie könnten möglicherweise für das Angebot der MESR Software Group und die bis Ende 2020 gültige Aktion berechtigt sein. Kontaktieren Sie uns über unsere Website https://www.tranquil.it/gerer-parc-info ... re-support falls diese Option Sie interessiert.

Aufrichtig.

Vincent