OpenLDAP является базой данных. Вы обращаетесь к OpenLDAP с целью выполнения запроса или задания, после чего OpenLDAP ищет данные и возвращает их вам. Чтобы этот процесс занимал как можно меньше времени, вы должны распределить ресурсы так, чтобы они использовались наиболее эффективно, например, настроить кэширование часто используемой информации и индексацию баз данных.
Оценка производительности
Прежде чем приступать к оптимизации slapd, вы должны оценить его текущую производительность. Для этого можно измерять время выполнения определенной операции в вашем приложении, пытаясь затем найти способ улучшить результат, или же можно вручную выполнить несколько запросов и оценить среднее время их выполнения. Измерять можно не только временные показатели; можно, например, попытаться уменьшить загрузку жесткого диска, если текущая конфигурация сервера LDAP приводит к большому количеству операций чтения и записи.
И в том, и в другом случае полезно произвести несколько измерений различных показателей до и после изменений конфигурации. В этом вам могут помочь следующие команды:
- vmstat – показывает статистику ввода/вывода и загрузку центрального процессора, а именно, время, затрачиваемое на выполнение процессов пользователя, и время ожидания
- iostat – показывает более подробную информацию об операциях чтения и записи на жесткий диск, а также о загрузке дискового контроллера
- ps – показывает статистику использования памяти процессом slapd (использование большого объема памяти само по себе не является чем-то плохим, но важно убедиться, что вы не используете больше ОЗУ, чем установлено в системе)
- time – команда для временной оценки различных операций командной строки
Оптимизация работы демона
Оптимизация всегда требует принятия компромиссных решений. Часто вы увеличиваете объем системных ресурсов (обычно это оперативная память или жесткие диски), выделяемый под определенный процесс, чтобы он выполнялся быстрее. Это приводит к тому, что под остальные процессы выделяется меньше ресурсов. Точно так же, если определенный процесс выполняется быстрее, он зачастую потребляет больше ресурсов, таких как циклы центрального процессора или операции чтения/записи на диск, которые при этом становятся недоступными для остальных процессов.
Необходимость находить компромиссы может существовать и на уровне приложений. Пожертвовав некоторой производительностью операций записи, вы в большинстве случаев можете довольно существенно повысить производительность операций чтения. Также вы можете повысить быстродействие вашего приложения, отключив некоторые функции безопасности, такие как ведение журналов транзакций. При этом в случае сбоя вы можете столкнуться с тем, что вам придется восстанавливать вашу базу данных из резервной копии; однако только вам предстоит решить, насколько приемлемым является этот компромисс.
Большинство людей используют базу данных Berkeley Database (BDB), которая основана на быстрой встроенной БД Sleepycat Berkeley Database, в настоящее время принадлежащей корпорации Oracle. Эта база данных не поддерживает язык запросов, а основана на поиске записей в хэш-таблицах. Оптимизация BDB может производиться в двух файлах: файл конфигурации slapd.conf и специальный файл, используемый исполняемыми модулями BDB.
Конфигурационные директивы файла slapd.conf
База данных BDB не является отдельной серверной службой, как большинство SQL-серверов, а линкуется вместе с исполняемыми файлами, которые ее используют. По существу, за некоторые аспекты работы базы данных BDB отвечает приложение, использующее ее. Все директивы, которые могут использоваться в файле slapd.conf, описаны в man-руководстве slapd-bdb(5); мы же рассмотрим только наиболее важные из них.
Так же, как и многие другие базы данных SQL, базы данных BDB записывают все изменения в журналы транзакций для обеспечения надежности, а также хранят данные в памяти для уменьшения количества операций записи на диск. Операция, которая выгружает содержимое памяти на жесткий диск и выполняет запись в журнал транзакций, называется контрольной точкой. Команда checkpoint указывает slapd, как часто нужно выполнять выгрузку данных на диск, оперируя такими параметрами, как количество килобайт данных и количество минут, прошедших с момента последней контрольной точки. Добавление строки checkpoint 128 15 в файл slapd.conf означает, что данные будут выгружаться при достижении объема в 128 килобайт или, как минимум, каждые 15 минут. По умолчанию никакие операции с контрольными точками не выполняются, что равносильно использованию команды checkpoint 0 0.
Записи, к которым происходят частые обращения, могут кэшироваться в ОЗУ для ускорения доступа к ним. По умолчанию кэшируются 1000 записей. Для изменения этого значения используйте команду cachesize с указанием количества записей. Чем больше значение параметра cachesize, тем больше вероятность того, что запись будет помещена в оперативную память, однако, при этом slapd расходует большее количество оперативной памяти. Выбор значения этого параметра зависит от того, сколько различных записей содержится в дереве каталога, а также от шаблона доступа. Убедитесь, что объема оперативной памяти достаточно для того, чтобы уместить элементы (такие как список пользователей), обращения к которым происходят наиболее часто.
Команда cachesize аналогична команде idlcachesize и определяет, сколько памяти отводится под кэширование индексов. Выбор значения этого параметра зависит от того, сколько индексов у вас определено (это будет обсуждаться позже), но разумно указывать то же самое значение, что и для параметра cachesize.
Оптимизация баз данных BDB
Как было замечено ранее, некоторые конфигурационные параметры BDB содержатся в отдельном файле, который считывается исполняемыми модулями программы и игнорируется службой slapd. Этот файл называется DB_CONFIG и расположен в той же папке, что и ваша база данных. Самым важным параметром в этом файле является параметр set_cachesize, который устанавливает размер внутреннего кэша BDB (отдельно от кэша slapd). Эта команда имеет следующий формат: set_cachesize <GigaBytes> <Bytes> <Segments;>. Параметры GigaBytes и Bytes относятся к размеру кэша (эти два параметра суммируются), а параметр Segments позволяет вам разделять кэш между отдельными блоками памяти для преодоления ограничений 32-разрядной адресации (значения этого параметра, равные как 0, так и 1, работают одинаково, позволяя использовать только один сегмент памяти). Чтобы задать кэш размером в 1 Гб, используйте команду set_cachesize 1 0 0.
Самый простой способ определить оптимальный размер кэша BDB – это посмотреть статистику использования кэша в работающей системе и при необходимости увеличить его размер. Статистику использования кэша BDB можно посмотреть с помощью команды db_stat -h /path/to/database -m. Наиболее значимая информация содержится в первых 20 строках вывода этой команды. Если из кэша удаляется большое количество страниц или количество страниц, найденных в кэше, составляет менее 95% от общего количества, подумайте об увеличении его размера. В некоторых дистрибутивах команда db_stat может называться slapd_db_stat, что позволяет обособить ее от системных библиотек и инструментов BDB.
Кроме оптимизации кэша вам необходимо обеспечить наблюдение за журналами транзакций. Укажите путь к журналам транзакций в качестве значения параметра set_lg_dir. Если вы сможете разместить базу данных и журнал транзакций на отдельных физических дисках или дисковых массивах, быстродействие системы существенно повысится.
Несмотря на то, что BDB является простой базой данных, существует необходимость блокировок файлов для выполнения операций записи. Обычно количество блокировок по умолчанию достаточно велико, но вам следует отслеживать максимальное количество используемых блокировок с помощью команды db_stat -h /path/to/database -c. Блокировки BDB делятся на три типа, для каждого из которых ведется отдельная статистика: lockers, locks и lock objects. Разница между этими тремя типами несущественна, тем не менее, максимальное количество блокировок каждого типа задается с помощью трех отдельных параметров – set_lk_max_lockers, set_lk_max_locks и set_lk_max_objects соответственно.
Каждый раз, когда вы вносите изменения в файл DB_CONFIG, вы должны перезапустить slapd. В листинге 19 приведен пример конфигурационного файла DB_CONFIG с использованием всех вышеупомянутых директив.
Листинг 19. Пример файла DB_CONFIG
# 256K cache set_cachesize 0 268435456 0 set_lg_dir /var/log/openldap set_lk_max_lockers 1000 set_lk_max_locks 1000 set_lk_max_objects 1000 |
Индексация базы данных
Большинство операций LDAP выполняют поиск определенных атрибутов, таких как имя пользователя, телефонный номер или адрес электронной почты. Без использования дополнительных средств slapd должен выполнять поиск, перебирая каждую запись. При добавлении индекса к определенному атрибуту создается специальный файл, который позволяет slapd находить данные гораздо быстрее. Недостатками использования индексов являются более низкая скорость записи в базу данных, а также увеличение загрузки жесткого диска и оперативной памяти. По этой причине лучше всего индексировать только те атрибуты, обращения к которым происходят чаще всего.
В зависимости от типа выполняемого поиска в OpenLDAP поддерживаются различные типы индексов. Все они перечислены в таблице 4.
Таблица 4. Типы индексов OpenLDAP
| Тип | Ключевое слово | Описание | Пример запроса |
|---|---|---|---|
| Наличие (Presence) | pres | Используется для выяснения существования атрибута. | uid=* |
| Эквивалентность (Equality) | eq | Используется для нахождения определенного значения. | uid=42 |
| Вхождение (Substring) | sub | Используется для нахождения строки, содержащейся в значении атрибута. Помимо основного типа sub вы можете использовать три его подтипа, оптимизированные для различных условий. | cn=Sean* |
| subinitial | Индекс вхождения, использующийся для нахождения строки, содержащейся в начале значения атрибута. | cn=Sean* | |
| subany | Индекс вхождения, использующийся для нахождения строки, содержащейся в середине значения атрибута. | cn=*jone* | |
| subfinal | Индекс вхождения, использующийся для нахождения строки, содержащейся в конце значения атрибута. | cn=*Smith | |
| Подобие (Approximate) | approx | Используется для нахождения значений, звучащих подобно указанной строке поиска. | cn~=Jason |
Чтобы создать индекс для атрибута, используйте следующий синтаксис: index [attrlist] [indices], где [attrlist] – это разделенный запятыми список атрибутов, а [indices] – разделенный запятыми список типов индексов, перечисленных в таблице 4. Можно использовать несколько строк с директивами index. Ключевое слово default определяет список типов индексов по умолчанию, который будет использоваться в том случае, когда опущен параметр [indices]. Ознакомьтесь с индексами, определенные в листинге 20.
Листинг 20. Примеры индексов
index default eq,sub index entryUUID,objectClass eq index cn,sn,mail eq,sub,subinitial,subany,subfinal index userid,telephonenumber index ou eq |
В первой строке листинга 20 определен список типов индексов по умолчанию, включающий в себя индексы эквивалентности и вхождения. Во второй строке создаются индексы эквивалентности для атрибутов entryUUID (полезно для повышения производительности syncrepl) и objectClass (для общего поиска). В третьей строке создаются индекс эквивалентности и все типы индексов вхождения для атрибутов cn, sn и mail, поскольку по этим полям часто выполняется поиск с использованием различных специальных символов. Для атрибутов userid и telephonenumber создаются индексы по умолчанию, поскольку не указаны никакие дополнительные параметры. Наконец, для атрибута ou создается индекс эквивалентности.
После определения индексов вы должны перестроить их, остановив slapd и выполнив команду slapindex от имени пользователя ldap (если вы работаете под учетной записью root, не забудьте назначить пользователя ldap владельцем всех файлов, расположенных в каталоге базы данных, после выполнения команды slapindex). Запустите slapd, после чего ваши индексы начнут использоваться.
Постовой
Все про опционы и опционные стратегии на лучшем сайте о биржевой торговле lowrisk.ru
Надоело пить непонятно что? Закажи доставку воды домой!