Cpu system time что это

pro4gl.ru

Управление загрузкой процессора

Управление загрузкой процессора

Все ресурсы влияют тем или иным образом на загрузку процессора. К примеру, медленные дисковые устройства заставляют CPU выполнять холостые циклы в ожидании завершения операции ввода/вывода. Смена контекста (context switch) аналогичным образом увеличивает время отклика системы.

Что такое загрузка процессора

Чтобы понять, чем занят процессор необходимо знать – из каких компонент состоит его загрузка. На UNIX-системах работу процессора разделяют на следующие компоненты:

На Windows-системах загрузку процессора разделяют на следующие компоненты:

Настройка операционной системы.

Любое время, потраченное на ожидание ввода-вывода кажется неопытному администратору нежелательным. Но, на самом деле, не все I/O wait являются поводом для беспокойства. Время I/O Wait возникает каждый раз, когда процессор выполнил свою работу и находится в ожидании других ресурсов : дисков или памяти. Это естественно – центральный процессор является быстрейшим из ресурсов и должен ждать отклика более медленных устройств. Если же ожидание ввода-вывода оказывает заметное влияние на систему, то это является причиной для беспокойства.

При настройке системы желательно (но необязательно) иметь всегда ненулевое значение Idle time (время простоя). Да, вполне возможно нагрузить под завязку двухпроцессорную систему на 100% полезной работой (иными словами мы будем иметь 100% User Time). Это не означает, что система имеет плохую производительность, напротив, она работает так быстро насколько может. При настройке производительности мы пытаемся перенести узкое место (bottleneck) на самый быстрый ресурс – CPU. Если процессоры на 100% заняты пользовательскими задачами, то система настроена просто прекрасно. Дальнейшее увеличение производительности возможно только при увеличении тактовой частоты или при добавлении новых ядер. Утилизацию процессора необходимо рассматривать только в совокупности показателей. В общих чертах, если время I/O Wait увеличивается, то совсем необязательно, что узким местом стала подсистема ввода-вывода. Если мы говорим об идеальных условиях, то достаточно иметь 70 % времени на пользовательские задачи (User Time), 20% – время системы (System Time), 0% – ожидание ввода-вывода (I/O Wait) и 10% – время простоя (Idle Time). Еще одной метрикой наблюдения является отсутствие 100 % загрузки CPU на пользовательские задачи, если, конечно, это не обычное поведение вашей системы. Такую нагрузку могут вызвать неконтролируемые процессы. Неконтролируемые процессы – это, в основном, клиентские процессы, главный отличительный признак которых – отсутствие присоединенных к себе терминалов (tty) и исполнение в режиме отличном от пакетного (-b).

Отношение User Time к System Time должно быть приблизительно как 3:1 на host-based системах, в то время как на системах клиент-сервер это время может быть ближе как 1.5:1. Если время, затраченное на пользовательские задачи ниже 20% от общего использования CPU и меньше времени системы, то такое отношение может изменяться в широких пределах. В некоторых случаях System Time больше User Time из-за плохого выделения ресурсов. Таким образом, во время увеличения User Time при настройке сервера следует стремиться к тому, чтобы System Time составляло треть или менее от пользовательского времени. Это легко увидеть, взглянув на ресурсы CPU в любом средстве мониторинга.

Иллюстрация 5 показывает пример информации отображаемой Performance Monitor

Время простоя CPU (CPU Idle Time)

Наличие Idle time может являться хорошим знаком. Это означает, что вашей системе есть куда расти. Необязательно, чтобы время простоя было всегда больше нуля. Если Idle Time равно нулю длительный период времени и нет существенного времени I/O Wait, то для полного понимания ситуации необходимо пристальнее взглянуть на работу CPU.

Например, посмотрите на глубину очереди CPU (cpu queue depth). Значение CPU queue depth показывает количество процессов в ожидании исполнения. Если в очереди всегда есть некоторое количество процессов, то необходимо предпринять один из следующих вариантов:

Если время I/O wait высокое и нет времени Idle Time, то необходимо повысить эффективность дисковой подсистемы (см главу 2 “Управление ресурсами OpenEdge”) – увеличить пропускную способность дисковой подсистемы или изменить временной график ваших вычислений. Если I/O Wait занимает 10 % или меньше и значение Idle Time не равно нулю, то необходимость в каких-либо действиях отсутствует.

Наблюдения за системой

Круглосуточный мониторинг за вашей системой всегда помогает принять решение при оптимизации загрузки процессора. Ваша система может выглядеть отлично в течение рабочего времени (пока вы видите, что происходит), но ночью могут быть серьезные проблемы производительности. Есть множество приложений, которые производят 70% своих вычислений в вечерние часы. Большинство систем выполняют в ночные часы совсем другие задачи, чем днем. Типичная система делает OLTP-транзакции с 9 утра до 5 вечера, производит закрытие дня с 7 вечера до 12 ночи и запускает большие “тяжелые” отчеты после полуночи.

Есть некоторые приёмы, которые вы можете использовать для более эффективного использования существующих ресурсов. К примеру, можно определить такое время суток, когда базе данных необходимо больше процессов APW (page writers); или запускать “тяжелый” отчет в ночные часы.

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

Использование OE Management для мониторинга производителоьности CPU

Информацию о CPU лучше разместить на странице My Dashboard для того, чтобы она все время была на виду. При настройке страницы My Dashboard вы можете выбрать CPU в пункте Other system resources to show, чтобы увидеть фрейм-viewlet со статистикой использования CPU.

Быстрый процессор или многопроцессорная конфигурация?

Итак, что же решить? Лучше всего – провести анализ вашего приложения и его использования. Например, если у вас большинство однопоточных задач, то выигрыш от быстрого процессора будет больше, даже за счет уменьшения количества CPU. А приложение с большим количеством ввода данных и малой долей однопоточных задач выиграет от наличия бОльшего количества CPU, даже если они будут медленными. В любом случае – залогом правильного решения будет детальный анализ утилизации процессоров.

В этой главе мы узнали как эффективно управлять системными ресурсами.

Источник

C/C++: как измерять процессорное время

КДПВ

P.S. Когда в статье написано «сегодня» или «сейчас», имеется ввиду «на момент выхода статьи», то есть, если я не ошибаюсь, март 2012. Ни я, ни автор не гарантируем, что это до сих пор так.
P.P.S. На момент публикации оригинал недоступен, но хранится в кэше Яндекса

Функции API, позволяющие получить процессорное время, использованное процессом, отличаются в разных операционных системах: Windows, Linux, OSX, BSD, Solaris, а также прочих UNIX-подобных ОС. Эта статья предоставляет кросс-платформенную функцию, получающую процессорное время процесса и объясняет, какие функции поддерживает каждая ОС.

Как получить процессорное время

Процессорное время увеличивается, когда процесс работает и потребляет циклы CPU. Во время операций ввода-вывода, блокировок потоков и других операций, которые приостанавливают работу процессора, процессорное время не увеличивается пока процесс снова не начнет использовать CPU.

Разные инструменты, такие как ps в POSIX, Activity Monitor в OSX и Task Manager в Windows показывают процессорное время, используемое процессами, но часто бывает полезным отслеживать его прямо из самого процесса. Это особенно полезно во время бенчмаркинга алгоритмов или маленькой части сложной программы. Несмотря на то, что все ОС предоставляют API для получения процессорного времени, в каждой из них есть свои тонкости.

Далее мы подробно обсудим все функции, тонкости и причины, по которым в коде столько #ifdef ‘ов.

Использование

Чтобы замерить процессорное время алгоритма, вызовите getCPUTime( ) до и после запуска алгоритма, и выведите разницу. Не стоит предполагать, что значение, возвращенное при единичном вызове функции, несет какой-то смысл.

Обсуждение

Каждая ОС предоставляет один или несколько способов получить процессорное время. Однако некоторые способы точнее остальных.

Каждый из этих способов подробно освещен ниже.

GetProcessTimes( )

На Windows и Cygwin (UNIX-подобная среда и интерфейс командной строки для Windows), функция GetProcessTimes( ) заполняет структуру FILETIME процессорным временем, использованным процессом, а функция FileTimeToSystemTime( ) конвертирует структуру FILETIME в структуру SYSTEMTIME, содержащую пригодное для использования значение времени.

Доступность GetProcessTimes( ): Cygwin, Windows XP и более поздние версии.

Получение процессорного времени:

clock_gettme( )

Однако, есть несколько тонкостей, затрудняющих использование этой функции в кросс-платформенном коде:

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

Доступность clock_gettime( ): AIX, BSD, Cygwin, HP-UX, Linux и Solaris. Но clock id на BSD и HP-UX нестандартные.

Доступность clock_getres( ): AIX, BSD, Cygwin, HP-UX и Linux, но не работает Solaris.

Доступность clock_getcpuclockid( ): AIX и Cygwin, не недостоверна на Linux.

Получение процессорного времени:

getrusage( )

На всех UNIX-подобных ОС, функция getrusage( ) это самый надежный способ получить процессорное время, использованное текущим процессом. Функция заполняет структуру rusage временем в секундах и микросекундах. Поле ru_utime содержит время проведенное в user mode, а поле ru_stime — в system mode от имени процесса.

Доступность getrusage( ): AIX, BSD, Cygwin, HP-UX, Linux, OSX, and Solaris.

Получение процессорного времени:

times( )

На всех UNIX-подобных ОС, устаревшая функция times( ) заполняет структуру tms с процессорным временем в тиках, а функция sysconf( ) возвращает количество тиков в секунду. Поле tms_utime содержит время, проведенное в user mode, а поле tms_stime — в system mode от имени процесса.

Внимание: Более старый аргумент функции sysconf( ) CLK_TCK устарел и может не поддерживаться в некоторых ОС. Если он доступен, функция sysconf( ) обычно не работает при его использовании. Используйте _SC_CLK_TCK вместо него.

Доступность times( ): AIX, BSD, Cygwin, HP-UX, Linux, OSX и Solaris.

Получение процессорного времени:

clock( )

На всех UNIX-подобных ОС, очень старая функция clock( ) возвращает процессорное время процесса в тиках, а макрос CLOCKS_PER_SEC количество тиков в секунду.

Заметка: Возвращенное процессорное время включает в себя время проведенное в user mode И в system mode от имени процесса.

Внимание: Хотя изначально CLOCKS_PER_SEC должен был возвращать значение, зависящее от процессора, стандарты C ISO C89 и C99, Single UNIX Specification и стандарт POSIX требуют, чтобы CLOCKS_PER_SEC имел фиксированное значение 1,000,000, что ограничивает точность функции микросекундами. Большинство ОС соответствует этим стандартам, но FreeBSD, Cygwin и старые версии OSX используют нестандартные значения.

Внимание: В Windows, функция clock( ) поддерживается, но возвращает не процессорное, а реальное время.

Доступность clock( ): AIX, BSD, Cygwin, HP-UX, Linux, OSX и Solaris.

Получение процессорного времени:

Другие подходы

Существуют и другие ОС-специфичные способы получить процессорное время. На Linux, Solarisи некоторых BSD, можно парсить /proc/[pid]/stat, чтобы получить статистику процесса. На OSX, приватная функция API proc_pidtaskinfo( ) в libproc возвращает информацию о процессе. Также существуют открытые библиотеки, такие как libproc, procps и Sigar.

На UNIX существует несколько утилит позволяющих отобразить процессорное время процесса, включая ps, top, mpstat и другие. Можно также использовать утилиту time, чтобы отобразить время, потраченное на команду.

На Windows, можно использовать диспетчер задач, чтобы мониторить использование CPU.

На OSX, можно использовать Activity Monitor, чтобы мониторить использование CPU. Утилита для профайлинга Instruments поставляемая в комплекте с Xcode может мониторить использование CPU, а также много других вещей.

Источник

Мониторинг использования CPU на сервере Linux

Объем памяти, размер кеша, скорость чтения и записи на диск, скорость и доступность вычислительной мощности – это ключевые элементы, влияющие на производительность любой инфраструктуры.

Данное руководство ознакомит с базовыми понятиями мониторинга CPU. Вы узнаете, как использовать утилиты uptime и top, чтобы узнать о нагрузке и использовании ЦП.

Требования

Основные понятия

Прежде чем приступить к работе с утилитами, нужно понять, как измеряется использование ЦП и к каким результатам нужно стремиться.

Загрузка и использование ЦП

Загрузка (CPU Load) и использование процессора (CPU Utilization) – два разных способа взглянуть на использование вычислительной мощности компьютера.

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

Использование ЦП оценивает исключительно занятость кассиров и не знает, сколько клиентов в очереди.

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

Загрузка ЦП – это длина очереди запланированных задач, включая те, что находятся в обработке. Задачи могут переключаться в пределах миллисекунд, поэтому один снапшот загрузки не так полезен, как среднее значение из нескольких снапшотов, взятых за определенный период времени. Потому загрузка ЦП часто представляется как среднее значение.

Загрузка процессора отображает спрос на процессорное время. Высокий спрос может привести к сбоям и ухудшению производительности.

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

Ненормированные и нормированные значения

В одной процессорной системе общая емкость всегда равна 1. В многопроцессорной системе данные могут отображаться двумя разными способами. Суммарная емкость всех процессоров рассчитывается как 100% независимо от количества процессоров, такое значение считается нормированным. Другой вариант предлагает считать каждый процессор как единицу, так что 2-процессорная система в полном объеме имеет емкость 200%, 4-процессорная система в полном объеме имеет мощность 400% и т. д.

Чтобы правильно интерпретировать загрузку или использование CPU, нужно знать количество процессоров на сервере.

Отображение информации о ЦП

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

В большинстве современных дистрибутивов Linux также можно использовать команду lscpu, которая отображает не только количество процессоров, но и архитектуру, имя модели, скорость и многое другое:

lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 2
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 63
Model name: Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz
Stepping: 2
CPU MHz: 1797.917
BogoMIPS: 3595.83
Virtualization: VT-x
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 30720K
NUMA node0 CPU(s): 0,1
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm vnmi ept fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat

Знание точного количества процессоров важно для интерпретации результатов тех или иных утилит.

Оптимальные значения загрузки и использования ЦП

Оптимальное значение использования ЦП зависит от того, какую работу должен выполнять сервер. Стабильно высокое использование процессора негативно влияет на отзывчивость системы. Часто приложениям и пакетным заданиям с интенсивными вычислениями необходим весь или почти весь объем ЦП. Однако, если система должна обслуживать веб-страницы или поддерживать интерактивные сеансы сервисов (например, SSH), тогда может понадобиться свободная вычислительная мощность.

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

Мониторинг ЦП

Существует множество инструментов для получения данных о состоянии ЦП системы. Мы рассмотрим две команды: uptime и top. Обе утилиты являются частью стандартной установки большинства популярных дистрибутивов Linux и обычно используются для исследования загрузки и использования ЦП.

Примечание: Следующие примеры выполнены на 2-ядерном сервере.

Утилита uptime

Команда uptime позволяет отследить загрузку процессора. Она может быть полезна, если система медленно реагирует на интерактивные запросы (вероятно, ей не хватает системных ресурсов).

Утилита uptime сообщает следующие данные:

uptime
14:08:15 up 22:54, 2 users, load average: 2.00, 1.37, 0.63

В этом примере команда была запущена в 14:08 на сервере, который работал почти 23 часа. При запуске uptime подключились два пользователя. Этот сервер имеет 2 процессора. За минуту до запуска команды средняя загрузка процессора была 2,00, что означает, что в течение этой минуты процессоры использовали в среднем две задачи, а ожидающих задач не было. Среднее значение загрузки з а5 минут указывает на то, что в течение некоторого интервала времени один из процессоров бездействовал около 60% времени. Среднее за 15 минут значение указывает на то, что было доступно больше времени обработки. Вместе эти три значения показывают увеличение загрузки за последние пятнадцать минут.

Утилита uptime сообщает полезные средние значения загрузки ЦП, но для того, чтобы получить более подробную информацию, нужно использовать top.

Утилита top

Как и uptime, утилита top доступна как в Linux, так и в Unix-системах, но помимо отображения средних значений нагрузки для заданных временных интервалов она предоставляет информацию о потреблении ЦП в реальном времени, а также другие полезные показатели производительности. Если uptime запускается и сразу завершает работу, top работает на переднем плане и регулярно обновляется.

Заглавный блок

Первые пять строк содержат сводную информацию о процессах на сервере:

Первая строка почти идентична выводу утилиты uptime. Здесь показаны средние значения за одну, пять и пятнадцать минут. Эта строка отличается от вывода uptime только тем, что вначале указывается утилита top и время последнего обновления данных.

Вторая строка предоставляет краткий обзор состояния задач: общее количество процессов, количество запущенных, спящих, остановленных и зависших процессов.

Третья строка говорит об использовании ЦП. Эти цифры нормируются и отображаются в процентах (без символа %), так что все значения в этой строке должны составлять до 100% независимо от количества процессоров.

Четвертая и пятая строки сообщают об использовании памяти и swap соответственно.

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

Давайте рассмотрим подробнее все компоненты строки CPU.

Таблица процессов

Все процессы, выполняемые на сервере, независимо от их состояния перечисляются под заглавным блоком вывода. Ниже приведены первые шесть строк таблицы процессов из предыдущего примера. По умолчанию таблица процессов сортируется по% CPU, поэтому в начале находятся процессы, которые потребляют больше CPU.

Столбец %CPU представлен как процентное значение, но он не нормируется, поэтому в этой двухъядерной системе общее количество всех значений в таблице процессов должно составлять до 200%, если оба процессора полностью используются.

Примечание: Если вы предпочитаете работать с нормированными значениями, вы можете нажать SHIFT + I, и отображение переключится с режима Irix в режим Solaris. Этот режим выводит ту же информацию, которая усредняется по всему количеству процессоров, так что используемая сумма не будет превышать 100%. Перейдя к режиму Solaris, вы получите краткое сообщение о том, что режим Irix выключен.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10081 8host 20 0 9528 96 0 R 50.0 0.0 0:49.18 stress
10082 8host 20 0 9528 96 0 R 50.0 0.0 0:49.08 stress
1439 root 20 0 223832 27012 14048 S 0.2 0.7 0:11.07 snapd
1 root 20 0 39832 5868 4020 S 0.0 0.1 0:07.31 systemd

Заключение

Теперь вы умеете работать с утилитами uptime и top и интерпретировать их вывод.

Источник

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

Если вам интересны счетчики производительности Windows, рекомендую обратиться к основной статье тематики — Счетчики производительности.

Счетчики производительности процессора — Описание

На среднестатистической операционной системе вы найдете две группы счетчиков производительности (не считая отдельно наборов счетчиков для Hyper-V), отвечающих за отслеживание метрик процессора. Это группы Процессор (Processor) и Сведения о процессоре (Processor Information). На первый взгляд группы очень похожи и вторая из них отличается лишь по количеству доступных счетчиков, которых там значительно больше. Отличие этих групп состоит в том, что вторая создана несколько позднее и рассчитана на поддержку значительно большего количества процессоров 1 :

In order to maintain compatibility for software accessing the performance counters as those were introduced more than a decade ago, the Windows development team decided to leave the old performance counters untouched and have those available with the old restriction of 64 processors and instead introduce a new collection of performance counters which will support more than 64 processors. The new collection shows up in Performance Monitor under ‘Processor Information’.

Таким образом, если у вас многопроцессорные системы, для вас есть смысл пользоваться именно группой Сведения о процессоре (Processor Information). Вот так выглядят полные списки счетчиков русской и английской версий ОС:

Рассмотрим их более подробно.

UPD: 05.08.2016

В каждом разделе в виде цитаты будет даваться описание счетчика, доступное в самой ОС. Может быть кому-то оно покажется более понятным и полезным.

% C1 Time, % C2 Time, % C3 Time — % времени C1, % времени C2, % времени C3

Эти счетчики отображают % времени, которое процессор находится в том или ином состоянии (C-State). Эти состояния характеризуются пониженным энергопотреблением, а также разным временем перехода в обычный рабочий режим (например 10нс для С1, 100нс для С2 и 50мкс для С3 2 ). Для высоконагруженных систем может быть плохим показателем, если процессор часто пытается перейти в состояния ниже С1, ведь для выхода из них нужен приличный временной интервал. Некоторыми состояниями можно управлять прямо из BIOS и если у вас нет цели максимально сильно сократить энергопотребление, есть вариант отключить саму возможность перехода (особенно это касается состояния C1E, которое рекомендуют отключать, например, на серверах 1С).

Как видно на рисунке выше, до запуска нагрузочного теста процессор большинство времени находился в состоянии C2 и в момент запуска нагрузки (загрузка ЦП на графике пошла резко вверх) % состояния С2 опустился фактически до 0 и ЦП максимум переходил в состояние С1, но не глубже.

‘% времени С1/С2/С3’ — доля времени, в течение которого процессор находится в ‘спящем режиме’ по питанию, называемом С1/С2/С3. ‘% времени С1/С2/С3’ — это часть общего времени простоя процессора. Это состояние позволяет процессору полностью сохранять весь контекст работы и быстро вернуться в режим полноценного функционирования. Не все компьютеры поддерживают режим С1/С2/С3.

Вывод: постоянное использование этих счетчиков для отслеживания работы ЦП будет излишним. Тем не менее на них нужно обратить внимание, если ваш процессор не обеспечивает требуемой производительности при небольшой нагрузке.

C1 Transitions/sec, C2 Transitions/sec, C3 Transitions/sec — C1-переходов/сек, C2-переходов/сек, C3-переходов/сек

Счетчики показывают количество событий перехода в указанное состояние в течение одной секунды. Время перехода в состояния глубже C1 сопряжено с увеличенными временными затратами на выход из этого состояния и если ваш ЦП при высокой (>50%) нагрузке часто бывает в режимах C2 или C3, это повод задуматься об аппаратном отключении этих состояний, если позволяет оборудование.

На скриншоте отображены абсолютные значения переходов в указанные состояния. Для наглядности был запущен стресс-тест, во время выполнения которого ЦП переходил только в состояние C1, но не глубже.

‘С1-переходов/сек/С2-переходов/сек/С3-переходов/сек’ — это скорость, с которой процессор переходит в ‘спящий’ режим по питанию С1/С2/С3. Процессор переходит в режим С1/С2/С3 тогда, когда он находится в режиме простоя и выходит из него по первому прерыванию. Этот параметр отображает разницу между значениями, наблюдавшимися между двумя последними выборками, поделенное на длительность интервала выборки.

% DPC Time — % времени DPC

Счетчик показывает % времени, которое процессор затратил на прием и обслуживание отложенного вызова процедур (Deferred Procedure Call — DPC). Поскольку вызовы DPC выполняются в привилегированном режиме (хоть и с меньшим приоритетом, чем обычные прерывания), показания этого счетчика являются частью общего % времени работы в привилегированном режиме. В любом случае значение счетчика % времени DPC не должно быть большим, в противном случае процессор является узким местом или существуют проблемы с ПО.

На графике выше % времени DPC обозначен красной линией и среднее значение составляет десятые доли процента, это вполне нормальный показатель.

% времени DPC — это доля времени, которое процессор был занят обработкой вызовов отложенных процедур (DPC — Deferred Procedure Call). Прерывания DPC имеют более низкий приоритет, чем обычные прерывания. % времени DPC является компонентом «% времени в привилегированном режиме», поскольку прерывания DPC выполняются в привилегированном режиме. Прерывания DPC подсчитываются отдельно от обычных прерываний и не входят в счетчики обычных прерываний. Этот счетчик отображает средний процент занятого времени во время интервала измерения.

Вывод: постоянное использование этого счетчика для отслеживания работы ЦП будет излишним, да и его ненормальное поведение у меня на практике не встречалось, даже при высокой общей нагрузке ЦП.

DPCs Queued/sec — Поставлено в очередь DPC/сек

Из названия видно, что этот счетчик отражает среднее количество прерываний DPC, поставленных в очередь в секунду. Фактически это можно назвать средней скоростью добавления в очередь. Об этом счетчике вы найдете достаточно мало информации. Данных об анализе его значений ещё меньше. Мне кажется, что показания счетчика исключительно субъективны и на процессорах разных поколений или даже эпох «нормальными» значениями могут быть величины, отличающиеся на порядки (или ещё больше).

«Поставлено в очередь DPC/сек» — это скорость, с которой отложенные вызовы процедур устанавливаются в очередь DPC для данного процессора. DPC — это прерывания, которые имеют более низкий приоритет, чем стандартные прерывания. Каждый процессор имеет свою собственную очередь DPC. Этот параметр измеряет скорость, с которой вызовы DPC помещаются в очередь, а не количество вызовов в очереди. Поэтому эта величина показывает разницу между значениями последних двух выборок, поделенную на длительность интервала выборки.

Вывод: малопригодный для обособленного анализа счетчик. Лучшим вариантом будет сравнение вместе с % DPC Time, при этом большие значения при небольшом % не должны вас пугать.

DPC Rate — Скорость DPC

Как и DPCs Queued/sec счетчик DPC Rate отражает скорость постановки прерываний DPC, только в этом случае принимается во внимание последнее взятое значение, а не усредненное. Нормальными также могут считаться совершенно разные показатели. Например где-то указывают на критический уровень в 20 3 , в то время как даже на несильно нагруженной системе у меня значений меньше 50 не бывает.

«Скорость DPC» — это скорость, с которой отложенные вызовы процедур помещаются в очередь процессора между прерываниями системного таймера. DPC — это прерывания, которые имеют более низкий приоритет, чем стандартные прерывания. Каждый процессор имеет свою собственную очередь DPC. Этот параметр измеряет скорость, с которой вызовы DPC помещаются в очередь, а не количество вызовов в очереди. Счетчик отображает последнюю измеренную величину, а не среднее значение.

Вывод: аналогично DPCs Queued/sec — малопригодный для обособленного анализа счетчик. Лучшим вариантом будет сравнение вместе с % DPC Time, при этом большие абсолютные значения при небольшом % не должны вас пугать.

% Interrupt Time — % времени прерываний

Счетчик отображает процент времени, которое процессор тратит на обработку прерываний от устройств, поскольку в этом режиме могут быть запущены только подпрограммы обслуживания прерываний (ISR, которые являются функциями драйверов устройств 4 ). Большие значения счетчика могут говорить о проблемах с оборудованием. В норме показания не должны выходить за 5% даже при значительной (>50%) нагрузке на ЦП. Значения в 20% уже очень подозрительны.

На графике выше % Processor Time (красная линия) сервера Exchange 2013. При этом значения счетчика % Interrupt Time составляют сотые доли процента от общей нагрузки процессора.

% времени прерываний — это доля времени выборочного интервала, которую процессор тратит на обработку аппаратных прерываний; эта величина является косвенным показателем активности устройств, формирующих аппаратные прерывания. Эта величина равна сумме значений ‘Процессор: % времени прерываний’ для всех процессоров на компьютере, деленная на число процессоров. DPC подсчитываются отдельно и не входят в состав общего счетчика прерываний. Эта величина является косвенным показателем активности устройств, формирующих аппаратные прерывания, таких как системного таймера, мыши, драйверов дисков, линий передачи данных, сетевых адаптеров и других периферийных устройств.

Вывод: важный показатель. При комплексном анализе производительности ЦП необходимо обязательно его учитывать.

Interrupts/sec — Прерываний/сек

В отличии от % Interrupt Time, счетчик показывает абсолютное значение, то есть количество прерываний в секунду. Поскольку прерывания принимаются от оборудования, высокие значения косвенно могут свидетельствовать о проблемах с устройствами или с их драйверами. Особенно актуальны показания счетчика после физического добавления нового устройства на сервер. Счетчик не учитывает прерывания DPC. В «голом» виде параметр анализировать смысла большого нет.

В таблице сверху 0,2% загрузки ЦП соответствует примерно два десятка тысяч прерываний в секунду. Замеры проведены на Core i7-4770 при средней загрузке (% Processor Time) ЦП 10%.

‘Прерываний/сек’ — средняя скорость, в событиях в секунду, с которой процессор получает и обслуживает аппаратные прерывания. Эта величина не включает отложенные вызовы процедур, которые подсчитываются отдельно. Эта величина является косвенным показателем активности устройств, формирующих аппаратные прерывания, таких как системного таймера, мыши, драйверов дисков, линий передачи данных, сетевых адаптеров и других периферийных устройств. Эти устройства обычно прерывают работу процессора при завершении своей работы или при возникновении необходимости обработки запроса. При этом обычное выполнение потока команд приостанавливается. Системный таймер обычно прерывает работу процессора каждые 10 миллисекунд, создавая ‘фон’ аппаратных прерываний. Поэтому эта величина отображает разницу между значениями последних двух выборок, поделенную на длительность интервала выборки.

Вывод: показания счетчика нужно анализировать вместе с % Interrupt Time и при большом значении последнего делать вывод о существовании каких-либо проблем. Если хотите привязать наблюдения именно к счетчику Interrupts/sec, то для начала нужно собрать историю показаний на отслеживаемом оборудовании и после этого эмпирически выставить пороговые значения, которые по вашему мнению будут свидетельствовать о проблемах. При этом на разном оборудовании пороговые значения должны быть разными, это ведь абсолютные значения, а не относительные. Радикально сократить количество прерываний можно с помощью параметра Win32PrioritySeparation 5 . Начните с максимального значения в 3F (в 16-ричной системе счисления) и понижайте при необходимости.

% Processor Time — % загруженности процессора

Процент времени, в которое ЦП выполняет инструкции, то есть занят какими-либо задачами. Счетчик включает в себя процессорное время, затрачиваемое на обработку аппаратных прерываний 6 :

Shows the percentage of elapsed time that this thread used the processor to execute instructions. An instruction is the basic unit of execution in a processor, and a thread is the object that executes instructions. Code executed to handle some hardware interrupts and trap conditions is included in this count.

Пример показаний счетчиков % Processor Time и % Idle Time:

На графике выше сумма показаний счетчиков составляет 100% процессорного времени, хорошо виден момент запуска нагрузочного теста.

% загруженности процессора — это процент времени, затраченного процессором на выполнение любого потока, кроме потока бездействия. Для вычисления этого значения измеряется процент времени, затраченного процессором на выполнение потока бездействия, а затем полученное значение вычитается из 100%. (У каждого процессора есть поток бездействия, на который расходуется время, если отсутствуют другие потоки, готовые к выполнению). Этот счетчик является основным индикатором активности процессора и показывает средний процент времени занятости за определенное время. Следует отметить, что учет использования ресурсов процессором выполняется через внутренние интервалы, равные тактам системных часов. По этой причине в современных быстрых процессорах % загруженности процессора может быть занижен, так как процессор может затрачивать много времени на обработку потоков между соседними тактами системных часов. Приложения таймера на основе рабочей нагрузки представляют один из примеров приложений, для которых наиболее вероятно неточное измерение занятости по причине того, что таймер получает сигнал сразу после обработки выбранного интервала.

Вывод: хоть это и самый элементарный для понимания счетчик, но все же он является самым главным. Начинать анализировать работу ЦП нужно именно с него. При небольших показаниях (менее 40% в среднем) % Processor Time браться за анализ других счетчиков ЦП не имеет никакого смысла. ЦП в данном случае бутылочным горлышком являться не будет.

% Idle Time — Процент времени бездействия

Название счетчика говорит само за себя и отражает он процент времени, в которое ЦП не выполнял никаких задач, попросту бездействовал.

«% времени бездействия» — доля времени, когда процессор простаивает в течение интервала выборки

Вывод: счетчик полезно использовать вместе с % Processor Time для исключения ошибок в показаниях последнего. При этом показания счетчика % Processor Time = 100 — % Idle Time и наоборот, что вполне логично. Ведь загрузка процессора на 80% фактически говорит о том, что все же 20% времени ЦП бездействует.

Average Idle Time — Среднее время простоя

Счетчик отображает усредненное за определенный промежуток время простоя ЦП в абсолютных значениях. О счетчике практически нет информации в интернете, также я не встречал, чтобы им вообще кто-то пользовался, поскольку всегда больше интересуют именно относительные значения.

Среднее время простоя — средняя продолжительность (в единицах по 100 нс) простоя между двумя последними снятиями показаний.

Вывод: вероятнее всего использовать счетчик есть смысл в каких-то узкоспециализированных задачах, пример которых мне, к сожалению, неизвестен.

% of Maximum Frequency — % от максимальной частоты

Отображает процент от максимальной частоты процессора. На мой взгляд счетчик более актуален для ноутбуков, но не для серверных или даже десктопных систем. Дело в том, что ЦП в простое очень часто не понижает частоту, а просто отключает ненужные ядра, оставляя активным одно на 100% частоте. По крайне мере я не видел, чтобы на сервере со средней ( Processor Frequency — Частота процессора

Отображает абсолютное значение текущей частоты процессора. Разумеется можно измерять частоту как процессора, так и каждого из его ядер. Лично мне это представляется бессмысленной затеей. Знать текущую частоту процессора полезно разве что так, для сведения.

Частота текущего процессора в мегагерцах.

Вывод: какой-либо явной потребности в показаниях счетчика Processor Frequency как мне кажется нет. Если все же хотите снимать его показания, рекомендую производить их анализ совместно со счетчиком % of Maximum Frequency.

% Performance Limit — % ограничения производительности

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

% ограничения производительности — это гарантированная производительность процессора в процентах от его номинальной производительности. Производительность может ограничиваться политикой питания Windows или платформой из-за бюджета питания, перегрева или других проблем с оборудованием.

Вывод: назначение счетчика до конца неизвестно. Если у кого-то есть данные о нем, буду рад информации.

% Processor Performance — % Производительность процессора

Ситуация аналогична счетчику % Performance Limit — данные мне найти не удалось. Видимо этот счетчик также как и % ограничения производительности отображает текущие значения по производительности.

% ограничения производительности — это гарантированная производительность процессора в процентах от его номинальной производительности. Производительность может ограничиваться политикой питания Windows или платформой из-за бюджета питания, перегрева или других проблем с оборудованием.

Вывод: назначение счетчика до конца неизвестно. Если у кого-то есть данные о нем, буду рад информации.

% Priority Time — % приоритетной загруженности

Счетчик отображает процент времени, которое затрачивается на обработку процессов, имеющих не низкий приоритет. На официальных ресурсах пишут следующее: значение счетчика вычисляется путем вычитания из 100% доли времени, которое процессор выполняет потоки с низким приоритетом или бездействующие потоки 7 :

This counter displays the average percentage of busy time observed during the sample interval excluding low priority background work. It should be noted that the accounting calculation of whether the processor is idle is performed at an internal sampling interval of the system clock tick.

Учитывая порядок вычисления значений этого счетчика, можно предположить, что его показания будут примерно равны или меньше значений счетчика % Processor Time.

% приоритетной загруженности — это процент времени, затраченного процессором на выполнение потоков, приоритет которых отличен от низкого. Для вычисления этого значения измеряется процент времени, затраченного процессором на выполнение потоков с низким приоритетом либо потока бездействия, а затем полученное значение вычитается из 100%. (У каждого процессора есть поток бездействия, на который расходуется время, если отсутствуют другие потоки, готовые к выполнению). Этот счетчик показывает средний процент времени занятости за определенное время за исключением обработки потоков с низким приоритетом в фоновом режиме. Следует отметить, что учет использования ресурсов процессором выполняется через внутренние интервалы, равные тактам системных часов. По этой причине % приоритетной загруженности может быть занижен, так как процессор может затрачивать много времени на обработку потоков между соседними тактами системных часов. Приложения таймера на основе рабочей нагрузки представляют один из примеров приложений, для которых наиболее вероятно неточное измерение занятости по причине того, что таймер получает сигнал сразу после обработки выбранного интервала.

Вывод: счетчик имеет второстепенную важность для общего анализа производительности ЦП, тем не менее может быть полезен в случае выяснения обстоятельств ненормального поведения процессора. Использовать в одиночку смысла большого нет, нужно анализировать данные обязательно в связке с % Processor Time.

% Privileged Time — % работы в привилегированном режиме

Счетчик отображает процент времени, которое процессор затрачивает на обработку запросов ядра, то есть выполняет код в привилегированном режиме. Все функции ОС работают именно в этом режиме. Теоретически не должно быть ситуации, когда работа в привилегированном режиме сжирает двухзначные доли процессорного времени. Если значение этого счетчика переваливает за 10% — это повод поискать где могут быть проблемы; значение в 20% уже выглядит крайне подозрительным.

На графике выше изображены счетчики % Processor Time (красный) и % Privileged Time (розовый) реального сервера 1С. % работы в привилегированном режиме даже на пиковых значениях не поднимается выше 10%.

‘% работы в привилегированном режиме’ — это доля времени, которое поток команд процессора потратил на исполнение кода в привилегированном режиме. При вызове системных служб Windows они часто исполняются в привилегированном режиме для того, чтобы получить доступ к критическим системным данным. Такие данные защищены от доступа потоков команд, исполняемых в пользовательском режиме. Вызовы к системе могут быть явными или неявными, например при ошибках вызова страниц памяти или обработке прерываний. В отличие от операционных систем предыдущих поколений, в дополнение к обычным способам защиты системы путем разделения пользовательских и привилегированных режимов работы, Windows использует границы процессов для защиты подсистем. При этом результаты работы Windows по обработке приложений может появляться в процессах других подсистем в дополнение к привилегированному времени процессов.

Вывод: достаточно информативный счетчик. При значениях выше 20% есть большой смысл начать копать глубже и проанализировать показания счетчиков % User Time, % Interrupt Time, % DPC Time. Повышенное внимание должна вызвать ситуация, когда показания счетчика начинают стабильно резко превышать среднестатистические значения, наблюдаемые ранее.

% User Time — % работы в пользовательском режиме

Если % Privileged Time говорит о времени, которое тратится на работу ОС и оборудования, то % User Time — это как раз та полезная нагрузка, для выполнения которой и куплен ваш сервер. Логично предположить, что % Processor Time как минимум является суммой работы ЦП в пользовательском и привилегированном режиме. В норме значения % User Time не должны выходить за 60% в среднем.

На графике выше % работы в пользовательском режиме обозначен зеленым цветом, красный и розовый — % Processor Time и % Privileged Time соответственно.

% работы в пользовательском режиме — это процент времени работы процессора, которое он находился в пользовательском режиме. (Пользовательский режим является ограниченным режимом работы процессора. В пользовательском режиме работают приложения, подсистемы обеспечения среды (например, Win32, POSIX) и интегрируемые подсистемы. Наоборот, привилегированный режим разработан для компонентов операционной системы и позволяет напрямую обращаться к аппаратуре и всей памяти. Операционная система переключает потоки приложений в привилегированный режим для доступа к службам операционной системы.) Этот счетчик отображает средний процент времени занятости процессора по отношению ко всему времени образца.

Вывод: анализировать счетчик необходимо как минимум совместно с % Privileged Time и бить тревогу, если разница между % User Time и % Processor Time составляет более трети в пользу последнего.

% Privileged Utility — % привилегированной полезной загрузки

Как минимум для меня малоизвестный счетчик, который, к тому же, встречается далеко не на каждой системе. Например в Windows Server 2008 R2 его нет, но в 2012/8 он присутствует. Судя по всему, счетчик отображает % полезной работы, выполненной в привилегированном режиме.

Привилегированная полезная загрузка — это объем работы, выполняемой процессором в привилегированном режиме, в процентах от объема работы, которую процессор выполнил бы, если бы функционировал с номинальной производительностью и никогда не простаивал. У некоторых процессоров этот показатель может превышать 100%.

Вывод: назначение счетчика до конца неизвестно. Если у кого-то есть данные о нем, поделитесь, пожалуйста.

% Processor Utility — % полезной загрузки процессора

Также один из «недавних» счетчиков, о принципе работы которого мне ничего не известно. Если смотреть на графики на разных системах, то показания этого счетчика практически всегда бывают больше % Processor Time. Поскольку значение счетчика больше реальной загрузки процессора, то вполне вероятно, что сам счетчик отображает чисто гипотетические значения и призван показать насколько эффективно используется ваш ЦП. То есть можно сделать вывод, что чем больше разница между % Processor Utility и % Processor Time, тем менее эффективно используется ваш процессор.

Полезная загрузка процессора — это объем выполняемой процессором работы в процентах от объема работы, которую процессор выполнил бы, если бы функционировал с номинальной производительностью и никогда не простаивал. У некоторых процессоров этот показатель может превышать 100%.

Вывод: назначение счетчика до конца неизвестно. Если у кого-то есть данные о нем, поделитесь, пожалуйста.

Clock Interrupts/sec — прерываний тактового генератора/с

Название говорит само за себя — счетчик отображает количество прерываний тактового генератора в секунду. Величина абсолютная, поэтому непонятно к чему привязать наблюдения. Счетчик встречается не на всех ОС.

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

Вывод: до конца непонятно какую пользу может принести счетчик в поиске проблем с ЦП.

Idle Break Events/sec — Событий прерываний простоя/с

Счетчик отображает количество событий в секунду, когда процессор выходил из состояния простоя. Насколько я понимаю, показания счетчика нужно анализировать совместно с % Idle Time и другими. На сайте Intel есть интересная статья 8 про анализ потребляемой ЦП мощности, в которой также упоминаются счетчики Idle Break Events/sec, Clock Interrupts/sec. Но эта статья была написана для мобильных платформ.

Событий прерываний простоя/с — средняя скорость в событиях в секунду, с которой процессор выходит из состояния простоя. Этот счетчик показывает разницу значений между двумя последними снятиями показаний, деленную на длительность интервала выборки.

Вывод: малопригодный для анализа производительности ЦП счетчик. На мой взгляд более информативными данными будут показания счетчиков C-State.

Parking Status — Состояние приостановки

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

Состояние приостановки определяет, выполнена или нет приостановка процессора.

Вывод: данные счетчика в большинстве случаев можно принять только к сведению. Чего-то большего из счетчика выжимать смысла нет.

Performance Limit Flags — Флаги ограничения производительности

Флаги ограничения производительности процессора говорят о причине снижения этой самой производительности. Интересный счетчик, жаль не удалось найти о нем какой-либо информации. Счетчик доступен с Windows 2012/8, в более ранних версиях системы его нет.

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

Вывод: к сожалению, информации о счетчике найти не удалось.

Processor State Flags — Флаги состояния процессора

Также информации найти не удалось. Счетчик доступен в том числе и на win2k8.

Вывод: флаги состояния процессора, как и флаги ограничения производительности, могут дать информацию о причинах неполадок.

Вывод

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

Счетчики первого порядка, на которые стоит обращать внимание в первую очередь:

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

Надеюсь статья была вам полезна. Оставляйте свои комментарии.

Источник