Рано или поздно это должно было случиться: производительность службы Active Directory (AD) внезапно снизилась без всякой видимой причины. На прошлой неделе все было нормально, но за последние дни администратор получил десяток жалоб на зависание системы при авторизации, ошибки при работе с адресной книгой в системе Microsoft Exchange Server и медленный запуск приложений. Запуск службы Performance Monitor на каждом из контроллеров домена показывает, что загруженность процессора на одном из контроллеров большую часть времени составляет 100%. Но ничего не изменилось, и все остальные компоненты вроде бы работают нормально. И что же делать?
В подобной ситуации может помочь Windows Server 2003 Performance Advisor (SPA), выпущенный компанией Microsoft более двух лет назад. SPA является эффективным, хотя и малоизвестным средством анализа производительности. Эта утилита автоматизирует сбор данных о настройках, оценочных данных о производительности одного или нескольких серверов и отслеживание событий (Event Tracing) в системе Windows (ETW), формирует итоговый массив данных и выдает удобные для чтения отчеты по производительности с предупреждениями и рекомендациями по устранению неполадок. SPA выпускается с предварительно настроенными коллекторами данных и правилами защиты производительности для основных файловых серверов, контроллеров домена службы AD, серверов DNS и серверов, использующих службу Microsoft Internet Information Services (IIS).
Шаг 1. Загрузка и установка утилиты SPA
SPA не поставляется вместе с Windows — придется загрузить ее со страницы http://www.microsoft.com/downloads/details.aspx?FamilyID=09115420-8c9d-46b9-a9a5-9bffcd 237da2=09115420-8c9d-46b9-a9a5-9bffcd 237da2. Важно убедиться, что это самая последняя версия, а не старая служба Server Performance Advisor 1.0. Установочный файл —spa_v2_msi.
Запуск утилиты SPA на загруженном сервере, например на контроллере домена, может привести к созданию журнала данных. Для размещения папки для хранения данных требуется несколько гигабайтов свободного места. В идеале следует поместить папку хранения данных на отдельном носителе, чтобы SPA как можно меньше влияла на производительность.
Установка утилиты SPA в системе Windows с 32-разрядной адресацией довольно проста. Нужно запустить полученный пакет Windows Installer; подтвердить, что вы принимаете лицензионное соглашение End-User License Agreement (EULA), подтвердить предложенные по умолчанию настройки для установки, хранения данных и папок с отчетами — и можно приступать.
Установка утилиты SPA в системе Windows с 64-разрядной адресацией чуть сложнее. Утилите SPA требуется пакет Microsoft .NET Framework версии 1.1, но эта версия недоступна для платформ с 64-разрядной адресацией. Однако можно использовать 32-разрядную версию .NET Framework на 64-разрядном сервере, и SPA будет нормально работать. Необходимо сделать следующее: загрузить и установить распространяемый пакет .NET Framework версии 1.1, доступный на странице http://www.microsoft.com/downloads/details.aspx?FamilyID=262d25e3-f589-4842-8157-034d1e7cf3a3&displaylang=en.
Затем нужно загрузить и установить пакет NET Framework Service Pack 1 (SP1) для системы Windows Server 2003. Он доступен на странице
http://www.microsoft.com/downloads/details.aspx?familyid=AE7EDEF7-2CB7-4864-8623-A1038563DF23&displaylang=en. И наконец, требуется установить утилиту SPA.
В дополнение к копированию исполняемых файлов и созданию папок SPA, программа установки создает несколько запланированных задач для сбора данных о производительности. Можно просмотреть эти задачи, щелкнув на ярлыке Schedule Tasks в окне Control Panel. Задачи, создаваемые службой SPA, являются пассивными, то есть они создаются, но для них не назначается время выполнения. Когда используется клиентское приложение утилиты SPA для запуска сбора данных, приложение просто осуществляет планирование выполнения задачи. Это необычный подход, но он проще, чем создание службы Windows, и к тому же эффективнее.
Шаг 2. Запуск утилиты SPA
Можно запустить клиентское приложение утилиты SPA, выбрав пункт меню Start, All Programs, Server Performance Advisor. При запуске клиентского приложения вы сталкиваетесь с непривычным пользовательским интерфейсом, изначально скрывающим иерархию объектов. Для отображения дерева нужно выбрать пункт Scope Tree из меню View или щелкнуть на значке в виде документа, расположенном на сером фоне в левой части окна.
Окно утилиты SPA использует традиционную структуру консоли Microsoft Management Console (MMC): иерархия объектов отображается в левом окне, а данные — в правом. Узлы Trace Providers и Performance Counters полезны для формирования новых типов сбора данных. Но наибольший интерес представляют узлы Data Collectors и Reports.
SPA получает данные о производительности сервера с помощью набора коллекторов данных. Существует четыре типа коллекторов данных: коллекторы оценок производительности, коллекторы настроек реестра, коллекторы отслеживаемых данных и коллекторы отслеживаемых данных ядра. SPA объединяет коллекторы данных в группы коллекторов, каждая из которых отвечает за данные по производительности определенной подсистемы, например служб IIS или AD.
В SPA имеется более 90 предварительно настроенных групп коллекторов. Процесс установки определяет, для какой роли или ролей предназначен сервер и в зависимости от этих ролей добавляет одну или несколько из следующих восьми групп коллекторов данных:
- Active Directory
- Active Directory/Application Mode (ADAM)
- DNS Server
- DNS Server Extended
- File (файловая система)
- IIS
- Print Spooler (сервер печати)
- System Overview (информация о системе)
SPA активирует соответствующие группы коллекторов при установке и отображает их в узлах Data Collectors и Reports в окне Scope Tree. Таким образом, например, при установке службы на контроллер домена будет отображена группа Active Directory. Можно активировать или деактивировать отдельные группы коллекторов из клиентского приложения утилиты SPA, щелкнув на пункте меню File->Add/Repair Data Collector Groups->Server Roles.
В состав утилиты SPA входят специализированные группы коллекторов, которые можно использовать и изменять в соответствии с текущими задачами. Можно активировать эти группы коллекторов, выбрав соответствующую группу в меню.
Шаг 3. Запуск сбора информации
Я настроил контроллер домена с именем DC2, работающий под управлением системы Windows 2003 SP1 с несколькими клиентскими машинами, на создание тестовой нагрузки с помощью приложения Active Directory Performance Testing Tool (ADTest.exe на странице http://www.microsoft.com/downloads/details.aspx?familyid=4814FE3F-92CE-4871-B8A4-99F98B3F4338&displaylang=en). Я изменил сценарии службы ADTest таким образом, чтобы они генерировали трафик данных аутентификации и простейшие процессы поиска по протоколу LDAP, и запустил их. Все рабочие процессы на контроллере домена были остановлены. Для выполнения анализа загрузки контроллера домена с помощью утилиты SPA я запустил сбор данных.
Чтобы начать сбор данных, нужно запустить SPA, открыть дерево объектов, выбрать группу коллекторов, которую требуется активировать (в нашем случае группу Active Direc- tory), и выбрать пункт Start из меню Record (нажмите F9 или щелкните на зеленой стрелке в панели инструментов). SPA назначает немедленное выполнение пассивных задач сбора данных и отображает несколько ярлыков сбора данных, которые соответствуют запущенным коллекторам данных. Группа коллекторов Active Directory содержит четыре задачи из области сбора данных: сбор данных по оценке производительности, сбор данных реестра, сбор данных Active Directory ETW и сбор данных Kernel ETW. Каждой из задач соответствует ярлык, расположенный вне окна.
По умолчанию коллекторы данных помещают свои исходные данные в папку C:PerfLogsDataназвание группы коллекторовCurrent folder. После завершения сбора данных SPA перемещает файлы исходных данных в промежуточную папку, после чего запускает программу SPARPT, которая перерабатывает данные и создает отчет в формате XML. SPA сохраняет отчет в папку, название которой состоит из названия сервера, а также даты и времени сбора данных, и размещает ее в каталоге Reports (например, C:PerfLogsReportActive DirectoryDC2_200607051641).
Шаг 4. Просмотр отчета
Пакет Performance Monitor может собрать большее количество данных, чем SPA, но эта служба выделяется именно своей способностью суммировать и представлять сотни мегабайтов данных в наглядных отчетах. SPA представляет данные о производительности в виде отдельной (возможно, достаточно большой) HTML-страницы. SPA организует отчеты о производительности по каждой группе коллекторов. Чтобы просмотреть отчет о производительности для группы коллекторов, нужно открыть узел Reports для данной группы коллекторов и выбрать пункт Current. SPA отображает доступные отчеты в окне данных, и путь к отчету состоит из названия компьютера, года, месяца и времени. Для просмотра отчета необходимо щелкнуть сначала на названии системы, потом на нужном годе, месяце и дне. Наконец, следует щелкнуть на отчете, который требуется просмотреть, и SPA отобразит его в окне данных.
Чтобы упростить перемещение по отчету, в таблицу с содержанием, размещенную в начале отчета, введены гиперссылки на разделы: раздел Performance Advice, несколько разделов, посвященных производительности службы AD, разделы, подробно описывающие загруженность процессора, сети, диска и памяти. В конце отчета находятся некоторые параметры отладки системы из реестра, основные настройки системы и информация по сбору данных. Давайте подробно рассмотрим некоторые разделы отчета.
Раздел Summary (Сводка). Сначала обратимся к разделу Summary, представленному на экране 1. Здесь можно найти следующую информацию:
CPU Usage(%) (использование процессора): загрузка центрального процессора во время сбора данных.
Top Process Group (группа процессов с максимальной нагрузкой): процесс, вызвавший максимальную загрузку процессора (на контроллере домена в этом качестве должны выступать процессы группы LSASS).
Top Activity (операции с максимальной нагрузкой): операция, выполняемая этим процессом и требующая максимальной загрузки процессора.
Top Client (наиболее активные клиенты): IP-адрес клиента, максимально загружающего процессор.
Top Disk by IO Rate (наиболее загруженные диски (по скорости ввода/вывода)): максимально используемый диск.
SPA может показать клиентские операции и операции службы AD, вызывающие максимальную загрузку процессора и наибольший объем ввода/вывода на диске за время сбора данных — обычно это все, что необходимо для определения причин возникновения проблем в работе контроллера домена. Если щелкнуть на одном из пунктов в разделе Summary, SPA переадресует вас к той части отчета, которая подробно описывает данный пункт.
Проблемы производительности. Ознакомившись со сводкой, следует щелкнуть на ссылке Warnings (Предупреждения) в разделе Performance Advice (Советы по производительности). SPA предоставляет 17 правил защиты для службы AD и 17 общих правил защиты, применяемых для всех ролей сервера. Можно настроить каждое правило, выбрав пункт Rules из меню Edit.
В нашем случае мы получаем три предупреждения, отображенные на экране 2.
Наиболее активный клиент потребляет 24,74% мощности процессора — куда больше, чем должен потреблять отдельный клиент.
Выходная длина очереди сетевой карты в контроллере домена — 12 пакетов. Это много: надо рассчитывать на длину очереди 1 или 2. Длинная очередь говорит о том, контроллер домена посылает слишком много данных через сетевую карту.
Процессы поиска, вызванные клиентами протокола LDAP службы AD, используют индекс объектов-прародителей. Служба AD задействует этот индекс для поиска на основе неиндексированного атрибута. В данной ситуации служба AD должна прочесть и проверить каждый объект в контейнере. Применение индекса объектов-прародителей говорит об использовании плохо продуманного запроса или необходимости создать новый индекс в структуре AD.
Раздел Directory Search (Поиск по каталогу). Если щелкнуть на ссылке в столбце Item для какого-либо предупреждения, SPA отобразит раздел отчета, который содержит более подробную информацию по данному предупреждению. Щелчок мышью на ссылке для первого предупреждения, показанного на экране 2, приведет к отображению раздела Directory Search (см. экран 3). Таблица Clients with the Most CPU Usage отображает список IP-адресов клиентов и информацию о производительности клиентских процессов поиска. Таблица Unique Searches показывает, что процессы поиска, вызванные клиентом с адресом 10.7.0.131, используют чрезмерную мощность процессора. Флаг в столбце Index в первой строке этой таблицы соответствует проблеме производительности, отображенной на экране 2; он означает, что именно клиент с адресом 10.7.0.131 ответствен за использование 24,74% мощности процессора.
Если щелкнуть на знаке + слева от IP-адреса клиента в таблице Clients with the Most CPU Usage, можно просмотреть подробную информацию по всем отдельным процессам поиска, связанным с этим клиентом, а также параметры поиска и другую информацию, связанную с поиском (см. экран 4). Каждая строка отображает одну или несколько операций поиска, которые имеют одинаковые базу поиска в протоколе LDAP, диапазон, фильтр и код результата. Примечание Top: 3 of 7 в панели заголовка таблицы говорит о том, что SPA показывает только три процесса поиска по протоколу LDAP с максимальным значением в определенном столбце. Чтобы просмотреть остальные записи, нужно щелкнуть на значении 3 и ввести другое число. Для сортировки данных по значению из определенного столбца следует щелкнуть на заголовке столбца. Подобным образом работает большинство таблиц в отчете SPA.
Столбец Index показывает индекс, используемый службой AD для выполнения поиска. Для поиска контейнера контекста именования схемы, одного из самых сложных среди отображаемых процессов поиска, фильтр поиска cn=*a* определяет выполнение поиска по середине строки (т. е. поиска с использованием фильтра, содержащего символ сопоставления, который не попадает в конец строки) на основе атрибута Common Name (CN). Атрибут CN индексируется в службе AD по умолчанию, но не для поиска по середине строки. Поэтому службе AD приходится читать каждый объект в контейнере контекста именования схемы, чтобы определить, совпадает ли его значение со значением фильтра.
Рассмотрев остальные процессы поиска, выполняемые данным клиентом, можно заметить, что они работают аналогично поиску контейнера контекста именования схемы: выполняют в деревьях нижнего уровня поиск по середине строки по значению атрибута CN. При этом службе AD приходится использовать либо индекс объектов-прародителей, либо индекс метки уникального имени (dnt_index), при этом ни один из них не оптимален для производительности процесса. Если слишком много процессов поиска используют индекс объектов-прародителей или индекс dnt_index, требуется либо изменить фильтр поиска и задействовать преимущество встроенных индексов службы AD, либо создать новые индексы. Например, если очевидно, что выражение cn=*a* — это правильный фильтр, который необходимо оптимизировать, можно добавить индекс поиска по середине строки на основе значения атрибута CN.
Используя статью Microsoft «Index an attribute in Active Directory» (http://go.microsoft.com/fwlink/?LinkId=46790), добавить индекс в службу AD просто. Следует иметь в виду, что каждый индекс использует дополнительное дисковое пространство и для дальнейшей работы вызывает операции обновления. Если у вас уже имеется большое информационное дерево Directory Information Tree (DIT), то объем дополнительной памяти может быть довольно существенным. Кроме того, проиндексированы будут все объекты в службе AD, а не только объекты в одном контейнере или в схеме NC, поэтому, прежде чем изменить индекс, оцените влияние нового индекса на производительность и тщательно протестируйте его.
Мы разобрались с двумя из трех проблем производительности. Давайте теперь поговорим о длинной выходной очереди на сетевой карте.
Раздел оценки производительности сетевой карты. Вернитесь в раздел Warnings в начале отчета и щелкните на ссылке в строке предупреждения о длинной очереди на сетевой карте. SPA отобразит таблицу оценки производительности сетевого интерфейса (Network Interface), приведенную на экране 5. Если навести курсор на флаг в столбце Mean и строке Output Queue Length, служба отобразит описание проблемы производительности.
На экране 5 можно увидеть несколько интересных значений. Показатель Current Bandwidth (Текущая полоса пропускания) имеет значение 100 Мбит, то есть устройство со скоростью 10/100 Мбит/с на самом деле работает со скоростью 100 Мбит/с. Показатель Bytes Total/sec (Всего байт/с) имеет значение 3,6 Мбайт/с, что значительно ниже возможностей сети. Я знаю, что на сервере, для которого создается отчет, весь сетевой трафик либо идет на контроллер домена, либо приходит с него. И наконец, мы видим, что показатель Bytes Sent/sec (Послано байт/с) учитывает почти весь трафик, из чего можно сделать вывод, что процессы поиска по протоколу LDAP получают чрезмерное количество данных.
Так почему выходная очередь имеет большую длину? Существует несколько вариантов.
Сетевая карта работает с максимальной загрузкой или с почти максимальной.
На сетевой карте установлен недостаточный объем выходных буферов.
Выходная очередь обрабатывается медленно, так как не хватает вычислительных возможностей процессора.
Хотя отчет показывает, что средняя общая пропускная способность сетевой карты составляет 3,6 Мбайт/с, пик пропускной способности составляет 10,8 Мбайт/с — он достигается при теоретическом максимуме в 100 Мбит/с (около 10 Мбайт/с). Из этого следует, что сетевая карта периодически бывает перегружена, а это означает, что другие компоненты сетевого сегмента также могут быть перегружены. Так как процессор работает почти на максимуме возможностей, добавление еще одной сетевой карты ситуацию не изменит. Для получения окончательного ответа может потребоваться дополнительный анализ, но лучшей стратегией является снижение нагрузки на сервер путем оптимизации запросов (или добавления индекса) и при необходимости либо замены процессора на более быстрый, либо добавления дополнительного контроллера домена и распределения обработки запроса между контроллерами.
Запросы по протоколу LDAP. Существует еще одно отклонение, которое стоит рассмотреть. Если щелкнуть на ссылке Top Client в разделе Summary, изображенном на экране 1, SPA отобразит подраздел Clients with the Most CPU Usage раздела LDAP Request. Конечно, клиент с адресом 10.7.0.131 является основным нарушителем.
Если раскрыть запись для данного IP-адреса, SPA отобразит сводку по операциям, выполненным данным клиентом, и процент ресурсов процессора, потребляемый каждой операцией (см. экран 6). Можно увидеть, что клиент с адресом 10.7.0.131 использует максимальное количество ресурсов процессора, вызывая процессы поиска nonDSE (т. е. поиск некоторой части дерева каталога). Эти данные соответствуют информации, полученной нами ранее.
Однако стоит обратить внимание на вторую строку сводки операций, где приведено существенное количество клиентских процессов поиска, закончившихся неудачно из-за ошибки Size Limit Exceeded. Эти ошибки являются причиной использования 12% ресурсов процессора. Таким образом, SPA помогла обнаружить по крайней мере одну проблему, связанную с этим клиентом: он не использует страничный поиск. Отсутствие страничного поиска — распространенная ошибка при программировании приложений и может привести к тому, что служба AD не предоставит все те данные, которые ищет приложение.
Чего мы добились?
Имея в наличии перегруженный контроллер домена, мы запустили группу коллекторов данных утилиты SPA Active Directory и получили отчет, выявляющий три причины возникновения проблем производительности:
клиенты вызывают процессы поиска по середине строки на основе атрибута, который не был индексирован для поиска данного типа;
клиенты не используют страничный поиск;
сетевая карта (и, возможно, другие системные и сетевые компоненты) перегружены.
Неплохие результаты за 15 минут работы! Также можно использовать утилиту SPA для сбора и архивирования данных о производительности с планированием, создавая базовые данные. Следующая моя статья будет посвящена настройке утилиты SPA на сбор данных с нескольких серверов и создание отчетов на централизованном отчетном сервере.
Джил Киркпатрик (gilk@netpro.com) — директор по технологиям в NetPro и MVP по Directory Services. Ведущий конференции Directory Experts Conference