- Мониторинг производительности Windows Server, настройка оповещений счетчиков PerfMon
- Мониторинг производительности процессора с Perfomance Monitor
- Группы сборщиков данных в PerfMon
- Создание Alert для мониторинга загрузки CPU
- Диагностика проблем с производительностью приложений на узлах сеансов удаленных рабочих столов с помощью счетчиков производительности Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts
- Включение новых счетчиков производительности и их использование Enable and use the new performance counters
- Счетчики, используемые в перегруженной системе Counters used in an overloaded system
- Параметры конфигурации Configuration Options
- Использование новых счетчиков со сторонними инструментами Using the new counters with non-Microsoft tools
- Поделитесь своим мнением Share your feedback
Мониторинг производительности 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 — не запрашивать скрытую копию письма.
Диагностика проблем с производительностью приложений на узлах сеансов удаленных рабочих столов с помощью счетчиков производительности Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts
Применяется к: Windows Server 2019, Windows 10 Applies to: Windows Server 2019, Windows 10
Плохая производительность приложений (когда приложения работают медленно или не отвечают) — одна из самых сложных проблем в плане диагностики. One of the most difficult problems to diagnose is poor application performance—the applications are running slow or don’t respond. В большинстве случаев диагностику начинают со сбора данных о ЦП, памяти, дисковых операциях ввода/вывода и других метриках, после чего пытаются выяснить причину проблемы с помощью таких средств, как Windows Performance Analyzer. Traditionally, you start your diagnosis by collecting CPU, memory, disk input/output, and other metrics and then use tools like Windows Performance Analyzer to try to figure out what’s causing the problem. К сожалению, в большинстве случаев эти данные не помогают определить основную причину, так как данные счетчиков потребления ресурсов часто существенно колеблются. Unfortunately, in most situations this data doesn’t help you identify the root cause because resource consumption counters have frequent and large variations. Из-за этого трудно сопоставить прочитанные данные с обнаруженной проблемой. This makes it hard to read the data and correlate it with the reported issue.
Счетчик задержки ввода данных пользователем совместим только с такими ОС: The User Input Delay counter is only compatible with:
- Windows Server 2019 или более поздней версии; Windows Server 2019 or later
- Windows 10 версии 1809 или более поздней. Windows 10, version 1809 or later
Счетчик задержки ввода данных пользователем может помочь быстро определить основную причину медленной производительности в рамках сеанса удаленного рабочего стола. The User Input Delay counter can help you quickly identify the root cause for bad end user RDP experiences. Этот счетчик измеряет, какой период времени ввод данных пользователем (например, с помощью мыши или клавиатуры) остается в очереди перед тем, как процесс его подхватит. Он работает в локальных и удаленных сеансах. This counter measures how long any user input (such as mouse or keyboard usage) stays in the queue before it is picked up by a process, and the counter works in both local and remote sessions.
На следующем рисунке показано примерное представление потока ввода данных пользователем, поступающего от клиента к приложению. The following image shows a rough representation of user input flow from client to application.
Счетчик задержки ввода данных пользователем измеряет максимальную разницу (в пределах интервала времени) между тем, когда ввод помещается в очередь и когда приложение получает его в традиционном цикле обработки сообщений, как показано на следующей блок-схеме. The User Input Delay counter measures the max delta (within an interval of time) between the input being queued and when it’s picked up by the app in a traditional message loop, as shown in the following flow chart:
Следует отметить, что этот счетчик сообщает максимальную задержку ввода данных пользователем в пределах настраиваемого интервала. One important detail of this counter is that it reports the maximum user input delay within a configurable interval. Это самое продолжительное время, за которое ввод поступает в приложение, что может повлиять на скорость выполнения важных видимых действий, таких как ввод. This is the longest time it takes for an input to reach the application, which can impact the speed of important and visible actions like typing.
Например, в приведенной ниже таблице задержка ввода данных пользователем в пределах этого интервала будет составлять 1000 мс. For example, in the following table, the user input delay would be reported as 1,000 ms within this interval. Счетчик сообщает наибольшую задержку ввода данных пользователем в пределах интервала, потому что пользователь рассматривает медленную реакцию как самое медленное время ввода (максимальное), а не как среднюю скорость всех вводов данных. The counter reports the slowest user input delay in the interval because the user’s perception of «slow» is determined by the slowest input time (the maximum) they experience, not the average speed of all total inputs.
Номер Number | 0 0 | 1 1 | 2 2 |
---|---|---|---|
Задержка Delay | 16 мс 16 ms | 20 мс 20 ms | 1000 мс 1,000 ms |
Включение новых счетчиков производительности и их использование Enable and use the new performance counters
Чтобы использовать эти новые счетчики производительности, необходимо сначала включить раздел реестра, выполнив следующую команду: To use these new performance counters, you must first enable a registry key by running this command:
Если вы используете Windows 10, версия 1809 или более поздняя, либо Windows Server, версия 2019 или более поздняя, вам не требуется включать раздел реестра. If you’re using Windows 10, version 1809 or later or Windows Server 2019 or later, you won’t need to enable the registry key.
После этого нужно перезапустить сервер. Next, restart the server. Затем откройте системный монитор и щелкните значок плюс (+), как показано на следующем снимке экрана. Then, open the Performance Monitor, and select the plus sign (+), as shown in the following screen shot.
После этого появится диалоговое окно «Добавить счетчики», где можно выбрать пункт User Input Delay per Process (Задержка ввода данных пользователем на процесс) или User Input Delay per Session (Задержка ввода данных пользователем на сеанс). After doing that, you should see the Add Counters dialog, where you can select User Input Delay per Process or User Input Delay per Session.
После того как вы выберете вариант User Input Delay per Process (Задержка ввода данных пользователем на процесс), в одноименном разделе отобразятся экземпляры выбранного объекта (другими словами, процессы) в формате SessionID:ProcessID
. If you select User Input Delay per Process, you’ll see the Instances of the selected object (in other words, the processes) in SessionID:ProcessID
Например, если Калькулятор выполняется в сеансе с идентификатором 1, вы увидите 1:4232 . For example, if the Calculator app is running in a Session ID 1, you’ll see 1:4232 .
Учитываются не все процессы. Not all processes are included. Вы не увидите процессы, запущенные как системные. You won’t see any processes that are running as SYSTEM.
Счетчик начинает отправку отчетов о задержке ввода данных пользователем сразу после того, как вы его добавите. The counter starts reporting user input delay as soon as you add it. Обратите внимание, что максимальный масштаб по умолчанию — 100 (мс). Note that the maximum scale is set to 100 (ms) by default.
Теперь давайте рассмотрим счетчик задержки ввода данных пользователем на сеанс. Next, let’s look at the User Input Delay per Session. Для каждого идентификатора сеанса есть экземпляры, и их счетчики показывают задержку ввода данных пользователем для любого процесса в указанном сеансе. There are instances for each session ID, and their counters show the user input delay of any process within the specified session. Кроме того, есть еще два экземпляра — «Макс.» (максимальная задержка ввода данных пользователем во всех сеансах) и «Средний» (средняя задержка во всех сеансах). In addition, there are two instances called «Max» (the maximum user input delay across all sessions) and «Average» (the average acorss all sessions).
В этой таблице представлен визуальный пример этих экземпляров. This table shows a visual example of these instances. (Те же сведения можно получить в системном мониторе, переключившись на тип графа «Отчет».) (You can get the same information in Perfmon by switching to the Report graph type.)
Тип счетчика Type of counter | Имя экземпляра Instance name | Сообщенная задержка (мс) Reported delay (ms) |
---|---|---|
Задержка ввода данных пользователем на процесс User Input Delay per process | 1:4232 1:4232 | 200 200 |
Задержка ввода данных пользователем на процесс User Input Delay per process | 2:1000 2:1000 | 16 16 |
Задержка ввода данных пользователем на процесс User Input Delay per process | 1:2000 1:2000 | 32 32 |
Задержка ввода данных пользователем на сеанс User Input Delay per session | 1 1 | 200 200 |
Задержка ввода данных пользователем на сеанс User Input Delay per session | 2 2 | 16 16 |
Задержка ввода данных пользователем на сеанс User Input Delay per session | Среднее Average | 108 108 |
Задержка ввода данных пользователем на сеанс User Input Delay per session | Макс. Max | 200 200 |
Счетчики, используемые в перегруженной системе Counters used in an overloaded system
Теперь давайте рассмотрим, что же отобразится в отчете, если производительность приложения снижена. Now let’s look at what you’ll see in the report if performance for an app is degraded. На следующей диаграмме приведены показатели пользователей, удаленно работающих в Microsoft Word. The following graph shows readings for users working remotely in Microsoft Word. В этом случае производительность сервера узла сеансов удаленных рабочих столов (RDSH) ухудшается по мере того, как входит большее количество пользователей. In this case, the RDSH server performance degrades over time as more users log in.
Вот что представляют линии на диаграмме: Here’s how to read the graph’s lines:
- Розовая линия показывает количество сеансов, в которые выполнен вход на сервере. The pink line shows the number of sessions signed in on the server.
- Красная линия показывает потребление ЦП. The red line is the CPU usage.
- Зеленая линия — это максимальная задержка ввода данных пользователем во всех сеансах. The green line is the maximum user input delay across all sessions.
- Синяя линия (отображается как черная на этой диаграмме) представляет среднюю задержку ввода данных пользователем во всех сеансах. The blue line (displayed as black in this graph) represents average user input delay across all sessions.
Можно заметить, что присутствует взаимосвязь между пиками потребления ЦП и задержкой ввода данных пользователем: задержка ввода данных пользователем повышается по мере увеличения потребления ЦП. You’ll notice that there’s a correlation between CPU spikes and user input delay—as the CPU gets more usage, the user input delay increases. Кроме того, по мере добавления в систему большего количества пользователей потребление ЦП приближается к 100 %, что приводит к более частым пикам задержки ввода данных пользователем. Also, as more users get added to the system, CPU usage gets closer to 100%, leading to more frequent user input delay spikes. Хотя этот счетчик очень полезен в случаях, когда серверу не хватает ресурсов, его также можно использовать для отслеживания задержки ввода данных пользователем, связанной с определенным приложением. While this counter is very useful in cases where the server runs out of resources, you can also use it to track user input delay related to a specific application.
Параметры конфигурации Configuration Options
При использовании этого счетчика производительности следует помнить, что он сообщает задержку ввода данных пользователем через определенный интервал — 1000 мс по умолчанию. An important thing to remember when using this performance counter is that it reports user input delay on an interval of 1,000 ms by default. Если задать для свойства интервала выборки счетчика производительности (как показано на следующем снимке экрана) другое значение, полученное значение будет неправильным. If you set the performance counter sample interval property (as shown in the following screenshot) to anything different, the reported value will be incorrect.
Чтобы устранить эту проблему, можно задать для следующего раздела реестра нужный интервал (в миллисекундах). To fix this, you can set the following registry key to match the interval (in milliseconds) that you want to use. Например, если мы изменим значение параметра Sample every x seconds (Выполнять выборку каждые x секунд) на 5 с, то для этого раздела нужно задать значение 5000 мс. For example, if we change Sample every x seconds to 5 seconds, we need to set this key to 5000 ms.
Если вы используете Windows 10, версия 1809 или более поздняя, либо Windows Server, версия 2019 или более поздняя, не нужно задавать параметр LagCounterInterval, чтобы исправить счетчик производительности. If you’re using Windows 10, version 1809 or later or Windows Server 2019 or later, you don’t need to set LagCounterInterval to fix the performance counter.
Мы также добавили несколько разделов, которые могут оказаться полезными, под тем же разделом реестра. We’ve also added a couple of keys you might find helpful under the same registry key:
LagCounterImageNameFirst — задайте для этого раздела значение DWORD 1 (значение по умолчанию (0) или раздел не существует). LagCounterImageNameFirst — set this key to DWORD 1 (default value 0 or key does not exist). В результате имена счетчиков изменятся на «Имя образа SessionID:ProcessId». This changes the counter names to «Image Name SessionID:ProcessId.» Например, «explorer «. For example, «explorer .» Это полезно, если нужно выполнить сортировку по имени образа. This is useful if you want to sort by image name.
LagCounterShowUnknown — задайте для этого раздела значение DWORD 1 (значение по умолчанию (0) или раздел не существует). LagCounterShowUnknown — set this key to DWORD 1 (default value 0 or key does not exist). В результате будут показаны все процессы, запущенные как службы или система. This shows any processes that are running as services or SYSTEM. Для некоторых процессов в качестве названия сеанса будет отображаться «?». Some processes will show up with their session set as «?.»
Вот что будет, если вы включите оба раздела: This is what it looks like if you turn both keys on:
Использование новых счетчиков со сторонними инструментами Using the new counters with non-Microsoft tools
Инструменты мониторинга могут использовать этот счетчик, как описано в руководстве Использование счетчиков производительности. Monitoring tools can consume this counter by Using Performance Counters.
Поделитесь своим мнением Share your feedback
Вы можете отправить отзыв об этом компоненте через Центр отзывов. You can submit feedback for this feature through the Feedback Hub. Выберите Приложения > Все другие приложения и добавьте»Счетчики производительности RDS — системный монитор» в заголовок публикации. Select Apps > All other apps and include «RDS performance counters—performance monitor» in your post’s title.