Этот раздел документации посвящён директивам, специфичным для баз данных bdb (и hdb). Общие директивы раздела database описаны здесь. Berkeley DataBase (BDB или HDB) (ныне принадлежит Oracle) — некогда был предпочтительным и рекомендуемым механизмом манипуляции данными OpenLDAP (в настоящее время вытеснен механизмом mdb), требующий, однако, тщательной настройки в случае, когда приложению необходима высокая производительность. Указанные здесь параметры — только часть настроек производительности. Другие настройки могут содержаться в файле DB_CONFIG file (смотрите также главу, посвящённую производительности).
Предупреждение: Файл журнала транзакций BDB (log.xxxxxxxxxxxx в директории базы данных LDAP, определяемой директивой directory) может очень быстро и очень сильно разрастаться, и потому требует регулярного обслуживания. Описание процедур обслуживания можно найти в документации BDB, в частности, утилиты обслуживания обсуждаются в главе 25, удаление файла журнала — в главе 12.
Часть параметров данного раздела файла slapd.conf напрямую обрабатывается базой данных BDB. Такие параметры могут быть заменены соответствующими директивами файла настройки базы данных DB_CONFIG (для cn=config его расположение определяется в атрибуте olcDbConfig) и удалены из cn=config (файла slapd.conf). Видимо, разработчики OpenLDAP всё больше склоняются к использованию директив DB_CONFIG, нежели эквивалентных им атрибутов конфигурации или директив slapd.conf. Если такая замена возможна, это указывается в описании каждой конкретной директивы.
Формат:
cachesize integer
Директива cachesize определяет количество записей, которое механизм манипуляции данными LDAP будет обслуживать в памяти. Не путайте данную директиву с директивой BDB set_cachesize — они управляют различным поведением.
Для достижения максимальной производительности этот показатель должен соответствовать, либо быть максимально приближен к количеству записей, содержащихся в каталоге. Значение по умолчанию — 1000. Примеры:
cachesize 10000 # LDAP обслуживает в памяти 10,000 записей
Смотрите также главу о настройках производительности.
Формат:
checkpoint kbyte min
Директива checkpoint определяет промежуток времени между выполнением операции сброса данных в контрольной точке (checkpoint) в базе данных BDB, то есть записи данных из оперативной памяти на диск. Восстановить базу данных можно только из последней контрольной точки.
По сути, частота выполнения операции сброса данных в контрольной точке определяет промежуток времени; если за этот промежуток времени в каталог будут внесены изменения, то, в случае краха системы, их невозможно будет восстановить средствами BDB. Если dbnosync НЕ ИСПОЛЬЗУЕТСЯ, в качестве данного промежутка времени может быть установлен достаточно длительный период, скажем, 10 минут или больше; если же директива dbnosync ИСПОЛЬЗУЕТСЯ, то лучше установить его в 5 — 15 минут или менее. Параметр kbytes — количество килобайт, записанных в каталог, а параметр min — время в минутах. То значение, которое будет достигнуто первым, и определяет окончание периода между операциями сброса в контрольной точке.
По умолчанию OpenLDAP НЕ ПРОИЗВОДИТ ОПЕРАЦИЙ СБРОСА В КОНТРОЛЬНОЙ ТОЧКЕ, таким образом, нужно всегда явно указывать директиву checkpoint. Дополнительную информацию можно найти в разделе 15 главы 12 документации BDB. Данную директиву можно заменить директивой txn_checkpoint файла DB_CONFIG. Примеры:
checkpoint 128 15 # сброс данных в контрольной точке происходит либо после записи 128k данных, # либо по прошествии 15 минут, в зависимости от того, что произойдёт раньше
Формат:
dbnosync
Директива dbnosync указывает, что для базы данных НЕ требуется немедленная синхронизация при изменении какой-либо записи в памяти. Данная опция увеличивает производительность при операциях записи, но есть и недостаток: если крах системы произошёл до того, как данные на диске и в памяти синхронизировались, то часть данных может быть утеряна. Синхронизация данных между памятью и диском управляется директивой checkpoint. По умолчанию (при отсутствии данной директивы) обновление данных на диске происходит сразу же. Примеры:
dbnosync # разрешено отложенное обновление данных на диске
Данная директива аналогична опции BDB set_flag DB_TXN_NOSYNC — смотрите главу о настройках производительности.
Формат:
directory /path/to/directory
Директива directory определяет местонахождение файлов базы данных BDB. По соглашению эти файлы размещаются в /var/db/openldap-data (BSD) или /var/lib/ldap (FC/Linux), но их можно размещать в любом удобном месте. Указанная в директиве директория ДОЛЖНА существовать перед первым запуском OpenLDAP.
Если Вы не определили данную директиву, OpenLDAP по умолчанию будет использовать директорию /var/db/openldap-data (BSD) или /var/lib/ldap (FC). Если Вы указали относительное имя для директории (без '/' в начале), BDB будет подставлять в начало пути содержимое своей переменной окружения DB_HOME, которая может указывать на любую точку вселенной.
Хотя значения по умолчанию предусмотрены, документация OpenLDAP утверждает (но не настаивает), что директива directory является ОБЯЗАТЕЛЬНОЙ. Мы рекомендуем всегда указывать эту директиву хотя бы затем, чтобы не тратить время на поиски месторасположения файлов базы данных.
Если Вы собираетесь создавать или обслуживать каталог с несколькими DIT (для этого нужно несколько разделов database), целесообразно заранее продумать и создать систему именования поддиректорий для хранения файлов этих баз данных. Примеры:
directory /var/ldap/example-com # директория example-com должна существовать, на неё должны # быть назначены права на чтение и запись пользователю ldap directory example-com # в начало пути добавляется значение переменной BDB DB_HOME # и директория будет /user/local/share/openldap/example-com (BSD)
Формат:
dirtyread
Директива dirtyread позволяет OpenLDAP при поисковых запросах возвращать данные из памяти, которые могут быть ещё не записаны на диск. Если последующая операция записи на диск завершится неудачей, эти данные будут потеряны. Таким образом, пользователь может получить результаты, отличающиеся от конечного состояния каталога.
Указание данной директивы может увеличить производительность каталога, повышая риск некоторого нарушения целостности. По умолчанию (при отсутствии данной директивы) данные в памяти, еще не записанные на диск, возвращаться не будут. Примеры:
dirtyread # пользователь МОЖЕТ получить данные, которые # не соответствуют конечному состоянию каталога
Лучше определять директивы index файла slapd.conf перед первоначальной загрузкой каталога (с помощью ldapadd), тогда при первоначальной загрузке соответствующие индексы будут созданы автоматически. При внесении изменений в настройки индексов после первоначальной загрузки требуется переиндексирование (повторное создание индексов) каталога с помощью slapindex (предупреждение: перед этим slapd должен быть остановлен).
В конфигурации OLC (cn=config) используется атрибут olcDbIndex, который может присутствовать только в записи olcDatabase={Z}xxx,cn=config. Кроме того, переиндексирование происходит в режиме реального времени, то есть любые изменения данного атрибута срабатывают немедленно и индексирование изменяется (выполнять slapindex не нужно). Однако, при использовании OLC (cn=config) трудно понять, когда переиндексирование завершается (никаких видимых признаков окончания процесса нет).
Формат:
# форма OLC (cn=config) olcDbIndex: attrlist | default indices # форма slapd.conf index attrlist | default indices # indices = [pres [,approx] [,eq] [,sub] [,special]]
Атрибуты olcDbIndex (директивы index) определяют, какие индексы будут обслуживаться OpenLDAP. Может быть включено любое количество параметров индексирования. Даже если атрибут не был указан в директивах index, его всё равно можно использовать в поисковых фильтрах — если это будет происходить часто, то конечно, производительность будет страдать, а если раз в жизни — ничего страшного.
attrlist может быть единичным атрибутом, или списком атрибутов, разделённых запятыми.
Необязательный параметр default содержит те индексы, которые должны поддерживаться по умолчанию. Они применяются к атрибутам в последующих атрибутах olcDbIndex (директивах index), в которых пропущен список индексов. Атрибут olcDbIndex (директива index) со значением default должен быть определён до появления атрибутов olcDbIndex (директив index) без списка индексов. Если определено несколько атрибутов olcDbIndex (директив index) со значением default, каждая из них будет влиять на атрибуты olcDbIndex (директивы index), следующие непосредственно за ней, до появления очередного атрибута olcDbIndex (директивы index) со значением default.
Индекс pres следует использовать, если предполагается, что будут выполняться поисковые запросы в форме 'objectclass=person' или 'attribute=mail'.
Индекс approx НЕОБХОДИМО использовать, если предполагается, что будут выполняться поисковые запросы в форме 'sn~=person' (поиск 'созвучных' значений).
Индекс eq следует использовать, если предполагается, что будут выполняться поисковые запросы в форме 'sn=smith', то есть без применения поисковых шаблонов (используется только правило EQUALITY).
Индекс sub следует использовать, если предполагается, что будут выполняться поисковые запросы в форме 'sn=sm*', то есть с применением поисковых шаблонов (используется правило SUBSTR). Данный индекс можно задать более конкретно, указывая subinitial (оптимизация под 'sn=*s'), subany (оптимизация под 'sn=*n*') или subfinal (оптимизация под 'sn=th*'). Для одного атрибута можно указать несколько индексов типа sub.
Параметр special связан с подтипами (subtype) и может быть либо nolang, либо nosubtypes.
Будьте очень внимательны при выборе того, какие индексы будут поддерживаться каталогом. Лучше делать это на основании требований приложений; если их не учитывать, это может серьёзно повлиять на производительность каталога. И наоборот, нет никакого смысла индексировать те атрибуты, поиск по которым никогда не осуществляется. Если в поисковых запросах используются только правила EQUALITY, нет смысла устанавливать индексирование sub. Индексы потребляют память (чем больше индексов, тем больше они занимают оперативную память). Кроме того, операции записи и модификации при большом количестве индексов будут выполняться дольше, поскольку требуется время и ресурсы на обновление индексов.
Примеры:
# Простое использование значения default # форма OLC (cn=config) olcDbIndex: default pres,eq olcDbIndex: cn,sn,uid # форма slapd.conf index default pres,eq index cn,sn,uid # Определяем индексы наличия и соответствия # для атрибутов cn, sn и uid # две приведённые выше директивы index выполняют # абсолютно то же, что и три, приведённые ниже index cn pres,eq index sn pres,eq index uid pres,eq index cn eq,sub,subinitial # Создаём индексы для атрибута cn (commonname) # для поисков EQUALITY, SUBSTR, а также дальнейшая оптимизация # для поисков типа sc=a* index sn eq,approx,sub # Создаём индексы для атрибута sn (surname) # для поисков EQUALITY и SUBSTR # Примечание: Индекс approx index - пустая трата времени, # поскольку для sn не определено правило ORDERING, # требуемое для поисков approx. Приводится лишь для # иллюстрации возможности использования index mail pres,eq,sub # Создаём индексы для атрибута mail on # для поисков на наличие, EQUALITY и SUBSTR index objectclass eq # Оптимизируем поиски по форме objectclass=person
Обзор других настроек производительности можно найти в соответствующей главе.
Считается устаревшей в пользу параметра set_lk_detect файла DB_CONFIG.
Формат:
mode mask
Директива mode определяет права на файлы, назначаемые при первоначальном создании файлов базы данных BDB. Значение по умолчанию — 0600 (чтение и запись разрешены только пользователю ldap, остальным доступ запрещён). Примеры:
mode 0660 # пользователь ldap - чтение и запись # группа ldap - чтение и запись # остальные - нет доступа
Формат:
searchstack depth
Директива searchstack определяет глубину (depth) стека, используемого для оценки поискового фильтра. Оценка поисковых фильтров происходит по стеку, в который помещаются вложенные условия AND / OR. Для каждого потока сервера выделяется собственный стек. Глубина стека определяет, насколько комплексные фильтры могут быть оценены без необходимости выделения дополнительной памяти.
Применение поискового фильтра с глубиной вложенности большей, чем глубина поискового стека, приведёт к тому, что для этой конкретной операции поиска будет выделен отдельный стек. Таким образом, если количество вложенных условий превышает указанное значение (или значение по умолчанию), происходит значительное падение производительности.
Каждый поисковый стек использует 512Kb для одного вложенного уровня условий. Глубина стека по умолчанию — 16, то есть используется 8MB памяти для каждого потока. Примеры:
searchstack 5 # позволяет размещать в стек до 5-ти вложенных инструкций поиска
Ответ на вопрос, стоит или нет использовать файл DB_CONFIG, прост: если Вы заботитесь о производительности — используйте его, если не заботитесь — забудьте о нём. ОДНАКО, если Вы решили не использовать DB_CONFIG, то Вы ДОЛЖНЫ определить директиву checkpoint в файле slapd.conf. Разработчики OpenLDAP всё чаще советуют использовать DB_CONFIG вместо определения аналогичных директив в slapd.conf.
Файл DB_CONFIG располагается в директории, указанной в директиве directory. Используемые в этом файле директивы полностью описаны в руководстве по BDB. Можно заменить директивы checkpoint, lockdetect, dbnosync файла slapd.conf эквивалентными директивами файла DB_CONFIG, а также добавить дополнительные директивы настройки производительности по мере необходимости.
Пример файла DB_CONFIG:
# замена директивы lockdetect set_lk_detect DB_LOCK_EXPIRE # ЛИБО set lk_detect DB_LOCK_DEFAULT # раскомментируйте, если требуется dbnosync # set_flags DB_TXN_NOSYNC # разрешено использовать несколько директив set_flags # устанавливает максимальный размер журнала в 5Mb (по умолчанию для BDB - 10Mb) set_lg_max 5242880 set_cachesize 0 5242880 1 # устанавливает кэш базы данных в 5Mb # разрешается фрагментация # НЕ заменяет директиву cachesize в slapd.conf # это параметр базы данных txn_checkpoint 128 15 0 # замена директивы checkpoint в slap.conf # сброс в контрольной точке при записи 128K или каждые 15 минут # 0 говорит о том, что если не было операций записи, то обновлений не производится
Примечание:
cd /to/bdb/directory db_stats -m # ИЛИ на BSD db4_stat -m
Следующие фрагменты раздела database иллюстрируют настройку базы данных BDB. Цель оптимизации производительности не ставится.
Пример 1 — файл DB_CONFIG не используется:
database bdb ... # только фрагмент раздела database # порядок директив не важен cachesize 10000 checkpoint 128 15 directory /var/ldap/first-dit dbnosync dirtyread index mail pres,eq index objectclass pres index default eq,sub index sn eq,sub,subinitial index telephonenumber index cn searchstack 5
Та же конфигурация с использованием файла DB_CONFIG:
Фрагмент slapd.conf:
database bdb ... # только фрагмент раздела database # порядок директив не важен cachesize 10000 directory /var/ldap/first-dit dirtyread index mail pres,eq index objectclass pres index default eq,sub index sn eq,sub,subinitial index telephonenumber index cn searchstack 5
Файл DB_CONFIG:
Файл DB_CONFIG располагается в директории, указанной в директиве directory. Используемые в этом файле директивы полностью описаны в руководстве по BDB. Можно заменить директивы checkpoint, lockdetect, dbnosync файла slapd.conf эквивалентными директивами файла DB_CONFIG, а также добавить дополнительные директивы настройки производительности по мере необходимости.
set lk_detect DB_LOCK_DEFAULT set_flags DB_TXN_NOSYNC set_lg_max 5242880 set_cachesize 0 5242880 1 txn_checkpoint 128 15 0
Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.
Нашли ошибку в переводе? Сообщите переводчикам!
Copyright © 1994-2017 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 21 апреля 2016 г.
Переведено участниками проекта Pro-LDAP.ru в 2012-2017 г.