Счётчики производительности

Часть 1. Чтение

Автор: Сергей Холодилов
The RSDN Group
Источник: RSDN Magazine #4-2003

Опубликовано: 24.02.2004
Версия текста: 1.0

Общая картина Структура данных о производительности Содержимое данных о производительности База имён Удалённый доступ Параметр lpValueName функции RegQueryValueEx All together now Код PCViewer Processor Protector

One, two, three, four,
Can I have a little more?
J.Lennon

Демонстрационный пример

«Счётчики производительности» (perfomance counters) – это расширяемый механизм сбора различной (в основном статистической) информации, заложенный в операционные системы линейки Windows NT, начиная с версии 3.1. Большая часть счётчиков доступна пользователю через оснастку (snap-in) Performance. О том, сколько всего интересного можно узнать, используя счётчики производительности, говорит тот факт, что примерно половина экспериментов, описанных в книге «Внутреннее устройство Windows 2000» Д.Соломона и М.Руссиновича, проводилась с использованием оснастки Performance. Кстати сказать, возможно чтение счётчиков и с удалённого компьютера.

Это мощный и гибкий механизм. Но, на мой взгляд, он неочевиден, громоздок и неудобен. Широкое практическое применение программистами представляется мне сомнительным. Однако есть несколько ситуаций, когда использование счётчиков производительности может быть оправдано:

• Вам нужно следить за каким-то параметром системы, недоступным через другие интерфейсы.
• Вы пишите какую-то сложную систему и хотите дать администратору возможность использовать стандартные механизмы для доступа к информации о состоянии этой системы (в принципе, можно использовать счётчики для обмена информацией внутри самой системы, но обычно это не самый простой путь ... мягко говоря).

Я считаю, что создание собственных счётчиков более интересно и полезно, но и более трудоёмко. Поэтому первая часть этой статьи описывает чтение данных существующих счётчиков производительности (всё равно считывать данные со счётчиков, хотя бы и своих, придётся) и морально подготавливает к созданию собственных счётчиков. Вторая посвящена собственно созданию.

Общая картина

Для получения значений счётчиков производительности нужно сделать примерно такой вызов:

res = RegQueryValueEx(
  HKEY_PERFORMANCE_DATA, 
  «...», 
  0, &type, 
  buffer, &size);

Особенности, отличающие этот код от обычного использования RegQueryValueEx:

• В качестве описателя ключа реестра используется HKEY_PERFORMANCE_DATA.
• Строка, используемая в качестве значения, не является обычным значением. Что это такое, объяснено ниже.
• Размер возвращаемых данных изменяется динамически, поэтому заранее предсказать необходимый размер буфера невозможно. Если размер буфера недостаточен, функция вернёт код ошибки ERROR_MORE_DATA. Обычно RegQueryValueEx вызывается в цикле с постепенным увеличением буфера.
• Если размер буфера оказался недостаточным, значение переменной size не меняется.

Но главное отличие – это, конечно, возвращаемые данные.

Структура данных о производительности

Данные, возвращаемые RegQueryValueEx, имеют чёткую иерархию.

На верхнем уровне находится весь блок данных в целом. Он описывается структурой PERF_DATA_BLOCK:

      typedef
      struct _PERF_DATA_BLOCK 
{
  ...
  // Размер всего блока данных
  DWORD     TotalByteLength; 
  // Размер структуры. Используется как смещение до начала первого «объекта типа».
  DWORD     HeaderLength;  
  // Количество «объектов типа», данные для которых есть в этом блоке.
  DWORD     NumObjectTypes;
  ...
} PERF_DATA_BLOCK, *PPERF_DATA_BLOCK;

На следующем уровне иерархии находятся «объекты типа» (object type; по-моему, их логично было бы называть «классами» или «типами», но обычно их называют объектами; далее и я буду называть их объектами). Они бывают двух видов:

• «одиночные» – объекты, для которых не существует понятия «экземпляр», так как их в принципе не может быть более одного (например, «System» или «Memory»).
• «экземплярные» (ну не придумал я другого слова...) – объекты, имеющие конкретные воплощения (например «Process», «Processor»). В данный момент времени экземпляр может быть один, или их может не быть вообще, это ничего не меняет, дело в принципе.

Основное логическое отличие между этими видами объектов заключается в том, что для «одиночных» объектов данные счётчиков относятся непосредственно к объекту, а для «экземплярных» данные относятся к экземпляру.

Объект описывается следующей структурой:

      typedef
      struct _PERF_OBJECT_TYPE 
{
  // Суммарный размер этого объекта, всех его счётчиков, экземпляров и их // данных. Используется как смещение до следующего объекта.
  DWORD TotalByteLength;  
  // Размер этой структуры и следующих за ней определений счётчиков. В случае// «одиночного» объекта это смещение до начала данных, в случае // «экземплярного» объекта – смещение до определения первого экземпляра.
  DWORD DefinitionLength; 
  // Размер этой структуры (смещение до начала определения счётчиков).
  DWORD HeaderLength;   
 ...
  // Количество счётчиков 
  DWORD NumCounters;    
 ...
  // Количество экземпляров. Признак «одиночного» объекта – значение // PERF_NO_INSTANCES (равное -1).
  LONG NumInstances;      
} PERF_OBJECT_TYPE, *PPERF_OBJECT_TYPE;

Далее идут «определения счётчиков». Их должно быть PERF_OBJECT_TYPE::NumCounters штук. Каждый счётчик представлен так:

      typedef
      struct _PERF_COUNTER_DEFINITION 
{
  // Размер этого определения счётчика. Т.е. смещение до следующего.
  DWORD ByteLength;
 ...
  // Смещение данных счётчика от начала блока данных объекта (в случае // «одиночного» объекта) или блока данных экземпляра (в случае // «экземплярного» объекта).
  DWORD CounterOffset;
} 
PERF_COUNTER_DEFINITION, *PPERF_COUNTER_DEFINITION;

После определений счётчиков у «одиночных» объектов находится блок данных. Он состоит из структуры PERF_COUNTER_BLOCK, и собственно значений счётчиков. Структура PERF_COUNTER_BLOCK:

      typedef
      struct _PERF_COUNTER_BLOCK 
{
  // Размер структуры, включая следующие за ней значения счётчиков.
  DWORD ByteLength; 
} 
PERF_COUNTER_BLOCK, *PPERF_COUNTER_BLOCK;

Данные счётчика находятся по смещению PERF_COUNTER_BLOCK::CounterOffset от начала этой структуры.

У «экземплярных» объектов всё несколько сложнее. За определениями счетчиков следуют «определения экземпляров», каждый со своим блоком данных. Блок данных имеет такую же структуру, что и блоки данных «одиночных» объектов. Определение экземпляра:

      typedef
      struct _PERF_INSTANCE_DEFINITION 
{
  DWORD ByteLength; // Размер этой структуры, т.е. смещение от её// начала до блока данных этого экземпляра.
  ...
} PERF_INSTANCE_DEFINITION, *PPERF_INSTANCE_DEFINITION;

Всё вместе выглядит примерно так:

Рисунок 1. Весь блок данных в целом.

Рисунок 2. «Одиночный» объект.

Рисунок 3. «Экземплярный» объект.

Содержимое данных о производительности

А теперь рассмотрим те же самые структуры, но с другой точки зрения.

      typedef
      struct _PERF_DATA_BLOCK {
  WCHAR      Signature[4];     // Сигнатура «PERF» в Unicode
  ...
  DWORD      Version;          // Версия, в Windows 2000/XP - 1
  DWORD      Revision;         // Ревизия, в Windows 2000/XP - 1
  DWORD      TotalByteLength;  // См. в предыдущем разделе
  DWORD      HeaderLength;     // См. в предыдущем разделе
  DWORD      NumObjectTypes;   // См. в предыдущем разделе
  ...
  SYSTEMTIME SystemTime;       // Системное время на момент получения данных
  ...
  DWORD      SystemNameLength; // Длина имени системы (в байтах)
  DWORD      SystemNameOffset; // Смещение имени системы от начала структуры;// имя хранится в Unicode
} PERF_DATA_BLOCK, *PPERF_DATA_BLOCK;

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

Объекты:

      typedef
      struct _PERF_OBJECT_TYPE 
{
  DWORD  TotalByteLength;      // См. в предыдущем разделе
  DWORD  DefinitionLength;     // См. в предыдущем разделе
  DWORD  HeaderLength;         // См. в предыдущем разделе
  DWORD  ObjectNameTitleIndex; // Индекс имени объекта в базе имён.
  ...
  DWORD  ObjectHelpTitleIndex; // Индекс описания объекта в базе имён. 
...
  DWORD  NumCounters;          // См. в предыдущем разделе
  ...
  LONG   NumInstances;         // См. в предыдущем разделе
  DWORD  CodePage;             // Кодовая страница. См. примечание // к PERF_INSTANCE_DEFINITION
  ... 
} 
PERF_OBJECT_TYPE, *PPERF_OBJECT_TYPE;

Базе имён посвящён следующий раздел. Если кратко, то поля ObjectNameTitleIndex и ObjectHelpTitleIndex позволяют получить текстовое имя объекта и его описание. Описание может оказаться полезным только в том случае, если планируется его выводить, а вот имя можно использовать при поиске нужного объекта (обычно, правда, поступают наоборот – сначала по имени получают индекс, а уже по индексу находят объект).

Счетчики:

      typedef
      struct _PERF_COUNTER_DEFINITION 
{
  DWORD ByteLength;            // См. в предыдущем разделе
  DWORD CounterNameTitleIndex; // Индекс имени счётчика в базе имён.
  ...
  DWORD CounterHelpTitleIndex; // Индекс описания счётчика в базе имён. 
  ...
  DWORD CounterType;           // Тип счётчика. Подробнее ниже.
  DWORD CounterSize;           // В некоторых случаях (зависит от типа) – // размер данных счётчика.
  DWORD CounterOffset;         // См. в предыдущем разделе
} 
PERF_COUNTER_DEFINITION, *PPERF_COUNTER_DEFINITION;

Самое интересное поле – это, конечно, CounterType. Оно определяет тип информации, содержащейся в счётчике, размер (или механизм вычисления размера) данных счётчика, манипуляции, которые необходимо произвести со значением счётчика перед использованием, и даже форму, в которой его нужно выводить.

В MSDN это поле уклончиво описано как комбинация различных значений (values). Именно значений, а не флагов, так как некоторые из битов этого поля являются флагами, а некоторые – нет. Те, которые «нет», отличаются тем, что логически они исключают друг друга, а их битовые маски пересекаются, поэтому проверять присутствие/отсутствие оператором «&» не получается. Схема такова:

      union CounterTypeMask
{
  DWORD dw;
  struct
  {
    unsignedint reserved1 : 8;
    unsignedint size      : 2; // размер данных счётчикаunsignedint type      : 2; // тип счётчикаunsignedint reserved2 : 4;
    unsignedint subtype   : 4; // подтип счётчикаunsignedint time      : 2; // подтипы таймеровunsignedint calc      : 6; // механизмы вычисления итогового значения, флагиunsignedint display   : 4; // как отображать
  };
};

Я приведу только значения, соответствующие полям size, type, и два значения поля subtype. Остальные менее интересны и более запутанны (некоторые – значительно более запутанны), если хотите, можете посмотреть их в MSDN.

Полноценный анализ поля CounterType в общем виде довольно сложен. Я, например, не только написать его не собрался, но даже и разобрался не со всеми вариантами. Но если вы не собираетесь писать свою оснастку Performance (да ещё и используя исключительно RegQueryValueEx…), то анализ этого поля вам нужно будет произвести только один раз, на этапе разработки приложения. В конце статьи есть пример такого анализа.

Экземпляры:

      typedef
      struct _PERF_INSTANCE_DEFINITION 
{
    DWORD           ByteLength;             // См. в предыдущем разделе
    DWORD           ParentObjectTitleIndex; // Если у этого объекта есть «родитель», // то это индекс имени объекта// родителя в базе имён. 
    DWORD           ParentObjectInstance;   // Номер экземпляра родителя.
    LONG            UniqueID;               // Идентификатор экземпляра или PERF_NO_UNIQUE_ID.
    DWORD           NameOffset;             // Смещение до начала имени экземпляра
    DWORD           NameLength;             // Длина (в байтах) имени экземпляра, 0, // если имени нет.
} PERF_INSTANCE_DEFINITION, *PPERF_INSTANCE_DEFINITION;

Поля ParentObjectTitleIndex и ParentObjectInstance позволяют установить отношения «родитель» - «ребёнок» для экземпляров. У экземпляров большинства объектов нет родителей, но, например, для потока (экземпляр объекта «Thread») родителем является его процесс (экземпляр объекта «Process»); для экземпляра объекта «Image» (образ исполняемого модуля) родитель – соответствующий экземпляр объекта «Process Address Space».

Поля UniqueID, NameOffset и NameLength позволяют определить имя экземпляра. Если UniqueID не равно PERF_NO_UNIQUE_ID (определено как -1), то экземпляры именуются по идентификаторам, и UniqueID – это как раз идентификатор. Иначе экземпляры именуются по именам, смещение имени от начала структуры указано в NameOffset, а длина имени – в NameLength.

База имён

База имён – это таблица соответствия между индексом имени/описания чего-либо и самим именем/описанием. Точнее, эти базы могут существовать для нескольких языков, причём по две для каждого – одна для имён, вторая для описаний. Хранится всё, как водится, в реестре, большими, слегка структурированными кусками данных... По этому поводу можно только слегка опечалиться.

И база имён, и база описаний находятся в значениях одного ключа реестра. Есть два варианта (они оба работают, вы можете выбирать любой, но если планируется работать под Windows NT 4.0, то посмотрите Q237304 и выберите первый):

1. Ключ HKEY_PERFORMANCE_DATA, значения «Counter XYZ» для имён и «Explain XYZ» для описаний.
2. Ключ «HKLM\Software\Microsoft\Windows NT\CurrentVersion\Perflib\XYZ», значения «Counter» и «Help».

Во всех случаях «XYZ» это трёхсимвольная строчка, содержащая «основную часть идентификатора языка» (primary language identifier) в шестнадцатеричном виде. Языком может быть либо английский, либо язык версии (не локализации, а именно версии; локализацию можно поменять из настроек Regional Options, поменять версию гораздо сложнее, я, например, не умею) Windows. Для английского «XYZ» будет «009», для русского «019». При использовании «009» строчки будут английскими, при использовании языка версии могут быть либо локализованными (если создатель соответствующего объекта позаботился об этом, подробнее во второй части статьи), либо английскими.

Базы хранятся в значениях типа REG_MULTI_SZ, то есть состоят из большого количества разделённых нулями строк, последняя строка завершается двойным нулём. Формат такой:

Индекс_1
Текст_1
Индекс_2
Текст_2
...

Здесь Индекс_X – строчка с десятичным представлением числа. Последовательные индексы совершенно точно не являются последовательными числами потому, что в базе имён все индексы (кроме первого) чётные, а в базе описаний – нечётные. Но это не значит, что они идут друг за другом через один – между ними могут быть дырки, в общем случае последовательность не обязательно везде возрастающая (скорее всего она будет возрастающей, но это никем не гарантируется).

В дополнение к этому, в параметрах «Last Counter» и «Last Help» (тип REG_DWORD) ключа «HKLM\Software\Microsoft\Windows NT\CurrentVersion\Perflib» хранятся максимальные значения индексов, использованных в базах имён и описаний соответственно.

Удалённый доступ

Поскольку всё хранится в реестре, для получения информации с удалённого компьютера (работающего под управлением Windows NT/2000/XP) можно использовать функцию RegConnectRegistry.

LONG RegConnectRegistry(
  LPCTSTR lpMachineName,
  HKEY hKey,
  PHKEY phkResult);

Параметры:

Вот так просто… всё было бы, если бы все пользователи были администраторами на целевой машине… Иногда это не так. В этом случае может помочь Q155363 (HOWTO: Regulate Network Access to the Windows NT Registry), Q146906 (HOWTO: How To Secure Performance Data in Windows NT) и несколько моих дополнений:

• Пользователь должен иметь право на чтение «HKLM\Software\Microsoft\Windows NT\CurrentVersion\Perflib\».
• Для чтения базы пользователь должен иметь право на чтение файлов «<Каталог Windows>\System32\perfcXYZ.dat» и «<Каталог Windows>\System32\perfhXYZ.dat». Эти файлы содержат соответствующие базы в формате «plain Unicode». Кстати, рядом лежат файлы «perfdXYZ.dat» и «perfiXYZ.dat», насколько я понял, в них «стандартная» часть базы.
• Значения счётчиков не хранятся в реестре, но в нём хранятся пути к библиотекам, которые нужно загрузить для получения этих значений. Поэтому пользователь должен уметь прочитать путь к dll (ну, и ещё кое-что) и загрузить эту dll. Пути и «ещё кое-что» хранятся в значениях ключа «HKLM\SYSTEM\CurrentControlSet\Services\<имя>\Performance», dll-и – там, куда указывает значение «Library» (если путь не полный, то dll лежит в «…\System32\»). Если пользователь не имеет прав на ключ или на dll, никаких ошибок не будет, он просто не увидит соответствующего объекта. Поэтому, если Вам необходимы значения счётчиков конкретного объекта, достаточно дать права только для одного ключа/dll.

Параметр lpValueName функции RegQueryValueEx

Здесь я просто приведу табличку из MSDN. Естественно, с некоторыми комментариями, половина из которых тоже взята из MSDN :)

All together now

Итак, вы хотите получить значение счётчика «Counter» объекта «Object» c компьютера «Computer». Последовательность действий:

• Получить HKEY_LOCAL_MACHNE либо HKEY_PERFORMANCE_DATA нужного компьютера – RegConnectRegistry(«Computer», HKEY_…, &hKey).
• Считать базу имён.

• Найти «Object» и «Counter», определить их индексы.

• Получить HKEY_PERFORMANCE_DATA нужного компьютера.
• Запросить данные для нужного объекта по индексу.
• Найти в полученных данных запрошенный объект (поле ObjectNameTitleIndex структуры PERF_OBJECT_TYPE должно совпадать с индексом).
• Найти нужный счётчик (поле CounterNameTitleIndex структуры PERF_COUNTER_DEFINITION должно совпадать с индексом).
• Прочитать его данные.

После получения данных о счетчиках (чтение базы имён в данном случае не считается) ключ HKEY_PERFORMANCE_DATA нужно закрыть. Но желательно делать это пореже. В том смысле, что лучше сделать это один раз в конце, а не каждый раз после обращения к RegQueryValueEx. Причина проста: для получения данных RegQueryValueEx загружает зарегистрированные в реестре dll-и. При закрытии HKEY_PERFORMANCE_DATA они могут быть выгружены, и при следующем запросе их придётся загружать заново.

Код

В качестве примера я написал две утилиты. Первая – скорее полезная, вторая – скорее забавная...

PCViewer

PCViewer –это утилита, позволяющая просматривать значения счётчиков производительности, их имена, типы и т.п. Она позволяет подключаться к другому компьютеру, выбирать используемую базу имён, формировать любые запросы. Выдаёт всю информацию, возвращаемую RegQueryValueEx (включая смещения и размеры).

Для упрощения перебора структур я написал три простых класса. Для работы с базой имён – ещё два. И один для получения информации от RegQueryValueEx. Эти классы сосредоточены в файлах (*.h и *.cpp) perfobjects, titledb (чтобы продемонстрировать все варианты доступа к базам имён, мне пришлось не слабо изуродовать этот класс, в файлах titledb лежит оригинальная версия, в titledb_for_sample – используемая в проекте), perfdata, все они лежат в каталоге Perf. Кроме них, в этом каталоге присутствуют два файла (опять *.h и *.cpp) countrhelpdb. Это обёртка вокруг классов, работающих с базой имён.

Остальное – пользовательский интерфейс, написанный с использованием WTL 3.1

Processor Protector

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

Для получения информации о процессоре и списка процессов используются фиксированные значения индексов – это стандартные объекты, для них можно.

Единственное, что может вызвать затруднение при просмотре кода – вычисление процента загрузки процессора по значению счётчика. Счётчик имеет следующий тип: PERF_SIZE_LARGE | PERF_TYPE_COUNTER | PERF_COUNTER_RATE | PERF_TIMER_100NS | PERF_DELTA_COUNTER | PERF_INVERSE_COUNTER | PERF_DISPLAY_PERSENT. Здесь:

• PERF_SIZE_LARGE – переменная типа LARGE_INTEGER.
• PERF_TYPE_COUNTER – значение только увеличивается.
• PERF_DELTA_COUNTER – «значением счётчика» считается разность двух последовательно полученных значений.
• PERF_COUNTER_RATE – для вычисления результата значение нужно поделить на время.
• PERF_TIMER_100NS – время измеряется в 100-наносекундных интервалах.
• PERF_INVERSE_COUNTER – после всего остального результат нужно инвертировать, под этим подразумевается вычитание из 1. Имеется в виду, что считаются моменты простоя процессора.
• PERF_DISPLAY_PERSENT – отображать в процентах. Видимо, при этом подразумевается необходимость домножить на 100. «Подразумевается» потому что в описании PERF_DISPLAY_PERSENT о необходимости умножения нет ни слова, но вот в формулах для счётчиков, отображаемых в процентах (кроме одного – PERF_PRECISION_OBJECT_TIMER) умножение на 100 присутствует.

Конечная формула выглядит так:

X = (1 – (value_2 – value1) / (time_2 – time_1) * frequency / 10000000) * 100 %

Где:

• value_X – значение счётчика
• time_X – время
• frequency – частота таймера (количество тиков в секунду)
• 10000000 – количество 100-наносекундных интервалов в секунду.

Что ж, можно считать, что теперь к созданию собственных счётчиков Вы готовы хотя бы морально :) Продолжение банкета – во второй части статьи.