Счетчик производительности оборудования — Hardware performance counter

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

СОДЕРЖАНИЕ

Реализации

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

Одним из первых процессоров, реализовавших такой счетчик и соответствующую инструкцию RDPMC для доступа к нему, был Intel Pentium , но они не были задокументированы до тех пор, пока Терье Матисен не написал статью о их обратном проектировании в Byte в июле 1994 года.

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

Процессор	доступные счетчики HW
UltraSparc II	2
Pentium III	2
ARM11	2
AMD Athlon	4
IA-64	4
ARM Cortex-A5	2
ARM Cortex-A8	4
ARM Cortex-A9 MPCore	6
МОЩНОСТЬ4	8
Pentium 4	18

По сравнению с программными методами

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

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

Выборка на основе инструкций

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

AMD представила методы для устранения некоторых из этих недостатков. Например, в процессорах Opteron в 2007 году была реализована технология, известная как выборка на основе инструкций (или IBS). Реализация IBS от AMD предоставляет аппаратные счетчики как для выборочной выборки (передняя часть суперскалярного конвейера), так и для оперативной выборки (задняя часть конвейера). Это приводит к дискретным данным о производительности, связывающим удаленные инструкции с «родительской» инструкцией AMD64.

Оценка производительности ИТ-сервисов

Кнопка оценки производительности ИТ-сервисов – это мониторинг качества (производительности) предоставляемых ИТ-сервисов со стороны пользователей без использования систем класса Real User Monitor.

Упрощённая схема мониторинга производительности ИТ-сервисов при помощи Кнопки показана на рисунке (см. выше). Предполагается использование Кнопки Помощи ITSM (ранее: Красная Кнопка ITSM) и системы мониторинга ProLAN.

Читайте так же:

Счетчики бетар есть ли обратный клапан

Мониторинг производительности ИТ-сервисов

На компьютеры пользователей ИТ-сервиса устанавливается Кнопка Помощи ITSM. Это программный агент EPM-Agent Plus и, опционально, аппаратная кнопка – USB-девайс ProLAN-101. Пользователь имеет возможность использовать Кнопку Помощи ITSM для двух целей – для регистрации инцидента (обычное нажатие) и для отправки жалобы в Агрегатор Информации системы мониторинга (продолжительное нажатие около 2 секунд).

Жалоба пользователя

Вводится различение инцидента и жалобы пользователя. Инцидент – это нарушение в работе ИТ-сервиса, требующее, с точки зрения пользователя, немедленного реагирования Службы поддержки. Жалоба – это следствие снижения качества (прежде всего, производительности) ИТ-сервиса ниже комфортного для пользователя уровня, но ещё не требующего немедленного реагирования Службы поддержки.

Жалоба не регистрируется напрямую в Service Desk, но принимается Агрегатором Информации системы мониторинга и используется для отслеживания производительности ИТ-сервисов.

Метрики производительности ИТ-сервисов

Экспертная система Агрегатора Информации группирует жалобы по географическому положению пользователя, по бизнес-процессам, выполнявшимся пользователями в момент нажатия «красной кнопки», по подразделению, к которому относится пользователь. На основании этой группировки формируются метрики производительности ИТ-сервисов, оцениваемые и отслеживаемые системой мониторинга так же, как метрики здоровья ИТ-инфраструктуры.

/	Справочник пользователей
Справочник операций	/	Топы — Москва	Продавцы — Питер	Все — Сочи
	Работа в 1С	Метрика 1: Жалобы топов из Москвы на работу 1С	Метрика 4: Жалобы продавцов из Питера на работу 1С и SAP CRM	Метрика 6: Жалобы всех пользователей из Сочи на работу 1С и SAP CRM
	Работа в SAP CRM	Метрика 2: Жалобы топов из Москвы на работу SAP CRM
	Интернет	Метрика 3: Жалобы топов из Москвы на работу Интернет	Метрика 5: Жалобы продавцов из Питера и всех пользователей из Сочи на работу Интернет

Пример механизма формирования метрик производительности ИТ-сервисов

Оперативный мониторинг и отчёты

Окно оперативного мониторинга производительности ИТ-сервисов программы SLA-ON Operations

Метрики производительности ИТ-сервисов оцениваются по пятибалльной шкале. Это позволяет сотруднику ИТ-службы или бизнес-аналитику в режиме реального времени наблюдать за производительностью ИТ-сервисов в разрезе регионов, бизнес-приложений и бизнес-процессов при помощи специальных технических средств (программа SLA-ON Operations, см. рисунок).

Для каждой метрики производительности ИТ-сервисов устанавливается минимальная оценка, падение ниже которой означает критическое снижение производительности ИТ-сервиса, требующее немедленного вмешательства службы поддержки. При снижении оценки метрики в данный момент времени ниже минимальной оценки система мониторинга автоматически формирует Агрегированный Снимок Инцидента и отправляет его в Service Desk, где он регистрируется наряду с обычными Снимками Инцидента.

Оценка Производительности (цвет «индикатора»)	>/<	Пороговое значение	Пороговое значение Оценки Производительности для отправки Агрегированного Снимка Инцидента в Service Desk
Плохо (красный)	>	4
На грани (мигающий красный)	>	3
Требует внимания (желтый)	>	2
Допустимо (мигающий желтый)	>	1
Хорошо (зеленый)	<	1

Пример таблицы пороговых значений метрики производительности ИТ-Сервисов

Читайте так же:

Счетчик лейкоцитарной формулы крови 265х105х70

Подробнее

Отчёты

Жалобы, значения метрик и их оценки записываются Агрегатором Информации в консолидированную базу данных. Это позволяет производить не только оперативный мониторинг, но и ретроспективный анализ производительности ИТ-сервисов. Результаты оценки удовлетворённости пользователей предоставляются в виде тактических, оперативных и стратегических отчётов. Тактические отчёты выгружаются в виде xml-файлов, которые можно открывать и редактировать в Excel.

Примеры тактических отчётов, открытых в Excel, приведены ниже. В крайнем левом столбце перечислены фильтры, использовавшиеся при формировании отчёта.

Мониторинг производительности в реальном времени. Real-Time Performance Monitoring

Мониторинг производительности в реальном времени (real-time performance monitoring RPM) – функция маршрутизаторов и коммутаторов Juniper, которая позволяет операторам связи и их клиентам проводить точные измерения показателей производительности соединения между двумя точками на сети. Инструмент RPM позволяет конфигурировать и отправлять тестовые пакеты до определенной точки на сети и проводить анализ полученных результатов измерений для определения таких показателей, как потеря пакетов, круговая задержка, джиттер и др.

RPM обеспечивает контроль выполнения SLA услуг операторов связи. RPM, сконфигурированный на оборудовании, позволяет устройству определять производительность сети на основании показателей времени круговой задержки (RTT), пакетного джиттера (Delay Variation) и потери пакетов (Packet Loss). Эти значения измеряются и собираются с помощью активных RPM тестов с применением протоколов HTTP, ICMP, TCP и UDP в зависимости от конфигурации.

Тестовые RPM пакеты

Вы получаете RPM статистику о производительности сетевого соединения посредством отправки c устройства-генератора RPM тестовых пакетов до указанной точки на сети, идентифицированной IP-адресом или URL. Когда удаленное устройство получает пакет, оно генерирует сообщения-ответы и отправляет их устройству-генератору. Анализируя время прохождения к и от удаленного устройства или сервера, устройство-генератор может производить вычисление параметров производительности сети.

Устройство-генератор RPM отправляет следующие типы тестовых пакетов:

Запрос HTTP GET конечного URL
Запрос HTTP GET на метаданные конечного URL
Запрос ICMP-echo к конечному адресу (настройки по умолчанию)
Запрос временной метки ICMP к конечному адресу
Ping-пакеты UDP к удаленному устройству
Запросы временной метки UDP к удаленному устройству
Ping-пакеты TCP к удаленному устройству

Типы RPM тестирования по протоколам UDP и TCP требуют, чтобы удаленный сервер или сетевое устройство Juniper был сконфигурирован как RPM-ресивер, который генерирует ответы на приходящие тестовые пакеты.

Результаты RPM-тестов доступны в форме MIB-объектов по протоколу SNMP.

RPM-тесты

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

Период проведения тестов и интервалы отправки пакетов

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

Читайте так же:

Куда отправить поверку счетчиков

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

Измерение джиттера с аппаратными временными метками

Джиттер – это разница относительного времени доставки пакетов между двумя последовательными пакетами.

RPM позволяет устанавливать аппаратные временные метки следующим тестовым RPM для повышения точности измерения показателей задержки или джиттера:

ICMP ping
Временная метка ICMP ping
UDP ping
Временная метка UDP ping

Добавление временной метки происходит в то время, когда сетевое устройство инициирует процесс отправки тестового пакета (RPM-генератор), но только не на удаленном устройстве, которое является оконечным (RPM-ресивер).

Поддерживаемыми режимами инкапсуляциями временных меток в RPM-пакеты являются Ethernet (включая VLAN), синхронный PPP, и Frame Relay. Единственный поддерживаемый логический интерфейс представляет собой интерфейс IT-сервисов.

Результаты измерений RPM-тестов с аппаратными временными метками могут быть получены по протоколу SNMP.

Статистика RPM-тестов

По завершению каждого теста оборудование собирает и анализирует статистические данные о времени круговой задержки, количестве входящих и исходящих пакетов (только для ICMP-тестов с временными метками) и потере пакетов, как показано в таблице:

Круговая задержка

Минимальное время круговой задержки

Наименьшее значение времени круговой задержки от сетевого оборудования Juniper до удаленного устройства/сервера, измеренное в процессе проведения теста

Максимальное время круговой задержки

Наибольшее значение времени круговой задержки от сетевого оборудования Juniper до удаленного устройства/сервера, измеренное в процессе проведения теста

Среднее время круговой задержки

Усредненное значение времени круговой задержки от сетевого оборудования Juniper до удаленного устройства/сервера, измеренное в процессе проведения теста

Стандартное отклонение времени круговой задержки

Стандартное отклонение времени круговой задержки от сетевого оборудования Juniper до удаленного сервера, измеренное в процессе проведения теста

Разница между максимальным и минимальным значениями времени круговой задержки, измеренная в процессе проведения теста

Входящее и исходящее время (только для ICMP-оборудования с временными метками)

Минимальное время прямого прохождения пакета (egress)

Наименьшее значение времени односторонней задержки от сетевого оборудования Juniper до удаленного устройства/сервера, измеренное во время проведения теста

Максимальное время обратного прохождения пакета (ingress)

Наименьшее значение времени односторонней задержки от удаленного устройства/сервера до сетевого оборудования Juniper, измеренное во время проведения теста

Среднее время прямого прохождения пакета (egress)

Усредненное значение времени односторонней задержки от сетевого оборудования Juniper до удаленного устройства/сервера, измеренное во время проведения теста

Среднее время прямого прохождения пакета (egress)

Усредненное значение времени односторонней задержки от удаленного устройства/сервера до сетевого оборудования Juniper, измеренное во время проведения теста

Стандартное отклонение времени обратного прохождения пакета (ingress)

Стандартное значение времени отклонения односторонней задержки от сетевого оборудования Juniper до удаленного устройства/сервера, измеренное во время проведения теста

Читайте так же:

Счетчик энергомера кто производитель

Стандартное отклонение времени прямого прохождения пакета (egress)

Стандартное значение времени отклонения односторонней задержки от удаленного устройства/серверадо сетевого оборудования Juniper, измеренное во время проведения теста

Джиттер обратного прохождения пакета (ingress)

Разница между максимальным и минимальным значениями времени выхода, измеренная в процессе проведения теста

Джиттер прямого прохождения пакета (egress)

Разница между максимальным и минимальным значениями времени входа, измеренная в процессе проведения теста

Количество тестовых пакетов

Отправленные тестовые пакеты

Общее количество тестовых пакетов, отправленных в процессе проведения теста

Общее количество ответов, полученных в процессе проведения тестов

Процент отправленных пакетов, на которые не был получен ответ

Пороговые значения RPM и уведомления

Вы можете задавать пороговые значения для показателей круговой и односторонни (egress/ingress) задержек, а также для стандартного отклонения и джиттера, для каждого RPM-теста.

Если значение показателя превышает заданное пороговое значение, устройство генерирует системное сообщение и может отправить уведомление посредством SNMP-trap, на заданный Вами адрес.

RPM для BGP мониторинга

Управляя пиринговыми сетями, соединенными посредством BGP-протокола (Border Gateway Protocol), Вам, возможно, потребуется обнаружить наличие пути между сетевым оборудованием Juniper и его BGP соседями. Вы можете вручную проверить каждого BGP соседа с помощь ping-запросов, чтобы определить статус соединения, но этот метод не практичен, когда таких соседей у устройства большое количество.

Вы можете сконфигурировать на устройстве RPM-тесты, чтобы проводить мониторинг соседних устройств BGP и определять их статус доступности.

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

С помощью этого механизма вы можете посмотреть оценку производительности основных аппаратных средств – процессора, видеосистемы, оперативной памяти и жесткого диска. Эта оценка может меняться и зависит от свойств упомянутых устройств. При помощи компонента Счетчики и средства производительности можно также настраивать или запускать функции, влияющие на производительность системы в целом:

? настраивать планы электропитания;

? настраивать параметры индексирования;

? настраивать визуальные компоненты;

? запускать очистку жесткого диска;

? запускать дефрагментацию жесткого диска.

Что касается оценки производительности, то это понятие впервые появилось в Windows Vista. Смысл этой оценки сводится к тому, что любая программа, которая может запускаться на компьютере, имеет определенные требования к ресурсам компьютера. Вот эти требования и можно интерпретировать как оценку. Если оценка возможностей компьютера ниже, чем оценка, требуемая программой, последняя может отказаться работать на компьютере, чтобы избежать возможных сбоев. Именно поэтому чем выше оценка компьютера, тем больше можно быть уверенным в том, что нужная программа запустится и будет работать в полную силу, не испытывая никаких проблем с ресурсами.

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

Продолжение на ЛитРес

Счетчик производительности оборудования — Hardware performance counter