Параллелизм BerkeleyDB

  • Какой оптимальный уровень параллелизма может разумно поддерживать реализация BerkeleyDB на C++?
  • Сколько потоков я могу обработать БД, прежде чем пропускная способность начнет ухудшаться из-за конфликта за ресурсы?

Я прочитал руководство и знаю, как установить количество блокировок, шкафчиков, размер страницы базы данных и т. Д., Но мне просто нужен совет от человека, имеющего реальный опыт работы с параллелизмом BDB.

Мое приложение довольно простое, я буду выполнять операции получения и размещения записей размером около 1 КБ каждая. Без курсоров, без удаления.

Ответов (5)

Разве это не зависит от оборудования, количества потоков и прочего?

Я бы сделал простой тест и запустил его с увеличивающимся количеством ударов потоков и посмотрел, что кажется лучшим.

Это зависит от того, какое приложение вы создаете. Создайте репрезентативный тестовый сценарий и приступайте к работе. Тогда вы узнаете окончательный ответ.

Помимо вашего варианта использования, это также зависит от процессора, памяти, внешней шины, операционной системы, настроек кеша и т. Д.

Серьезно, просто проверьте свой собственный сценарий.

Если вам нужны числа (которые на самом деле могут ничего не значить в вашем сценарии):

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

Были задействованы скользящие средние и всевозможные показатели, но вывод заключался в следующем: просто адаптируйтесь к тому, как все работает в данный момент. Вы никогда не знаете, когда администраторы баз данных улучшат производительность или оборудование будет обновлено, или, возможно, возникнет другой процесс, который загрузит систему во время работы. Так что адаптируйтесь.

Да, и еще один момент: избегайте переключений процессов, если можете - группируйте вещи.


О, я должен прояснить это: все это происходило во время выполнения, а не во время разработки.

Насколько я понимаю, Samba создала tdb, чтобы разрешить "несколько одновременных писателей " для любого конкретного файла базы данных. Поэтому, если ваша рабочая нагрузка имеет несколько писателей, ваша производительность может быть плохой (например, проект Samba решил написать свою собственную систему, по-видимому, потому, что в этом случае он не был доволен производительностью Berkeley DB).

С другой стороны, если у вашей рабочей нагрузки много читателей, то вопрос в том, насколько хорошо ваша операционная система обрабатывает несколько читателей.

Я полностью согласен с точкой зрения Даана: создайте тестовую программу и убедитесь, что способ, которым она обращается к данным, максимально соответствует шаблонам, которые вы ожидаете от своего приложения. Это чрезвычайно важно для BDB, потому что разные шаблоны доступа дают очень разную пропускную способность.

Помимо этого, я обнаружил, что на пропускную способность оказывают большое влияние следующие общие факторы:

  1. Метод доступа (который в вашем случае, я думаю, BTREE).

  2. Уровень постоянства, с которым вы настроили DBD (например, в моем случае флаг среды DB_TXN_WRITE_NOSYNC улучшил производительность записи на порядок, но это поставило под угрозу постоянство)

  3. Вмещается ли рабочий набор в кеш?

  4. Количество прочтений по сравнению с Пишет.

  5. Насколько распределен ваш доступ (помните, что BTREE имеет блокировку на уровне страницы, поэтому доступ к разным страницам с разными потоками является большим преимуществом).

  6. Шаблон доступа - это означает, насколько вероятно, что потоки будут блокировать друг друга или даже заблокировать друг друга, и какова ваша политика разрешения тупиковых ситуаций (эта может быть убийственной).

  7. Аппаратное обеспечение (диск и память для кеша).

Это сводится к следующему: масштабирование решения, основанного на DBD, так, чтобы оно предлагало больший параллелизм, имеет два основных способа решения этой проблемы; либо минимизируйте количество замков в своей конструкции, либо добавьте больше оборудования.