Любому администратору, конечно же, известно, что осуществляемый вручную процесс анализа журналов Performance Monitor отнимает массу времени и требует как глубоких знаний в области счетчиков производительности, так и знакомства с архитектурой Windows. В службу поддержки Microsoft Global Escalation Services поступают тысячи обращений с просьбами о помощи в анализе журналов Performance Monitor. Клиенты хотят либо решить некую проблему, либо уточнить, оптимизированы ли их серверы для достижения максимальной производительности. Я расскажу о некоторых инструментах, применяемых службой поддержки Microsoft для анализа производительности систем. Надеюсь, эта информация поможет вам более эффективно анализировать характеристики своих систем и выявлять неполадки, связанные с их производительностью.
Два этапа анализа
Анализ производительности включает решение двух основных задач.
Сбор данных. С увеличением числа управляемых систем осуществляемый локально или удаленно сбор данных журналов Performance Monitor может превратиться в сложную задачу. Еще одна проблема — определить, какой именно набор счетчиков производительности необходимо контролировать и по истечении каких временных интервалов это следует делать.
Анализ данных. Итак, данные собраны. Требуется организовать их корректный анализ, и надо сказать, что именно этому вопросу посвящена подавляющая часть обращений, поступающих в службу поддержки Microsoft.
Рассмотрим инструменты, с помощью которых администратор может выполнять каждую из упомянутых задач анализа производительности.
Средства сбора данных
Мастер Performance Monitor Wizard (perfwiz.exe) помогает администратору выполнить все этапы создания журналов утилиты Performance Monitor локально и удаленно. PerfWiz упрощает процесс сбора данных журналов Performance Monitor в системах Windows Server 2003, Windows XP (только x86) и Windows 2000. С этой целью мастер настраивает корректные счетчики для сбора и предлагает оптимальные интервалы выборки, а также размеры файлов журналов. PerfWiz можно загрузить по адресу www.microsoft.com/downloads/details.aspx?FamilyID=31FCCD98-C3A1–4644–9622-FAA046D69214&displaylang=en.
Logman.exe — это встроенное в систему Windows средство командной строки, осуществляющее управление и расписание сбора результатов счетчиков производительности на локальных и удаленных системах. Logman.exe выполняется в средах Windows Server 2008, Windows Vista (x86 и x64), Windows 2003 и Windows XP. Дополнительную информацию о синтаксисе Logman, а также примеры использования этого средства можно найти по адресу http://technet.microsoft.com/en-us/library/cc755366.aspx.
Вот пример использования программы командной строки logman.exe для создания журнала Performance Monitor с именем High-CPU-Perf-Log с целью сбора данных с пятисекундным интервалом:
Logman.exe create counter High-CPU- Perf-Log -f bincirc -v mmddhhmm -max 250-c "LogicalDisk (*)*" "Memory*" "Network Interface (*)*" "Paging File (*)*" "PhysicalDisk (*)*" "Process (*)*" "Redirector*" "Server*" "System*" "Thread (*)*" -si 00:00:05
Проследите за тем, чтобы вся команда вводилась одной строкой без разрывов, как показано в приведенном примере.
При выполнении команды logman.exe создается файл с расширением .blg. Для его просмотра откройте окно Performance Monitor и перейдите в папку Data Collector Sets, как показано на экране 1.
Если вы хотите запустить утилиту Performance Monitor с целью обнаружить причину неполадок в работе системы, я рекомендую перед запуском Performance Monitor перезагрузить сервер и выполнять проверку журнала с момента перезагрузки до проявления проблемы, причину которой вы определяете (зависание системы, снижение производительности). Давая возможность утилите собирать данные до момента проявления проблемы, вы обеспечиваете сбор всех необходимых данных, касающихся исследуемой ситуации. Накопление в журнале максимально широкого набора данных повышает эффективность анализа. Если действовать по принципу «сначала перезагрузка, а потом запуск Performance Monitor», причину найти легче, поскольку можно видеть статистику потребления ресурсов (памяти, процессора, дискового пространства) с самого начала и до возникновения проблемы.
Рекомендую регулярно собирать базовые данные по производительности самых важных серверов сети. Это позволит сэкономить время, которое вы тратите на то, чтобы определить, действительно ли возникла проблема или все в пределах нормы. Обращаясь к службе поддержки Microsoft, клиенты часто задают вопрос, следует ли считать тот или иной статистический показатель производительности «плохим» или «хорошим». Разумеется, Microsoft публикует ориентировочные данные в этой области, но тем не менее трудно сказать, какие именно показатели следует считать типичными для той или иной сети, если под рукой нет базовых данных производительности. Кроме того, фиксирование базовых уровней позволяет администраторам сосредоточиться на рассматриваемой проблеме, когда в системе имеются и другие неполадки. Некоторые статистические показатели производительности можно ошибочно принять за причину возникновения новой проблемы, и тому, кто располагает базовыми показателями за период, предшествующий появлению проблемы, будет легче абстрагироваться от не имеющих отношения к делу статистических данных. С рекомендациями Microsoft по сбору базовых данных можно познакомиться по адресу http://technet.microsoft.com/en-us/library/cc781394.aspx.
Анализ данных
Программа, с помощью которой сотрудники службы технической поддержки Microsoft анализируют журналы Performance Monitor, называется Performance Analysis of Logs (PAL) Tool. Это инструментальное средство объемом в 6000 строк кода написал на языке VBScript Клифф Хаффман, старший специалист по поддержке в Microsoft. PAL позволяет администраторам, которые отнюдь не должны быть экспертами ни в области счетчиков производительности, ни в сфере архитектуры Windows, с легкостью анализировать журналы Performance Monitor. PAL включает в себя пользовательский интерфейс на базе мастера, который запрашивает конкретные данные о системе. Затем PAL передает эти данные в качестве аргументов программе VBScript. В PAL получили дальнейшее развитие подходы, намеченные в других анализаторах журналов; так, программа принимает во внимание, относится ли система к категории 64-разрядных или 32-разрядных, используется ли в ней переключатель/3 Гбайт, а также учитывает объем установленной физической памяти — иначе говоря, все переменные, определяющие производительность системы. Разработчик PAL ранжировал тревожные извещения в хронологическом порядке; таким образом можно соотносить производительность системы с различными проблемами, выявленными в то или иное время.
Кроме того, утилита PAL дает возможность осуществлять анализ производительности при выполнении конкретных приложений, таких как Microsoft BizTalk Server, Microsoft Exchange Server, Microsoft Office SharePoint Server, Microsoft SQL Server и Microsoft IIS. Иначе говоря, если вы как администратор работаете по нескольким направлениям, в вашем распоряжении имеется средство для анализа данных производительности применительно к тому или иному приложению, и при этом от вас не требуется квалификации эксперта по счетчикам производительности для конкретного приложения. PAL может облегчить жизнь, с одной стороны, тем, что предоставляет базовые статистические показатели в ситуациях, когда система показывает нормальную производительность, а с другой — тем, что помогает выявлять причины неполадок в случае возникновения таковых.
Удобный в применении интерфейс программы PAL предоставляет пошаговые инструкции по выполнению не столь уж широкого набора действий, которые нужно предпринять, запуская процесс анализа. Генерируемый утилитой отчет об анализе представляет собой файл HTML, который по умолчанию хранится в папке My DocumentsPAL Reports. Отчет содержит гиперссылки и диаграммы, позволяющие с легкостью истолковывать результаты анализа и перемещаться по ним; а благодаря переносимости файла эти данные можно без труда разместить в любом удобном месте.
Применение программы PAL
Ценность программы PAL в критических ситуациях иллюстрирует пример, когда один из клиентов получил от системы Microsoft Operations Manager (MOM) извещение о том, что все службы BizTalk на одном из эксплуатируемых клиентом серверов BizTalk отключились. Удаленно подключиться к этому серверу было невозможно. Однако, поскольку сервер входил в состав кластера, журналы регистрации событий реплицировались, и администратор обнаружил следующую ошибку, имевшую место в случае, когда сервер BizTalk перестал функционировать:
Event Type: Error
Event Source: Srv
Event Category: None
Event ID: 2019
Description: The server was unable to allocate from the system non-paged ecause the pool was empty.
Ошибка разъясняла, почему удаленные подключения к серверу оказались невозможными, но не давала информации относительно корневой причины проблемы.
Клиент устранил проблему путем перезагрузки сервера, который после этого вновь стал участвовать в транзакциях BizTalk. Но нам нужно было понять, что же вызвало сбой. Мы начали с того, что запустили журнал Performance Monitor непосредственно после перезагрузки. Получив данные о производительности, мы скопировали файл .blg на рабочую станцию для анализа, затем передали этот файл мастеру PAL для формирования отчета по результатам анализа. Поскольку ошибка в журнале регистрации указывала, что система испытывала нехватку пула невыгружаемой памяти, мы прокрутили содержимое вниз и в разделе отчета, посвященном памяти, увидели тревожные оповещения, в том числе сообщения 31 Handle Leak Detection, как показано на экране 2.
После щелчка на гиперссылке Handle Leak Detection на экране отобразилась легко читаемая диаграмма, которая указывала на то, что в ходе одного процесса было использовано свыше 340 тыс. дескрипторов. Кроме того, мы щелкнули по ссылке Chronological Order (она расположена в начале отчета, но не показана на экране 2). На мониторе появилось разъяснение извещения, показанное на экране 3.
Выяснилось, что источником проблемы, возникшей на этом сервере, является процесс, на который указала нам программа PAL. Когда мы обновили процесс (т. е. выяснили у поставщика, имеется ли обновление, нашли не примененное клиентом обновление и установили его), проблема была устранена. Прекратилась и утечка дескрипторов, и тревожные сообщения от системы MOM о том, что процессы BizTalk перестали функционировать.
Полезный багаж
Надеюсь, что с помощью описанных выше инструментов и сформулированных мною рекомендаций по их использованию вы сможете составить более четкое представление о процессе анализа производительности систем. Эта информация поможет вам лучше разобраться с тем, как обычно функционируют ваши системы, а если придется столкнуться с проблемой снижения производительности, полученные знания позволят решить ее с применением бесплатно распространяемых и простых в использовании инструментов.
Майкл Моралес (morales@microsoft.com) — старший инженер службы поддержки Microsoft Global Escalation Services. Специализируется на проблемах отладки и производительности Windows
Просмотр файла .blg, сгенерированного logman.exe