Мониторинг производительности Windows Server, настройка оповещений счетчиков PerfMon
В этой статье мы рассмотрим особенности использования встроенных счетчиков производительности Performance Monitor для мониторинга состояния Windows Server. Счетчики PerfMon можно использовать для отслеживания изменений определенных параметров производительности сервера (алертов) и оповещать администратора в случае возникновения высокой загрузки или других нештатных состояниях.
Чаще всего для мониторинга работоспособности, доступности, загруженности серверов используются сторонние продукты. Если вам нужно получать информацию о производительности приложений либо железа только с одного-двух Windows-серверов, либо когда это нужно на непостоянной основе, либо возник более сложный случай, требующий глубокого траблшутинга производительности, то можно воспользоваться встроенным функционалом Windows Performance Monitor.
Основные возможности Performance Monitor, которые можно использовать отдельно или совместно с другими сторонними системами мониторинга (типа Zabbix, Nagios, Cacti и другие):
- cистема мониторинга при выводе информации о производительности сначала обращается к Performance Monitor;
- главной задачей системы мониторинга является оповещение о наступлении тревожного момента, аварии, а у Performance Monitor – собрать и предоставить диагностические данные.
Текущие значения производительности Windows можно получить из Task Manager, но Performance Monitor умеет несколько больше:
- Task Manager работает только в реальном времени и только на конкретном (локальном) хосте;
- в Performance Monitor можно подключать счётчики с разных серверов, вести наблюдение длительное время и собранную информацию сохранять в файл;
- в Task Manager очень мало показателей производительности.
Мониторинг производительности процессора с Perfomance Monitor
Для снятия данных о производительности процессора воспользуемся несколькими основными счётчиками:
- \Processor\% Processor Time— определяет уровень загрузки ЦП, и отслеживает время, которое ЦП затрачивает на работу процесса. Уровень загрузки ЦП в диапазоне в пределах 80-90 % может указывать на необходимость добавления процессорной мощности.
- \Processor\%Privileged Time — соответствует проценту процессорного времени, затраченного на выполнение команд ядра операционной системы Windows, таких как обработка запросов ввода-вывода SQL Server. Если значение этого счетчика постоянно высокое, и счетчики для объекта Физический диск также имеют высокие значения, то необходимо рассмотреть вопрос об установке более быстрой и более эффективной дисковой подсистемы (см. более подробную статью об анализе производительности дисков с помощью PerfMon).
- \Processor\%User Time — соответствует проценту времени работы CPU, которое он затрачивает на выполнение пользовательских приложений.
Запустите Performance Monitor с помощью команды perfmon. В разделе Performance Monitor отображается загрузкой CPU в реальном времени с помощью графика (параметр Line), с помощью цифр (параметр Report), с помощью столбчатой гистограммы (параметр Histogram bar) (вид выбирается в панели инструментов). Чтобы добавить счетчики, нажмите кнопку “+” (Add Counters).
Слева направо двигается линия в реальном времени и отображает график загрузки процессора, на котором можно увидеть, как всплески, так и постоянную нагрузку.
Например, вам нужно посмотреть загрузку процессора виртуальными машинами и самим Hyper-V. Выберите группу счетчиков Hyper-V Hypervisor Logical Processor, выберите счетчик % Total Run Time. Вы можете показывать нагрузку по всем ядрам CPU (Total), либо по конкретным (HV LP №), либо всё сразу (All Instances). Выберем Total и All Instances.
Группы сборщиков данных в PerfMon
Чтобы не сидеть целый за наблюдением движения линии, создаются группы сбор данных (Data Collector Set), задаются для них параметры и периодически просматриваются.
Чтобы создать группу сбора данных, нужно нажать на разделе User Defined правой кнопкой мыши, в меню выбрать New -> Data Collector Set. Выберите Create manually (Advanced) -> Create Data Logs и включите опцию Performance Counter. Нажмите Add и добавите счётчики. В нашем примере % Total Run Time из группы Hyper-V Hypervisor Logical Processor и Available MBytes из Memory. Установите интервал опроса счётчиков в 3 секунды.
Далее вручную запустите созданный Data Collector Set, нажав на нём правой кнопкой мыши и выбрав в меню пункт Start.
Через некоторое время можно просмотреть отчёт. Для этого в контекстном меню группы сбора данных нужно выбрать пункт Latest Report. Вы можете посмотреть и проанализировать отчёт производительности в виде графика. Отчёт можно скопировать и переслать. Он хранится в C:\PerfLogs\Admin\CPU_Mon и имеет расширение .blg.
Если нужно на другом сервере запустить такой же набор счётчиков, как на первом, то их можно переносить экспортом. Для этого в контекстном меню группы сбора данных выберите пункт Save Template, укажите имя файла (расширение .xml). Скопируйте xml файл на другой сервер, создайте новую группу сбора данных, выберите пункт Create from a template и укажите готовый шаблон.
Создание Alert для мониторинга загрузки CPU
В определённый критический момент в Performance Monitor могут срабатывать алерты, которые помогают ИТ-специалисту прояснить суть проблемы. В первом случае алерт может отправить оповещение, а во втором – запустить другую группу сбора данных.
Чтобы создать алерт в PerfMon, нужно создать ещё один Data Collector Set. Укажите его имя CPU_Alert, выберите опцию Create manually (Advanced), а затем — Performance Counter Alert. Добавьте счётчик % Total Run Time из Hyper-V Hypervisor Logical Processor, укажите границу загрузки 50 %, при превышении которой будет срабатывать алерт, установите интервал опроса счётчика в 3 секунды.
Далее нужно зайти в свойства данной группы сбора информации, перейти на вкладку Alert Action, включить опцию Log an entry in the application event log и запустить группу сбора данных. Когда сработает алерт, в журнале (в консоли Event Viewer в разделе Applications and Services Logs\Microsoft\Windows\Diagnosis-PLA\Operational) появится запись:
“Performance counter \Processor(_Total)\% Processor Time has tripped its alert threshold. The counter value of 100.000000 is over the limit value of 50.000000. 50.000000 is the alert threshold value”.
Здесь же рассмотрим и второй случай, когда нужно запустить другую группу сбора данных. Например, алерт срабатывает при достижении высокой загрузки CPU, делает запись в лог, но вы хотите включить сбор данных с других счётчиков для получения дополнительной информации. Для этого необходимо в свойствах алерта в меню Alert Action в выпадающем списке Start a data collector set выбрать ранее созданную группу сбора, например, CPU_Mon. Рядом находится вкладка Alert Task, в которой можно указать разные аргументы либо подключить готовую задачу из консоли Task Scheduler, указав её имя в поле Run this task when an alert is triggered. Будем использовать второй вариант.
С помощью Task Scheduler можно выполнить какие-то действия: выполнить команду, отправить письмо или вывести сообщение на экран (сейчас последниед ве функции не поддерживаются, считаются устаревшими (deprecated)). Для вывода на уведомления на экран можно использовать скриптом PowerShell. Для этого в консоли Task Scheduler создайте новую задачу, на вкладке Triggers выберите One time, на вкладке Actions в выпадающем поле Action выбирите параметр Start a program, в поле Program/Script укажите powershell.exe, а в поле Add arguments (optional) следующий код:
-WindowStyle hidden -Command «& <[System.Reflection.Assembly]::LoadWithPartialName('System.Windows.Forms'); [System.Windows.Forms.MessageBox]::Show('Внимание, CPU загружен', 'Посмотреть')>«
Для отправки письма вы можете воспользоваться командлетом PowerShell Send-MailMessage или стороннюю утилиту mailsend.exe.. Для этого создайте аналогичное задание в Task Scheduler, в поле Program/Script укажите полный путь к утилите (у нас C:\Scripts\Mail\mailsend.exe), а в поле Add arguments (optional) через параметры нужно передать значения: электронный адрес, адрес и номер порта SMTP-сервера, текст письма и заголовка, пароль:
-to dep.it@ddd.com -from dep.it@ddd.com -ssl -port 465 -auth -smtp smtp.ddd.com -sub Alarm -v -user dep.it@ddd.com +cc +bc -M «Alarm, CPU, Alarm» -pass «it12345»
где +cc означает не запрашивать копию письма, +bc — не запрашивать скрытую копию письма.
Как проверить производительность сервера windows 2019
Я получил несколько серверов 2016 года, которые ужасно медленные (обновления Windows очень медленные, что хорошо известно, но общая производительность также довольно плохая), и я надеялся, что сервер Windows 2019 работает намного лучше. Ребята, у вас есть опыт?
WS 19 исправляет гораздо быстрее. Будь то из-за того, что Microsoft исправляет свой дерьмовый стек обновлений или просто потому, что на данный момент нет трехлетних патчей для его обработки, еще неизвестно. Это все еще однопоточный, поэтому я боюсь, что это последнее.
У меня не было много проблем с WS16 за пределами RDS. Пользовательский интерфейс конечного пользователя может быть совершенно сломан время от времени. Предварительный просмотр миниатюр панели задач, как застрять в открытую — это бесит. В остальном все было в порядке.
Надеемся, что WS19 в приложении RDS исправит все ужасные ошибки в Windows 10 GUI. Я надеюсь!
С точки зрения отзывчивости я не могу сказать, что видел большую разницу, они оба кажутся приемлемо быстрыми на эквивалентном оборудовании для меня.
Это лучший стек обновлений. Помните, что сервер 2016 работает на той же самой базе, что и та же старая база Win10-1607, которая была выпущена в середине 2016 года. С тех пор было много улучшений в более поздних версиях Win10 и 2019
Вы хотите, чтобы исправление, то есть запись на диск, было многопоточным?
Я не вижу причин, по которым они не могут оценивать и применять патчи более чем по одному за раз. Вдвойне, учитывая, что они являются одной из крупнейших компаний-разработчиков программного обеспечения на планете.
Я думаю, что они такие большие — одна из причин, почему это так сложно. Представьте, какие там бюрократические заграждения существуют.
Не цитируйте мне правила. Я был сопредседателем комитета, который рассмотрел рекомендацию о пересмотре цвета книги, в которой находятся эти правила.
Что касается бюрократического БС . Вы понятия не имеете .
Это не имело бы значения, если бы это было не навязчивым. Ни в одном дистрибутиве Linux обновления не выполняются одновременно, но это не имеет значения, потому что обновления неинтрузивные, асинхронные и меньше, чем обновления Windows.
Из того, что я видел, по крайней мере исправление 2019 года намного более плавно. Что касается всего остального, я действительно не чувствовал разницу.
Я действительно не против того, чтобы исправление заняло так много времени, просто немного облом. Но общие показатели 2016 года такие плохие. Я думаю, мне просто нужно установить сервер 2019 и убедиться в этом сам.
На мой взгляд, вы должны использовать SSD с Server 2016 и выше, чтобы получить приемлемую производительность
Как я упоминал ранее, у одного из моих клиентов есть одна полностью флеш-система, и производительность на самом деле не лучше, чем у полностью жестких систем.
Это, кажется, имеет небольшое влияние. Это все еще может занять более часа . часто.
Я поместил твердотельные накопители m.2 в RAID 1 для загрузочного диска нашего нового компьютера с Windows Server 2016, и новые исправления Windows заняли еще два часа. Я действительно не думаю, что HDD имеет значение
ну да 2016 год отстой в любом случае — он основан на win10 1607, и это тоже было ужасно.
Нет проблем с производительностью в 2016 году. Возможно, вам нужно проверить базовое оборудование?
2016 год ужасно медленный.
Стек обслуживания сломан, но это хорошо известно. Установка накопительного обновления занимает 2 часа в традиционной медленной сети SAN.
2016 также включает в себя множество потребительских функций, которые (к счастью) были исключены в 2019 году. В 2016 году был стек Xbox для громкого крика. Нечестно говорить людям «проверять базовое оборудование», когда оно отлично работало с 2008R2. Мы говорим о том, как щелкать по интерфейсу Windows, открывать меню «Пуск» и искать. Очень простые вещи.
2019, к счастью, намного лучше. Наравне с 2012R2 скажу. Нигде так быстро, как 2008R2.
Нет конфетки на сервере 2019? Тогда какой смысл?
Что, черт возьми, мы должны делать, ожидая загрузки обновлений?
Это хорошая информация. Я также говорю о проблемах производительности с простыми задачами, такими как щелчок в графическом интерфейсе. Я обязательно попробую сервер 2019. Я бы сказал, что 2016 год похож на Windows 8 (не 8.1).
Я так не думаю. Когда я сравниваю сервер 2012r2 с сервером 2016 как с одинаковой конфигурацией, скажем, с 4 ядрами и оперативной памятью 8 ГБ, 2012r2 работает намного плавнее .
Настройки гипервизора также. В прошлом я видел пару других потоков, в которых определенные конфигурации VMware могут вызывать проблемы с производительностью, но не слишком много знаем об этом.
Для меня это был Защитник Windows, который поставляется встроенным и включенным из коробки в 2016/19 (его не было в 2012 году). Как только я установил исключения AV, это исправило мои проблемы с перфорированием. Если вы отключите защиту в реальном времени все вместе (не рекомендуется), система будет чувствовать себя так же быстро, как и в 2012 году, исходя из моего опыта.
Огромное спасибо за хедз-ап.
Я обязательно попробую это. Спасибо приятель.
Я замечаю 0 различий между 2012/2016/2019 с точки зрения производительности.
2019, кажется, имеет случайные проблемы с меню Пуск, но делает все из командной строки, чтобы исправить эту проблему
Хороший обходной путь. Но смотри мой ответ выше, не могу подтвердить, что нет никакой разницы. Это почему? То же виртуальное оборудование должно работать одинаково или даже лучше на более новом сервере, верно? Перед тем, как всплывает вопрос: да, все в курсе.
Какие? Нет . Новая ОС почти всегда требует больше ресурсов. За исключением Windows 10 над 8, я никогда не знал, чтобы какая-либо ОС работала лучше, чем ее предшественница на том же оборудовании.
Конечно, вы правы. Я думаю, что это обычный цикл: 1 плохая операционная система (2008), 1 хорошая операционная система (2008r2), 1 плохая операционная система (2012), 1 хорошая операционная система (2012r2), 1 плохая операционная система (2016), надеюсь, 1 хорошая операционная система (2019)
Именно так. Тем не менее, я бы сказал, что разрыв между хорошим и плохим на серверных ОС не так велик, как у Desktop. В целом, Windows Server все еще улучшает стабильность за последние 10 лет.
Конечно, разрыв не так велик. Но это вроде очевидно. Хотя стабильность хорошая, но я все еще думаю, что пик был с 2012r2. Я не знаю . установка 2019 прямо сейчас, посмотрим, как она работает. Нужно избавиться от этого 2016 года!
Честно говоря, у меня не было проблем с производительностью на Windows Server 2016. В большинстве случаев, если были проблемы с производительностью, это в основном было связано с базовым оборудованием.
Вы плаваете в деньгах и SSD?
2016 год ужасен для RAID на все жесткие диски.
Не совсем, но на жестких дисках RAID 10 все в порядке.
Не могу подтвердить. У одного из наших клиентов есть полностью флеш-система, и производительность на самом деле не лучше, чем у полностью HDD RAID. Похоже, узкое место на стороне процессора .
общая производительность довольно плохо
Вы должны быть более конкретным, чем это. Дайте нам детали и метрики.
Простые вещи, такие как щелчок мышью в графическом интерфейсе, требуют вечности, а меню «Пуск» — навсегда, чтобы открыться . такие вещи.
Это вполне ожидаемо, в Server 2016 они снизили приоритет пользовательского интерфейса, чтобы ускорить фоновые процессы. Это по замыслу, 2019 год такой же. Они пытаются заставить вас использовать PowerShell больше.
А что менеджер по ресурсам скажет по этому поводу?
У меня не было проблем с производительностью в 2016 году (кроме обновлений), и у меня их тоже не было в 2019 году.
Но чувствуете ли вы разницу в производительности по сравнению с 2012r2?
Да, в худшем случае он одинаково быстр, но в большинстве случаев работает быстрее и плавнее.
Видите, вот в чем дело . но не то, чтобы 2016 был немного медленнее, он ужасно медленный
У нас сейчас много 2019-х в производстве. Что касается подачи контента, мы не видим никакой разницы. Резервное копирование файловых серверов фактически привело к заметному снижению производительности, сокращая время резервного копирования на 1/3 сразу после перемещения LUN на виртуальную машину 2019 года. Графический интерфейс рабочего стола на 2019 году очень быстрый и отзывчивый по сравнению с 2016 годом, даже после нескольких месяцев работы и под нагрузкой. Обновления Windows загружаются, устанавливаются и завершаются менее чем за 10 минут, в то время как в 2016 году обновления не могут получить такие же обновления, не превышая в некоторых случаях 1-2 часа.
У нас есть чуть более 800 серверов, из которых 1/10 из них на 2019 год охватывает широкий спектр услуг: ADDS, DNS, File & Print, SQL, Backup, ArcGIS, MySQL, IIS WWW, IIS FTP, IIS SMTP и т. Д., и это мои наблюдения до сих пор.
Вот ответ, который я искал. Спасибо за ваши идеи.
Извините, похоже, этот комментарий или тема нарушили правило sub-reddit и были удалены модератором.
Неправильное использование или ожидание Сообщества.
- Избегайте некачественных постов. Постарайтесь обогатить сообщество, в котором вы можете предоставить подробности, контекст, мнения и т. Д. В своих сообщениях.
- Moronic Monday и Thickheaded четверг доступны для простых вопросов или других запросов, которые не нуждаются в их собственной полной теме. Используйте их как можно больше.
Если вы хотите подать апелляцию на это действие, пожалуйста, не стесняйтесь сообщить модератору .