Wie man pg_dump weniger ressourcengierig macht

Ich habe cron so konfiguriert, dass pg_dump täglich nach folgender Regel aufgerufen wird:

# xyz database backups:
00 01 * * * root umask 077 && pg_dump --user=xyz_system xyz | gzip > /var/xyz/backup/db/xyz/`date -u +\%Y\%m\%dT\%H\%M\%S`.gz

Grundsätzlich funktioniert es. Die Datenbank wächst relativ schnell und exponentiell (der Exponent ist jedoch nicht sehr groß). Derzeit benötigt der komprimierte Speicherauszug etwa 160 MB. Wenn die Datenbank gesichert wird, beginnt das System zu crawlen. Der Lastdurchschnitt, den ich mit dem topBefehl gesehen habe, war ungefähr 200, 200, 180. Grundsätzlich reagiert der Server kaum.

Die erste Frage ist, wie festgestellt werden kann, wo der Engpass liegt. Wird die schlechte Leistung durch schwere E / A-Vorgänge verursacht? Wird es durch Probleme beim Sperren von Tabellen verursacht? Vielleicht ist es ein Speicherproblem? Die Ausgabe des pg_dumpBefehls wird an den gzipBefehl weitergeleitet. Ist es sequentiell, dh der gesamte Speicherauszug wird im Speicher abgelegt (Austauschproblem?) Und dann komprimiert oder gleichzeitig (dh gzip komprimiert das, was es erhält, und wartet auf mehr)? Kann es durch einen anderen Faktor verursacht werden?

Die zweite Frage ist, wie der Dumpingvorgang für die Hauptfunktionen des Systems weniger aufdringlich gemacht werden kann. Soweit ich weiß, kann der Speicherauszug aufgrund der Datenbankintegrität nicht zu lange dauern. Es gibt Tabellenschreibsperren usw. Was kann ich tun, um die Probleme zu begrenzen (oder zu verzögern, wenn man das Datenbankwachstum berücksichtigt)?

Die dritte Frage : Ist es bereits Zeit, sich über erweiterte Datenbankkonfigurationen zu informieren? Das System funktioniert einwandfrei, wenn keine Datenbanksicherungen durchgeführt werden, aber möglicherweise ist das Problem mit dem Datenbankspeicherauszug ein erstes Symptom für eingehende Probleme?

Beeindruckend. Erstaunliche Anzahl von Fragen. Ich werde versuchen, einige anzusprechen, aber diese Antwort ist noch nicht vollständig.

wie man feststellt, wo der Engpass ist.

Verwenden Sie topzuerst, um zu sehen, was während des Dumps los ist. Überprüfen Sie die CPU-Auslastung des Prozesses und den Prozessstatus. Dbedeutet "Warten auf E / A".

Wird die schlechte Leistung durch schwere E / A-Vorgänge verursacht?

Ja, höchstwahrscheinlich.

Wird es durch Probleme beim Sperren von Tabellen verursacht?

Könnte sein. Sie können die pg_stat_activitySystemansicht verwenden , um zu sehen, was während des Dumps in Postgres vor sich geht.

Vielleicht ist es ein Speicherproblem?

Sehr unwahrscheinlich.

Die Ausgabe des Befehls pg_dump wird an den Befehl gzip weitergeleitet. Ist es sequentiell, dh der gesamte Speicherauszug wird im Speicher abgelegt (Austauschproblem?)

Nein. Gzip ist ein Blockkompressor, der im Stream-Modus arbeitet. Er speichert nicht alle Eingaben im Speicher.

und dann komprimiert oder gleichzeitig (dh gzip komprimiert, was es bekommt und wartet auf mehr)?

Ja, es komprimiert Block für Block, gibt aus und wartet auf mehr.

Kann es durch einen anderen Faktor verursacht werden?

Ja.

Soweit ich weiß, kann der Speicherauszug aufgrund der Datenbankintegrität nicht zu lange dauern. Es gibt Tabellenschreibsperren usw. Was kann ich tun, um die Probleme zu begrenzen (oder zu verzögern, wenn man das Datenbankwachstum berücksichtigt)?

Die Speicherauszugsdauer hat keinen Einfluss auf die Speicherauszugsintegrität. Die Integrität wird durch die Verwendung einer Transaktion mit wiederholbarer Leseisolationsstufe für alle pg_dump-Prozesse sichergestellt. Es gibt KEINE Tabellenschreibsperren.

Ist es bereits an der Zeit, sich über erweiterte Datenbankkonfigurationen zu informieren? Das System funktioniert einwandfrei, wenn keine Datenbanksicherungen durchgeführt werden, aber möglicherweise ist das Problem mit dem Datenbankspeicherauszug ein erstes Symptom für eingehende Probleme?

Niemals zu spät. Beginnen Sie mit http://wiki.postgresql.org/wiki/Performance_Optimization .

Ich empfehle Ihnen, sich die kontinuierliche Archivierung von postgresql anzuschauen. Hier sind die Vorteile gegenüber der Verwendung von pg_dump:

1. Sie müssen nicht jedes Mal eine vollständige Sicherung durchführen. Zu Beginn reicht eine vollständige Sicherung aus, es wird jedoch empfohlen, beispielsweise alle paar Tage eine vollständige Sicherung durchzuführen.
2. Sehr viel schneller wiederherzustellen, wenn die Datenbank größer wird.
3. Die Fähigkeit zur Wiederherstellung an einem anderen Punkt (Point-In-Time-Wiederherstellung).
4. Sie führen jede Stunde eine inkrementelle Sicherung durch (ca. 30 Minuten). Dies kann konfiguriert werden und hängt auch von der Aktualisierungsaktivität ab.

Es gibt jedoch einige Nachteile (die in den meisten Fällen kein Problem darstellen können):

1. Normalerweise wird mehr Speicherplatz benötigt, da es sich um binäre Sicherungen handelt. Der DB-Ordner kann komprimiert werden.
2. Sie können sie nicht auf einer anderen Architektur (Binärdaten) wiederherstellen.