Анализ производительности PAL


Вовнею посвящается.

img_25112016_173722

Проносило меня как-то мимо ФБ, и случайно я увидел тредик, в котором поднимался, в общем-то каждодневный и злободневный вопрос для любого администратора.

Как замониторить почтарь систему Х. Тут и администратор желтой программы, и ДБА, и кто угодно может расстроиться и начать искать крайних кругом, стреляя в администраторов виртуализации, или склоняя другие отделы к вспомоществованию.

В том топике сразу же эксперты с мировым именем на вопрос чем и как снять показания с больного, предложили perfmon.

Ну еще бы: данные-то от него не им смотреть, поэтому почему бы и не предложить.

Увидев такое я загрустил, поскольку вопрос «тормозит у меня» поднимается довольно часто, а внятных гайдов, куда бежать-то и нет.

А вопросы, чем анализировать данные которые дают, есть.

Было решено исправить упущение, по этому встречаем:

Performance Analysis of Logs (PAL) Tool

[Чего на курсах МС не расскажут, так это того, что собирать данные в виде культурных графиков можно старым добрым способом, но мы его трогать не будем, просто хотелось бы упомянуть что можно и так. Не все про это знают, увы.]

Итак, знакомимся со страничкой проекта.

Обязательно советую скачать ролик со страницы проекта, чтобы поглядеть, что все эти вопросы были решены в далеком 2008 году, и подробно разобран алгоритм работы программы.

Для тех кто ролик не осилит, предложу далее немного картинок и больших букв.

Алгоритм прост: скачали PAL на рабочую станцию администратора, показали путь к файлам логов, выбрали паттерн из готового или создали новый свой.

Подкрутили параметры экспорта и производительности.

Уходим пить чай, кофе или другие жидкости, поскольку если файл большой, анализ будет длиться очень и очень долго. Начинайте с малых, смотрите производительность вычислений скрипта и привыкайте к работе программы. Торопиться не надо.

1 2 3 4 5 6

67

Вот такие страшные картинки получились в результате.

Для любопытных приложу полный отчет на демо сервере, можете скачать и изучить его. Такой же получится и у вас, и продолжим наставления.

Итак, что делать и полным отчетом? Сервер тормозит, всё красное? Куда бежать?

Бежать никуда не надо, надо собирать данные. Собрав данные, Вы получите свой baseline. А вот с ним уже будем работать. Мой страшный отчет собран на специально созданной  пыточной конфигурации Exchnage в Azure с низкими ресурсами. Поменяв конфигурацию я бы изменил и отчет.

Возьмем пример с технетов: администратор установил Exchange, создал там 50 ящиков, полетел. Но производительность сервера ему не нравится. Кажется, что Exchnage должен летать и порхать, ведь загрузки не видно, а все работает «как-то медленно».

Если под рукой нет добрых помошников вроде SCOM’ов, VCops’ов, Veeam One’ов и прочих экселей, то возьмем отчеты PAL. Прогоним их, сведем результаты в таблицу. Напряжем голову: есть ли проблема? Может, быть ее нет, и подотчетный сервер на имеющемся оборудовании так и будет работать. Если это ВМ, сдвинем на другой хост, и посмотрим. Потыкаем палочкой в другие подсистемы, которые можно безвозвратно и непоправимо улучшить.

Если ничего не помогает, то вывода два: либо принимаем проблему, либо готовимся к апгрейду.

Виноватых полно: дисковая подсистема сервера, сеть, и в 90% случаев неверная конфигурация. Да-да, волшебные изменения в настройках часто творят чудеса, если сделаны опытным специалистом, а не человеком, развернувшим в первый раз свой первый сервер.

Именно это узкое место и позволит определить вдумчивый поиск неисправности и работа головой. Не нужно размахивая распечаткой нестись к финдиректору или писать подлые письма в обслуживающую организацию, в стиле

«что-то у нас тут больше 20 мс очереди, это ой как плохо. Вот видите же красное». Вижу, но мне больше нравится сухое.

Нужно осмыслить эти цифры, и понять, действительно ли они плохие. Может стоит подкрутить счетчик в PAL, чтобы сказать ему, что Вас все устраивает, и не надо никого шокировать красным цветом? Ведь надо держаться с тем, что есть ,патронов больше не подвезут.

Серебрянной пули в посте я не предлагаю. Я лишь хотел рассказать о старом добром инструменте, (как обычно , сорвав покровы), про который к моему великому сожалению знают единицы людей, и еще меньше им пользуются. А жаль.

PS. Напишите в комментариях к статье, чем Вы пользуетесь в критичных ситуациях разбора полетов, и почему.

P.P.S.

Блог Clint Huffman
http://blogs.technet.com/b/clinth/

Книга Clint Huffman, просто великолепная, лучшая из того что можно прочитать по анализу производительности. Лучше одну ее прочитать.
Windows Performance Analysis Field Guide
http://www.amazon.com/dp/0124167012/ref=wl…=I2TOVTYHI6HDHC

Надеюсь, этот пост был полезен, всех благ.

Реклама

Анализ производительности PAL: 2 комментария

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s