Wie berechnet man die Dauer für eine BerkeleyDB-Dump-/Ladeoperation für eine gegebene BDB-Datei?

Question

Ich verwende eine Drittanbieteranwendung, die BerkeleyDB für den lokalen Datenspeicher (BMC Discovery) verwendet. Im Laufe der Zeit werden seine BDB-Dateien fragmentiert und lächerlich groß, und BMC Software schrieb ein kompaktes Dienstprogramm, das im Grunde db_dump in db_load mit einem neuen Dateinamen piped und dann die ursprüngliche Datei durch die neu erstellte Datei ersetzt.

Die Zeit, die für große Dateien benötigt wird, ist wahnsinnig lang und kann Stunden dauern, während andere für die gleiche Größe die Hälfte dieser Zeit benötigen. Es scheint wirklich von der Ebene der Fragmentierung in der Datei und/oder Art der Daten zu abhängen (ich nehme an?).

Das bereitgestellte Dienstprogramm verwendet eine grobe Methode, um die Dauer basierend auf der Gesamtgröße des Datenspeichers (der aus mehreren BDB-Dateien besteht) zu aktivieren. Ex. wenn größer als 1G sagt "wird ein paar Stunden dauern" und wenn größer als 100G sagt "wird viele Stunden dauern". Dies hilft überhaupt nicht.

Ich frage mich, ob es einen besseren, präziseren Weg geben würde, mit den mit BerkeleyDB.6.0 (auf Red Hat) bereitgestellten Befehlen die Dauer einer db_dump/db_load-Operation für eine bestimmte BDB-Datei zu schätzen.

Hinweis: Auch wenn diese Frage eine bestimmte Anwendung von Drittanbietern erwähnt, ist es nur, um Sie in den Kontext zu setzen. Die Frage bezieht sich auf BerkelyDB.

Answer 1

db_dump/db_load sind die üblichen (portablen) Möglichkeiten zur Defragmentierung.

Neuere BDB (wie letzte 4-5 Jahre, sicherlich db-6.x) hat einen db_hotbackup (8) Befehl, der schneller sein könnte, indem Hex-Konvertierungen vermieden werden.

(Lösungen unten würde erfordern, benutzerdefinierte Codierung)

Es gibt auch eine DB-> compact (3) nennen das „gegebenenfalls nicht verwendeten Btree, Hash oder Recno Datenbankseiten auf die zugrunde liegende Dateisystem zurückgibt.“. Dies wird wahrscheinlich zu einer dünnen Datei führen, die lächerlich groß erscheint (mit "ls-l"), aber tatsächlich nur die Blöcke verwendet, die zum Speichern der Daten notwendig sind.

Schließlich gibt es db_upgrade (8)/db_verify (8), die beide mit DB-> set_feedback (3) angepasst werden können, um einen Callback (d. H. Einen Fortschrittsbalken) für lange Operationen auszuführen.

Vor allem würde ich Konfiguration mit db_tuner (8) und db_stat (8) überprüfen, und ein wenig über Tuning-Parameter in DB_CONFIG denken.