Неправильное использование процесса из расширенных событий работоспособности системы?

Недавно я работал над пониманием данных или метрик, которые хранятся в файле событий расширенного состояния системы.

Мы пытаемся реализовать сбор данных о показателях производительности с использованием работоспособности системы, как указано здесь.

Существуют отчеты, которые дают такие метрики, как загрузка ЦП, использование других процессов и т. Д., Которые собираются из события работоспособности системы с именем

scheduler_monitor_system_health_ring_buffer_recorded

Я не могу понять для некоторых из моих занятых серверов, почему поле «process_utilization», которое указано в отчете как загрузка ЦП SQL, чаще всего превышает 100. В пиковое время оно колеблется между 120-160 и из-за этого отчет всегда показывает процессор выше 100, хотя, когда я проверял монитор активности серверов, это никогда не происходило.

Я поднял эту проблему в Github, но, похоже, не исправить или ответить.

Поэтому мой вопрос будет

1. Как я могу получить точное число для использования ЦП SQL для моих серверов, используя записанный кольцевой буфер состояния системы?

2. Отчет также показывает счетчик для ниже 2 полей, рассчитанных для их отчета

1. 100-System_idle-process_utilization как OtherProcessUtil

2. 100-system_idle как SystemUtil

Для чего нужны / полезны эти OtherProcessUtil и SystemUtil ?

3. Я также вижу, что использование памяти каждый раз всегда отображается как 100. Это тоже не кажется правильным. Кто-нибудь это заметил?

Другие инструменты, такие как Idera и sentry [который я тестировал], не показывают загрузку ЦП выше 100% для тех же серверов. Я сделал параллельное сравнение для той же нагрузки.

Значения счетчиков% диска и процессора, превышающие 100%. Должны быть разделены на число процессоров или дисков, присутствующих в системе. Таким образом, 100% означает, что он использует 100% одного процессора. 250% будет означать, что он использует два с половиной процессора. Так что, если он сообщает 120%, посмотрите, эквивалентен ли он 120 / <количество процессоров>.

Обратите внимание, что последнее изменение в tigertools было в июне 2018 года. Вы можете проверить sqlwatch.io, так как он выглядит гораздо более активным проектом.

См. Social.msdn.microsoft.com/Forums/sqlserver/en-US/… и просто измените его на TOP (1), чтобы узнать текущее использование ЦП SQL.

- Тони Хинкл