Сколько RAM нужно для OpenLDAP

MAATRIX

OpenLDAP — не модный проект с еженедельными релизами, а каталог, который тихо держит корпоративную аутентификацию десятилетиями: он аутентифицирует Linux-машины через SSSD, отдаёт группы для VPN, служит бэкендом для Keycloak и Authentik и до сих пор стоит в основе половины Active Directory-подобных инфраструктур на *nix. Проблема в том, что документация по его RAM почти вся написана для backend BDB/HDB десятилетней давности, а с версии 2.4 по умолчанию используется MDB с совершенно другой моделью памяти. Разберём, сколько реально нужно памяти под разные объёмы каталога и как это посчитать, а не гадать.

Как OpenLDAP использует память на самом деле

Ключевой момент, который путает почти всех: у backend MDB (Lightning Memory-Mapped Database, LMDB) нет своего кеша в привычном смысле. Старый backend BDB/HDB держал кеш записей и индексов в куче процесса slapd, размер которой явно настраивался через set_cachesize в DB_CONFIG. MDB работает иначе — база данных открывается через mmap(), и «кешированием» занимается сам Linux, храня горячие страницы файла в page cache.

Практическое следствие: слишком мало выделенной RAM на сервере вы не увидите как ошибку OOM у slapd — вы увидите деградацию задержек. Пока файл базы (.mdb) целиком влезает в page cache, поиск по индексированному атрибуту укладывается в единицы миллисекунд. Как только сервер начинает вытеснять страницы каталога ради других процессов (или ради собственного диска-кеша), каждый поиск превращается в случайное чтение с диска — и это уже десятки миллисекунд вместо одной.

Сам процесс slapd при этом занимает немного: базовый RSS — 30-80 МБ на потоки, буферы соединений, TLS-контекст и структуры кеша сущностей верхнего уровня (olcDbCache, отдельный от файлового кеша слой для распарсенных объектов). Основная память, которую вы «выделяете» под OpenLDAP — это не RSS процесса slapd, а объём RAM сервера, который остаётся свободным для page cache под файл базы.

Формула: сколько RAM нужно под ваш каталог

Формула простая, но требует реальных чисел, а не «на глазок»:

RAM_под_LDAP ≈ (размер_базы_mdb + размер_индексов) × 1.3 + 300 МБ

Где 300 МБ — запас под сам процесс slapd, ОС и её собственные нужды (systemd, sshd, cron), а коэффициент 1.3 — запас на рост каталога и служебные страницы LMDB (страницы перезаписи при MVCC, свободные списки).

Чтобы узнать реальный размер базы на уже работающем сервере:

du -sh /var/lib/ldap/*.mdb
# или для точного размера "живых" данных без пустот файла:
slapcat -n 0 | wc -c   # конфигурация cn=config
slapcat -n 1 | wc -c   # основная база (dc=example,dc=com)

Если каталог ещё не создан, ориентируйтесь на размер одной записи пользователя. Типичная запись inetOrgPerson с cn, sn, uid, mail, userPassword (хеш), memberOf для 2-3 групп и парой служебных атрибутов занимает 1.5-3 КБ на диске вместе с индексами. Запись группы (posixGroup или groupOfNames) с полусотней участников — заметно больше, до 5-10 КБ, потому что список DN участников хранится целиком в атрибуте.

Практические уровни: от малого офиса до энтерпрайза

Числа в таблице — ориентир по типичной схеме атрибутов, у вас может отличаться в 1.5-2 раза в любую сторону в зависимости от того, сколько кастомных атрибутов вы храните (фото в jpegPhoto, к примеру, легко утраивает размер записи) и насколько глубоко вложены группы. Меряйте на своих данных через slapcat, а не переносите таблицу буквально.

Отдельно стоит сказать про совсем маленькие инсталляции: OpenLDAP формально стартует и на 256 МБ RAM, но с постоянным давлением на page cache со стороны других сервисов (веб-сервер, PHP-FPM, тот же Keycloak, если он на этом же сервере) даже каталог на 200 записей начинает подтормаживать под нагрузкой в пиковые минуты. Если LDAP — не единственный сервис на VPS, закладывайте память отдельно под него, а не «он же маленький, влезет в остаток».

Настройка olcDbMaxSize и почему это не про RAM

Частая ошибка новичков — путать olcDbMaxSize (максимальный размер memory-map, то есть верхний потолок, до которого может вырасти база) с реальным потреблением RAM. Это не одно и то же: MDB резервирует под mmap виртуальное адресное пространство сразу на весь maxsize, но физическую RAM (через page cache) занимает только по мере фактической записи данных.

Посмотреть и изменить текущее значение через cn=config:

ldapsearch -Y EXTERNAL -H ldapi:/// -b "olcDatabase={1}mdb,cn=config" olcDbMaxSize

Увеличить лимит (обязательно с запасом на будущий рост, задним числом расширять больнее, чем сразу выделить с запасом):

cat > /tmp/maxsize.ldif <<'EOF'
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcDbMaxSize
olcDbMaxSize: 2147483648
EOF

ldapmodify -Y EXTERNAL -H ldapi:/// -f /tmp/maxsize.ldif
systemctl restart slapd

Значение задаётся в байтах — 2147483648 это 2 ГБ. Ставьте с запасом раз в 10-20 от текущего реального размера базы: это не расходует RAM заранее, а лишь резервирует адресное пространство, зато избавляет от аварийного MDB_MAP_FULL в проде в неудобный момент. На 64-битных системах щедрость с olcDbMaxSize практически ничего не стоит.

Индексы: они увеличивают базу, но экономят память при поиске

Индексы в OpenLDAP — отдельные B+-деревья внутри того же mdb-файла, и они тоже должны попадать в page cache, чтобы поиск был быстрым. Без индекса по атрибуту, по которому идёт частый поиск (обычно uid, mail, memberOf), slapd делает полное сканирование базы (unindexed search) — а это не только медленно по CPU, но и заставляет page cache тащить в память куда больше страниц, чем нужно бы при точечном поиске по индексу.

Минимальный разумный набор индексов для каталога аутентификации:

olcDbIndex: objectClass eq
olcDbIndex: uid eq
olcDbIndex: cn,sn eq,sub
olcDbIndex: mail eq
olcDbIndex: memberOf eq
olcDbIndex: uidNumber,gidNumber eq

После добавления индексов на уже заполненный каталог нужно их перестроить:

systemctl stop slapd
slapindex -F /etc/ldap/slapd.d
chown -R openldap:openldap /var/lib/ldap
systemctl start slapd

Индексы обычно добавляют 15-30% к размеру базы — учитывайте это в формуле выше как часть «размера базы + индексов», а не отдельной строкой.

Как понять, что памяти уже не хватает

Прямого предупреждения от slapd вы не получите — нужно смотреть на систему в целом:

# Есть ли своп-активность — главный красный флаг для LDAP на MDB
free -h
vmstat 1 5

# Реальный RSS процесса slapd
ps -o pid,rss,vsz,cmd -C slapd

# Задержки самих запросов — включите access-лог с таймингами
# в slapd.conf/cn=config: olcLogLevel: stats
journalctl -u slapd -f | grep -i "SRCH\|RESULT"

Главный сигнал — не рост RSS у slapd (он и так остаётся почти постоянным), а появление своп-активности (si/so в vmstat больше нуля) или падение доли available памяти в free -h близко к нулю на сервере, где крутится LDAP. Если сервер уходит в своп даже на короткие пики — читатели каталога (SSSD-клиенты, приложения через LDAP-bind) начнут получать задержки в разы выше обычных, хотя сам slapd формально жив и отвечает на ldapsearch с localhost без проблем. Разумный размер и настройку самого свопа стоит проверить отдельно — это описано в статье про правильный размер swap для VPS.

Полезно также периодически смотреть статистику самой LMDB — она показывает, сколько «грязных» страниц и свободного места накопилось в файле без сжатия:

mdb_stat -e /var/lib/ldap

Если mapsize из olcDbMaxSize за годы работы почти исчерпан, а физический размер файла на диске сильно больше, чем показывает slapcat | wc -c — стоит сделать slapcat + slapadd в новую базу, это компактифицирует файл и освобождает накопленный «мусор» от старых транзакций.

OpenLDAP в связке с современным SSO-стеком

На практике чистый OpenLDAP сегодня редко торчит наружу как единственный слой аутентификации — чаще он работает бэкендом каталога, а перед ним стоит современный IdP с OIDC/SAML, который транслирует логины пользователей в LDAP-bind. Это добавляет требования к RAM отдельно на сам IdP: если это Keycloak — считайте JVM-heap и кеш сессий поверх памяти под LDAP, а не вместо неё; более лёгкие варианты вроде Authentik или Authelia экономнее, но тоже не бесплатны по памяти.

Если вы уже используете LDAP как источник для сетевой аутентификации (VPN, Wi-Fi через RADIUS), полезно свериться со схожим сценарием интеграции каталога в статье про аутентификацию VPN через Active Directory и NPS — логика разделения ролей «каталог отдельно, точка входа отдельно» там та же самая, просто со стороны Windows-инфраструктуры.

Разносить LDAP и IdP по разным серверам стоит уже начиная со среднего масштаба (от 5 000 записей): так пик нагрузки на JVM-heap современного IdP не давит на page cache, который держит горячие страницы каталога, и наоборот.

Частые вопросы