performance limit utilization что это

Метрика загруженности процессора (CPU utiliztion) — это не то что вы думаете

Всем привет. Предлагаю вашему вниманию свой перевод поста «CPU Utilization is Wrong» из блога Брендана Грегга.

Как вы думаете, что значит нагрузка на процессор 90% на картинке ниже?

Вот что это значит на самом деле:

Stalled, то есть «приостановлено» значит, что в данный момент процессор не обрабатывает инструкции, обычно это означает, что он ожидает завершения операций ввода/вывода связанных с памятью (здесь и далее речь о RAM, а не дисковом вводе/выводе). Соотношение между «занято» и «приостановлено» (busy/stalled), которое я привел выше, это то что я обычно вижу в продакшене. Вероятно, что ваш процессор тоже большую часть времени находится в stalled состоянии, но вы об этом и не догадываетесь.

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

Что такое нагрузка на процессор на самом деле?

Метрика, которую мы называем нагрузкой на процессор (CPU utilization) на самом деле это «не-idle время», то есть время, которое процессор не выполняет idle-тред. Ядро вашей операционной системы (какую бы ОС вы не использовали) обычно следит за этим во время переключения контекста. Если не-idle тред запустился, а затем спустя 100 милисекунд остановился, то ядро посчитает, что процессор был использован в течение всего этого времени.

Эта метрика так же стара как и системы совместного использования времени (time sharing systems). В бортовом компьютере лунного модуля Apollo (это пионер среди систем совместного использования времени) idle-тред назывался «DUMMY JOB» и инженеры мониторили циклы выполняющие его в сравнении с реальными задачами, это было важной метрикой измерения нагрузки. (Я писал об этом ранее).

Что же с этой метрикой не так?

Со временем все становится только хуже. Долгое время производители процессоров увеличивали тактовые частоты своих процессоров быстрее чем производители памяти уменьшали задержки доступа к памяти (CPU DRAM gap). Примерно в 2005 году процессоры достигли частот в 3 GHz и с тех пор мощность процессоров растет не за счет увеличения тактовой частоты, а за счет большего числа ядер, гипертрединга и многопроцессорных конфигураций. Все это предъявляет еще больше требований к памяти. Производители процессоров пытались снизить задержки связанные с памятью за счет больших по размеру и более умных CPU-кешей, более быстрых шин и соединений. Но проблема со stalled-состоянием все еще не решена.

Как понять, что процессор на самом деле делает

Сделать это можно используя Performance Monitoring Counters (PMC-счетчики): хардверные счетчики, которые могут быть прочитаны с помощью Linux pref (пакет linux-tools-generic в Линуксе) и других утилит. Для примера понаблюдаем за всей системой в течение 10 секунд:

Ключевая метрика здесь instructions per cycle (insns per cycle: IPC, число инструкций за один цикл), которая показывает сколько в среднем инструкций было выполнено за каждый такт. Чем больше, тем лучше. В примере выше значение 0.78 кажется очень неплохим (нагрузка 78%?) до тех пор пока вы не узнаете, что максимальная скорость процессора это IPC 4.0. Такие процессоры называют 4-wide, это название пошло от особенностей пути извлечения/декодирования инструкций в процессоре (подробнее об этом в Википедии).

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

В облаках

Если вы работаете в виртуальном окружении, то вероятно у вас нет доступа к PMC-счетчикам, это зависит от поддержки этой фичи гипервизором. Я недавно писал о том, что PMC-счетчики теперь доступны в AWS EC2 в виртуальных машинах базирующихся на Xen.

Как интерпретировать и что делать

Если ваш IPC 1.0, то вероятно, вы ограничены числом инструкций, которые может выполнять процессор. Попробуйте найти способ уменьшить число выполняемых инструкций: уменьшить число ненужной работы, кешировать операции и т.п. CPU flame графы — отличная утилита для этих целей. С точки зрения тюнинга железа, попробуйте использовать процессор с большей тактовой частотой и большим числом ядер и гипертредов.

Для моих правил выше я выбрал значение IPC 1.0, почему именно его? Я пришел к нему из своего опыта работы с PMC-счетчиками. Вы можете выбрать для себя другое значение. Сделайте два тестовых приложения, одно упирающееся по производительности в процессор, другое — в память. Посчитайте IPC для них и возьмите среднее значение.

Что инструменты мониторинга производительности должны сообщать вам?

Другие причины почему CPU utilization вводит в заблуждение

Проблема со stalled-циклами может быть не только в задержках связанных с памятью:
— изменение температуры может влиять на приостановленность процессора,
— турбобуст может менять тактовую частоту процессора,
— ядро варьирует частоту процессора с определенным шагом,
— проблема с усреднением: 80% нагрузки в течение минуты скроет кратковременный всплеск до 100%,
— спинлоки: процессор нагружен, имеет высокий IPC, но приложение ничего не делает.

Заключение

Нагрузка на процессор (CPU utilization) это обычно неправильно интерпретируемая метрика, так как она включает циклы, потраченные на ожидание ответа от основной памяти, которые могут доминировать в современных нагрузках. Вы можете понять что на самом деле стоит за %CPU используя дополнительные метрики, включая число инструкций за цикл (IPC). Если IPC 1.0, то в скорость процессора. Я писал про IPC в своем предыдущем посте, в том числе написал и о использовании PMC-счетчиках, необходимых для измерения IPC.

Инструменты мониторинга производительности, которые показывают %CPU должны показывать PMC-счетчики, чтобы не вводить пользователей в заблуждение. Например, они могут показывать %CPU с IPC и/или число instruction-retired и stalled циклов. Вооруженные этими метриками разработчики и админы могут решить как правильнее тюнинговать их приложения и системы.

Источник

Не могу раскрыть потенциал Palit GeForce RTX 3080 Ti GameRock

Купил видеокарту, подключаю к компьютеру, корпус открыт, включаю киберпанк, все настройки на максимум, DLSS – качество, вертикальная синхронизация выключена, разрешение 2к, загрузка видео 70-80%. Процессор 70%. FPS 58.

Не понимаю, в чём проблема, почему видео не 99%? Почему FPS зажимается? Где-то бутылочное горлышко.

Включаю Метро исход. Такая же проблема, видео 60%, проц 50%, FPS 60-90.

Открываю GPU-Z. В разделе сенсоров у датчика «PerfCap Reason» (говорит, в какой лимит упёрлись) сплошная сине-зелёная полоса. Показывает, что достигнуты лимиты по vRel, Pwr. Где:

Pwr = Power. Indicating perf is limited by total power limit.

vRel = Reliability. Indicating perf is limited by reliability voltage.

Думаю, может настройки биоса кривые.

Через Afterburner настраиваю кривую часты и напряжения вручную. Вольтаж 962mv при частоте 1815 Mhz. Применяю. Увеличиваю Power Limit до 113% (максимальное значение).

Теперь GPU-Z говорит, что карта больше не упирается ни в какие лимиты (idle), но ситуация по загрузке и FPS не меняется.

Процессор i7-6800k (6 ядер). Оперативка 32 Gb от корсара (3000 Mhz). Windows 10 Pro лицензия с последними обновлениями. Драйвер видео 466.77.

Последнее предположение, что карту зажимает проц, но загрузка проца не 100% и даже не 90%. А всего 50-70.

Обратил внимание, что любое понижение настроек графики просто снижает нагрузку на видеокарту. FPS при это не растёт.

Источник

Анализ ключевых показателей производительности — часть 3, последняя, про системные и сервисные метрики

Мы заканчиваем публикацию перевода по тестированию и анализу производительности от команды Patterns&Practices о том, с чем нужно есть ключевые показатели производительности. За перевод спасибо Игорю Щегловитову из Лаборатории Касперского. Остальные наши статьи по теме тестирования можно найти по тегу mstesting

В первой статье цикла по анализу ключевых показателей производительности мы наладили контекст, теперь переходим к конкретным вещам. Во второй посмотрели на анализ пользовательских, бизнесовых показателей/метрик и показателей, необходимых к анализу внутри приложения. В этой, заключительной — про системные и сервисные (в т.ч. зависимых сервисов) метрики.
Итак,

Системные метрики.

Системные метрики позволяют определять, какие системные ресурсы используются и где могут возникать конфликты ресурсов. Эти метрики направлена на отслеживание ресурсов уровня машины, таких как память, сеть, процессор и утилизация диска. Эти метрики могут дать представление о внутренних конфликтах лежащих в основе компьютера.
Вы также можете отслеживать данные метрики для определения аспектов производительности – нужно понимать, если ли зависимость между системными показателями и нагрузкой на приложение. Возможно, вам потребуются дополнительные аппаратные ресурсы (виртуальные или реальные). Если при постоянной нагрузке происходит увеличение значений данных метрик, то это может быть обусловлено внешними факторами — фоновыми задачами, регулярно-выполняющимися заданиями, сетевой активностью или I/O устройства.

Как собирать
Вы можете использовать Azure Diagnostics для сбора данных диагностики для для отладки и устранения неполадок, измерения производительности, мониторинга использования ресурсов, анализа трафика, планирования необходимых ресурсов и аудита. После сбора диагностики ее можно перенести в Microsoft Azure Storage для дальнейшей обработки.

Другой способ для сбора и анализа диагностических данных — это использование PerfView. Этот инструмент позволяет исследовать следующие аспекты:

Изначально PerfView был предназначен для локального запуска, но теперь он может быть использован для сбора данных из Web и Worker ролей облачных сервисов Azure. Вы можете использовать NuGet-пакет AzureRemotePerfView для установки и запуска PerfView удаленно на серверах ролей, после чего скачать и проанализировать полученные данные локально.
Windows Azure Diagnostics и PerfView полезны для анализа используемых ресурсов “постфактум”. Однако, при применении таких практик как DevOps, необходимо мониторить “живые” данные производительности для обнаружения возможных проблем производительности еще до того, как они произойдут. APM-инструменты могут предоставлять такую информацию. Например, утилиты Troubleshooting tools для веб-приложений на портале Azure могут отображать различные графики, показывающие память, процессор и утилизацию сети.

На портале Azure есть “health dashboard”, показывающий общие системные метрики.

Аналогичным образом, панель Diagnostic позволяет отслеживать заранее настроенный набор наиболее часто используемых счетчиков производительности. Здесь вы можете определить специальные правила, при выполнении которых оператор будет получать специальные нотификации, например, когда значение счетчика сильно превысит определенное значение.

Веб-портал Azure может отображать данные о производительности в течении 7 дней. Если вам нужен доступ данных за более длительный период, то данные о производительности нужно выгружать напрямую в Azure Storage.
Websites Process Explorer позволяет вам просматривать детали отдельных процессов запущенных на веб-сайте, а также отслеживать корреляции между использованием различных системных ресурсов.

New Relic и многие другие APM имеют схожие функции. Ниже приведено несколько примеров.

Мониторинг системных ресурсов делится на категории, которые охватывают утилизацию памяти (физической и управляемой), пропускную способность сети, работу процессора и операции дискового ввода вывода (I/O). В следующих разделах описано, на что следует обратить внимание.

Использование физической памяти

Существует две основные причины ошибки OutOfMemory – процесс превышает выделенное для него пространство виртуальной памяти либо операционная система оказывается неспособной выделить дополнительную физическую память для процесса. Второй случай является самым распространенным.

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

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

Многие APM-инструменты предоставляют сведения об использовании процессами системной памяти без необходимости глубокого понимания о принципах работы памяти. На графике ниже показана пропускная способность (левая ось) и время отклика (правая ось) для приложения, находящегося под постоянной нагрузкой. Примерно после 6 минут производительность внезапно падает, и время отклика начинает “прыгать”, по прошествии нескольких минут происходит показателей.

Результаты нагрузочного тестирования приложения

Записанная с помощью New Relic телеметрия показывает избыточное выделение памяти, которое вызывает сбой операций с последующим восстановлением. Использованная память растет за счет файла подкачки. Такое поведение является классическим симптомом утечки памяти.

Телеметрия, показывающая избыточное выделение памяти

Примечание: В статье Investigating Memory Leaks in Azure Web Sites with Visual Studio 2013 содержится инструкция, показывающая как использовать Visual Studio и Azure Diagnostics для мониторинга использования памяти в веб-приложении в Azure.

Использование управляемой памяти

.NET приложения используют управляемую память, которая контролируется CLR (Common Language Runtime). Среда CLR проецирует управляемую память на физическую. Приложения запрашивают у CLR управляемую память, и CLR отвечает за выделение требуемой и освобождение неиспользуемой памяти. Перемещая структуры данных по блокам, CLR обеспечивает компоновку этого типа памяти, уменьшая тем самым фрагментацию.

Управляемые приложения имеют дополнительный набор счетчиков производительности. В статье Investigating Memory Issues содержится детальное описание ключевых счетчиков. Ниже описаны наиболее важные счетчики производительности:

Источник

Thread: GFX72VM GPU Perf Limiter is always on UTILIZATION

Thread Tools

Search Thread

Display

GFX72VM GPU Perf Limiter is always on UTILIZATION

I bought a few months ago a GFX72VM which is working very well for me, however, after I performed a clean installed I noticed that the gaming center (1.0.12) always has the GPU Perf Limiter Utilization.

Prior to that, every time I paused a game and checked the gaming centre I could see the label change.

I performed a window factory reset which effectively erased all the partitions previous data so I cannot confirm which software I had before.

Thank you for any advice.

To be honest it’s pretty much what you should see from my understanding. It basically means the GPU is downclocking because the GPU isn’t being utilised. Run the sensor screen in GPU-Z and set each value to ‘max’. Then whilst keeping GPU-Z running start playing a game for 5 minutes. Then close the game and look at GPU-Z. It will show you the maximum GPU usage and click speeds during the gaming session so you can see the GPU utilisation. Additionally you can move your mouse over the ‘PerfCap Reason’ timeline to see if it is throttled for any reason other than utilisation. Hope this helps.

Sent from my Nexus 6 using Tapatalk

Thank you very much for the advice. I had not heard about this tool.

I did what you said this is during light load:

https://www.dropbox.com/s/jr8uz7wdz7. _load.png?dl=0

And this is after playing. more than 5 minutes I am afraid .

https://www.dropbox.com/s/ktuifdr4qc. _load.PNG?dl=0

I saved a log and I during perf utilization it is either on 16 (basic load) and during gaming it goes to 1 sometimes. I think these are the codes meaning:

/*!
* Power. Indicating perf is limited by total power limit.
*/
NV_GPU_PERF_POLICY_ID_SW_POWER = 1,
/*!
* Utilization. Indicating perf is limited by GPU utilization.
*/
NV_GPU_PERF_POLICY_ID_SW_UTILIZATION = 16,

Do you think this is right?

I’m moving house today so won’t get time time for a few days to check my G752VT but you GPU temps get very high. Have you overclocked your GPU?

Pretty sure the Power perf limit means you’ve reached your power target. But looking at the sensor screen yr click speeds and GPU load all take a dive at one point but don’t seem to show a corresponding change in the Per Limiter.

Sent from my Nexus 6 using Tapatalk

Источник