Bsddb3 DB.get / put зависает с транзакцией
Я новичок в Berkeley DB, и я пытаюсь использовать его в Python с bsddb3 с транзакциями для обеспечения энергобезопасности. С DB_AUTO_COMMIT и без чтения и записи аргументов транзакции работают нормально. Но в тот момент, когда я вызываю get / put с ручной транзакцией, вызов зависает на неопределенное время, практически не используя CPU (около 50 000 циклов в секунду) и не выполняя дискового ввода-вывода.
_data_store_env.log_set_config(bdb.DB_LOG_AUTO_REMOVE, True)
_data_store_env.set_lg_max(256 * 2**20)
_data_store_env.set_cachesize(0, 512 * 2**20)
_data_store_env.set_lg_dir(str(_journal_path))
_data_store_env.set_tmp_dir(str(tmp_dir))
_data_store_env.open(str(_bulk_data_path), bdb.DB_CREATE | bdb.DB_INIT_LOCK | bdb.DB_INIT_LOG | bdb.DB_INIT_MPOOL | bdb.DB_INIT_TXN | bdb.DB_RECOVER | bdb.DB_THREAD)
# Originally I simply used DB_AUTO_COMMIT, but I changed it to see if this way would fix the hang. It didn't.
txn = _data_store_env.txn_begin()
_data_store = bdb.DB(_data_store_env)
_data_store.set_flags(bdb.DB_CHKSUM)
_data_store.set_pagesize(65536)
_data_store.open("filestore.db", None, bdb.DB_HASH, bdb.DB_CREATE | bdb.DB_THREAD, 0x660, txn)
_idx_store = bdb.DB(_data_store_env)
_idx_store.set_flags(bdb.DB_CHKSUM | bdb.DB_DUPSORT)
_idx_store.open("idxstore.db", None, bdb.DB_HASH, bdb.DB_CREATE | bdb.DB_THREAD, 0x660, txn)
_data_store.associate(_idx_store, lambda key, data: key[0:9], bdb.DB_IMMUTABLE_KEY, txn)
txn.commit()
...
# It doesn't matter whether this flag is present or not. Both produce the same result.
txn = _data_store_env.txn_begin(None, bdb.DB_TXN_BULK)
...
# Never returns
file_exists = _idx_store.has_key(entry_key, txn)
...
# Also never returns
_data_store.put(file_hash, file_data, txn)
Я делаю что-то неправильно? Транзакции вообще работают в bsddb3?
Ответы 1
Я считаю, что после нескольких часов отладки с помощью отладчика машинного кода я довольно близко подошел к первопричине. Похоже, что зависание происходит не при вызове get / put, а после него - при вызове len на объекте базы данных, выполняемом графическим интерфейсом отладчика после завершения вызова get / put (а также периодически, если программа запущена бесплатно). Это, по-видимому, застревает в цикле получения ресурсов, который никогда не завершается, потому что транзакция выполняется (у меня нет символов для сборки bsddb3 - которая статически связана с BDB, не меньше - поэтому я не заинтересован в тратить время выяснить, что это за дюжина или около того функций в стеке вызовов под вызовом DB_length). Вероятно, это также связано с тем фактом, что время отклика на любые команды отладчика увеличилось примерно до 5 секунд (когда он не заблокирован), когда я ввел bsddb3 в проект.
Таким образом, это выглядит токсичным взаимодействием между графическим интерфейсом отладчика, пытающимся поддерживать свое окно переменных в актуальном состоянии, и дизайнерским решением о том, что базы данных bsddb3 должны быть сопоставлены. Я очень открыт для предложений, как обойти это; Я пробовал несколько вещей, но не смог понять, как удалить метод len из объектов БД (это свойство только для чтения, поскольку оно реализовано на C). Прямо сейчас я создаю оболочку вокруг БД, которая НЕ является последовательностью; это решает проблему, если вы случайно не наведете курсор мыши на объект БД и отладчик не попытается получить его свойства.