Как рассчитать продолжительность операции дампа/загрузки BerkeleyDB для данного файла BDB?

Question

Я использую стороннее приложение, которое использует BerkeleyDB для своего локального хранилища данных (называемое BMC Discovery). Со временем его фрагменты BDB и стали смехотворно большими, а BMC Software разработала компактную утилиту, которая в основном использует db_dump, подключенный к db_load с новым именем файла, а затем заменяет исходный файл на восстановленный файл.

Время, которое может потребоваться для больших файлов, безумно длинное и может занимать несколько часов, в то время как некоторые другие на тот же размер занимают половину этого времени. Кажется, что это действительно зависит от уровня фрагментации в файле и/или типа данных в нем (я предполагаю?).

Приведенная утилита использует грубый метод для согласования продолжительности, основанной на общем размере хранилища данных (который состоит из нескольких файлов BDB). Ex. если более 1G говорят, что «займет несколько часов», и если более 100G скажут «займет много часов». Это совсем не помогает.

Мне интересно, если бы был лучший, более точный способ, используя команды, предоставленные BerkeleyDB.6.0 (в Red Hat), для оценки продолжительности операции db_dump/db_load для конкретного файла BDB?

Примечание. Несмотря на то, что в этом вопросе упоминается конкретное стороннее приложение, вам просто нужно поставить вас в контекст. Вопрос важен для BerkelyDB.

Answer 1

db_dump/db_load - обычный (переносной) способ дефрагментации.

Новый BDB (как и последние 4-5 лет, конечно, db-6.x) имеет команду db_hotbackup (8), которая может быть быстрее, избегая шестнадцатеричных преобразований.

(решения ниже потребует пользовательского кодирования)

Существует также db-> компактный (3) вызов, что «возможно, возвращает неиспользованную ВТКЕЕ, Hash или страницы базы данных Recno в основной файловой системе.». Это, скорее всего, приведет к разреженному файлу, который будет казаться смехотворно большим (с «ls -l»), но на самом деле использует только блоки, необходимые для хранения данных.

Наконец, есть db_upgrade (8)/db_verify (8), оба из которых могут быть настроены с помощью DB-> set_feedback (3) для выполнения обратного вызова (то есть индикатор выполнения) для длительных операций.

Прежде всего, я бы проверил конфигурацию с помощью db_tuner (8) и db_stat (8) и немного подумал о настройке параметров в DB_CONFIG.