pg_dump out of memory

Hallo,

ich habe ein Problem bei einem Backup mit pg_dump.

Bei der Sicherung einer Datenbank im Custom Format bekomme ich einen “out of memory” Fehler.
Im Log steht nur “unerwartetes EOF auf Client-Verbindung mit einer offenen Transaktion”. Ich finde in
den Messages keinen Hinweis darauf, das der oom Killer zugeschlagen hätte.

Sichere ich die Datenbank im nicht Custom Format läuft es problemlos durch. Da ich auf 30 Servern ca. 160 Datenbanken
Scriptgesteuert sichere möchte ich nicht Ausnahmen vom normalen Verfahren, das ja sonst auch überall klappt, programmieren wenn es einen anderen Weg gibt.

Ich nutze für diese Datenbank Postgres 9.3.5. Ein Update auf eine andere Version ist nicht ohne weiteres möglich,
da diverse Anwendungen dahinter hängen.

Die betroffene Datenbank ist 10GB gross, der Rechner läuft unter SLES, 64bit, die Maschine hat (wie alle anderen) 32 GB Speicher.

Gruß

robomobil

Erhöhe mal max_locks_per_transaction, evtl. kann das helfen. Du solltest auch die aktuelle 9.3 installieren, das sind NUR Bugfixes, da ändert sich nix in der API. Wenn Du das mit der aktuellen Minor-Release auch bekommst wären weitere Details interessant.

Bei 30 Servern etc.: was hast Du für Anforderungen an die Verfügbarkeit der Backups? Bei einem täglichen Dump gehen Dir u.U. 23 Stunden, 59 Minuten 59 Sekunden produktiver Arbeit flöten. Wie groß sind die Datenbanken? Logische Dumps via pg_dump(all) sind ab einem bestimmten Punkt keine sinnvollen Backups mehr. Und ja: sicherst Du auch die globalen Objekte?

Das mit den max_locks_per_transaction (aktuell default eingestellt) probiere ich mal aus wenn ich den Postgres neu starten kann. Und die 9.3.16 zu installieren sollte auch möglich sein.

Zu Erläuterung des Dumps: Die normale Sicherung ist eine inkrementelle File System Sicherung mit WAL Archivierung, dazu noch Snapshots vom OS. Den pg_dump machen wir nur, da wir immer wieder Probleme mit defekten Pages haben und die frühzeitig erkennen müssen. Ich will da nicht auf eine Meldung im Logfile warten.

Haben wir, aber im Log kommt die Meldung nur, wenn auf den defekten Bereich einer Tabelle zugegriffen wird. Das kann u.U. Wochen nach dem Fehler sein und ich muss das einfach früher erfahren.

Moin,

ich habe jetzt die max_locks_per_transaction vom default 64 auf 256 gesetzt und nach Restart der DB einen Dump gemacht. Leider mit dem gleichen Ergebnis. Können höhere Werte 1024 oder mehr da etwas bringen?

Die Meldung “Speicher aufgebraucht” kommt übrigens nach “pg_dump: sichere Datenbankdefinition”, wahrscheinlich (?) beim ersten Copy Out der Tabellen.

Wie hoch ist denn work_mem eingestellt? Vielleicht hilft es ja das zu erhöhen?

Work_men steht auf default (1MB). Aber greift das überhaupt beim Dump? Laut Handbuch: Specifies the amount of memory to be used by internal sort operations and hash tables before writing to temporary disk files.

Ich probiers einfach mal aus.

Nope, wenn ich den auf 32MB setzte gehts es auch nicht.

Aktualisiere erst einmal auf die aktuelle version, prüfe auch, daß die Version von pg_dump aktuell ist. Hat die Tabelle, die das auslöst, Besonderheiten wie z.B. sehr große Felder? Ich kann mich dunkel an einen unserer Kunden mal erinnern, wo wohl durch Charset-Probleme (wandlung von charset A nach charset B) TEXT oder BYTEA-Felder so groß wurden, daß da ein Buffer überlief. Das wurde dann aber gefixt in einer späteren Minor-Version.

Mit der aktuellsten Veriosn 9.3.16 bekomme ich den gleichen Fehler. Bei welcher Tabelle das schiefgeht, kann ich nicht sagen, der Fehler kommt wie beschrieben unmittelbar nach “sichere Datenbankdefinition”. Es ist beim Abbruch auch noch keine Datei geschrieben, es muss also bei der ersten Tabelle geschehen, die der dump anpackt.

Tabellen mit BYTEA Felder sind in dieser Datenbank, in anderen auf dem Server aber auch. %-|

Ist es vielelicht doch der oom_killer? Hab in keinem Log was gefunden, da muss ich mal die OS Truppe im Haus befragen.

Danke, das probiere ich am Montag mal aus.

Das Statement bei dem der Dump abgebrochen wird ist:

SELECT
‘/appserver/postgresql//XXXX//data/base/’||(SELECT datid FROM pg_stat_database WHERE datname=‘xxxx’)||’/’||relfilenode||’|’||substring(string_agg(’(’||schemaname::text||’).’||tablename::text,’, ') from 1 for 256)
FROM pg_catalog.pg_class
INNER JOIN
pg_catalog.pg_tables ON (tablename = relname)
WHERE
relfilenode != 0
GROUP BY relfilenode
ORDER BY relfilenode DESC;

Das kann ich so ohne Probleme in psql ausführen. Hmmm? Da komme ich immer noch ncith weiter.

Langsam lichtet sich das Dunkel. Schuld sind weder der OOM-Killer noch die Postgres Version. Sondern eine selbstgeschriebene (nicht von mir) Extension. Warum das ein Problem ist muss ich noch raukriegen, aber wenn ich die Extension rausschmeisse läuft der Dump ohne Probleme durch.

Aus der Produktion kann ich die leider nicht entfernen, da die Sachen gebraucht werden.

Danke für die Info, gut zu wissen.