BerkeleyDB Concurrency - PullRequest
Новая
       21

BerkeleyDB Concurrency

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

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

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

Ответы [ 5 ]

13 голосов
/ 03 августа 2008

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

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

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

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

7 голосов
/ 14 октября 2008

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

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

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

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

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

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

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

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

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

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

4 голосов
/ 02 августа 2008

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

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

2 голосов
/ 16 сентября 2008

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

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

2 голосов
/ 04 августа 2008

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

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

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

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

...