LINUX.ORG.RU

Да, в 10-100 раз быстрее по записи: OpenLDAP + LMDB

 , , , ,


2

2

Комрады, речь о готовом рецепте увеличения производительности по записи для OpenLDAP (когда LMDB используется как бакенд хранения) и для самой «Lightning Memory-Mapped Database» (http://symas.com/mdb/). Не хотелось-бы углубляться в сравнения, но LMDB один из немногих вариантов позволяющий обслужить под миллион read-запросов и порядка 1-100К write-запросов (с этими правками).

Никаких чудес и бесплатного сыра, платить приходиться более редкой фиксацией данных на диске, либо ставить «RAID с батарейкой» (теперь в этом есть смысл). Грубо говоря, на диске фиксируется не каждая транзакция, а как настроите (периодически или по объему изменений). Если же будет write-back кэш «с батарейкой», то ускорение будет и при фиксации каждой транзакции.

Чтобы это работало пришлось допилить LMDB и немного OpenLDAP (aka slapd):

  • правка багов для консистентности периодических чекпоинтов.
  • LIFO-реклайминг (90% правок).
  • прочие мелочи, включая замену «минут» на «секунды» в чекпоинтах.

Из slapd.conf рецепт выглядит например так:

backend mdb
envflags writemap nosync lifo
checkpoint 0 1
Что в переводе: сквозная запись (которая теперь без глюков), сразу ничего не записывать, делать чекпоинты каждую секунду (БД консистентна на диске).

Фишка LIFO-реклайминга в гораздо большей вероятности записи одних и тех же секторов на диске, что дает возможность объединять такие операции если фиксируется не каждая транзакция или есть «RAID с батарейкой». В результате write perfomance действительно растет в обещанные 10-100 раз.

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

Всё сделанное заслано в http://www.openldap.org/its/index.cgi/Incoming?id=7958, от того и пишу. Мой интерес протолкнуть это в mainstream, чтобы не поддерживать патчи локально. А у Symas Corp видимо сомнения проистекающие из стиля кодирования LMDB. Грубо говоря, и так не всегда понятно как оно работает, а теперь еще веселее (к гусарам просьба - не предлагать переписать LMDB).

Короче, если у кого есть интерес отпишите челобитную по последнему урлу, авось поможет.

p.s. Дабы не уличили в замалчивании: некую первую версию lifo-патча сделал dmitrii.fonariuk@gmail.com, я повторил с «чистого листа» поскольку были баги и в местах контакта код LMDB существенно изменился.


А как по той ссылке содержимое ревизий посмотреть?

Sorcerer ★★★★★ ()

А чего на gitorious.org с merge request'ом не зальешь?

ebantrop ()

Поправочка

«Некую первую» версию lifo-патча сделал Алексей Петров, а не Дмитрий Фонарюк.

ly ()
Ответ на: комментарий от EnterpriseMobility

Re: LMDB сосет, LevelDB рулит?

- Все относительно.

На наших нагрузках живет только приличный in-memory. Например тарантул, если по копии на каждом ядре. Но LMDB тут выигрывает неблокируемыми читателями, т.е. по записи «как тарантул», про чтению множим на кол-во ядер.

Плюс LMDB уже приклеена к OpenLDAP, а level-db и тарантул нет...

ly ()

с товарищчем Howard Chu доводилось уже общаться?

ЗЫ круто

mos ★★☆☆☆ ()
Ответ на: комментарий от mos

Re: с товарищчем Howard Chu доводилось уже общаться?

Господин скрипач думает, а пока думает нужно его аккуратно потроллить общественным мнением...

ly ()
Ответ на: комментарий от mos

Re: тот китайский горец из калифорнии за словом в карман не лазет, судя по мэйл листам

Да-да, он такой, этот неуловимый джо ;)

Мои любимые, почти хиты:
- ответы/пояснения почему в mdb не нужен volatile.
- пояснения «head_room /= head_id» (бабушек поделили на номер автобусы).

ly ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.