Cpu user time что это
Анализ счетчиков производительности CPU
Если вам интересны счетчики производительности Windows, рекомендую обратиться к основной статье тематики — Счетчики производительности.
Анализ счетчиков производительности CPU
Для начала хочу уточнить один момент — существует две группы счетчиков производительности процессора, это группы Процессор (Processor) и Сведения о процессоре (Processor Information). Обе они имеют разный набор счетчиков (подробнее читайте в статье Счетчики производительности процессора), но я буду рассматривать только те из них, которые присутствуют в обоих группах. То есть вы можете использовать любую группу на ваш выбор.
В первом случае полное название счетчика (на примере % Processor Time) будет иметь вид:
\Processor Information(_Total)\% Processor Time (русскоязычная версия — \Сведения о процессоре(_Total)\% загруженности процессора)
\Processor(_Total)\% Processor Time (русскоязычная версия — \Процессор(_Total)\% загруженности процессора)
Первым делом нужно для себя определить на какие именно счетчики обращать внимание в первую очередь. В случае с основными показателями производительности CPU главным счетчиком является % Processor Time. Именно с его показаний и нужно искать проблему. При этом, по моим наблюдениям, нормальной считается средняя нагрузка до 60%, нагрузка 85% и выше уже представляет из себя большую проблему. Учитывая тот факт, что даже на стресс-тестах загрузка ЦП находится в районе 95%, то для серверов в продакшене 85% — это критическая загруженность.
Норма % Processor Time — до 60%, критическая — 85% и выше
1. Смотрим показания % Processor Time и, допустим, в вашем случае нагрузка ЦП действительно близка к критической и нужно что-то делать. Увеличивать процессорную мощность спешить не нужно, для начала посмотрите другие счетчики и уже после этого делайте выводы.
2. Чтобы на всякий случай убедиться в корректности показаний % Processor Time, открываем счетчик % Idle Time и смотрим какие средние значения он имеет. Этот счетчик показывает % простоя ЦП, то есть % времени, в которое ваш процессор не выполнял никаких задач. Следуя логике, показания этого счетчика должны быть = 100 — % Processor Time.
Норма % Idle Time обратно пропорциональна % Processor Time и составляет не ниже 40%, критическое значение — ниже 15%
С % Idle Time все в порядке, но легче нам не стало, идем дальше.
Пришло время посмотреть что нам покажут счетчики % Privileged Time и % User Time.
3. Смотрим счетчик % Privileged Time — время работы в привилегированном режиме — и если он в среднем держится выше 10%, это повод задуматься.
Норма % Privileged Time составляет 20%
Стоит отметить, что норму для % User Time определить достаточно трудно, ведь этот счетчик говорит о полезной нагрузке, которую выполняет ваш сервер. Грубо говоря, счетчик отображает % времени ЦП, которое тратится на обработку данных приложений, которые вы и запустили. Учитывая тот факт, что % Processor Time = % User Time + % Privileged Time, то в идеале значения % User Time должны стремиться к % Processor Time, а доля % Privileged Time стремиться к 0. Но это в идеале, в реальности же никак не убрать ту нагрузку, которую генерирует ядро ОС (она как раз и составляет % времени работы в привилегированном режиме).
Предположим % Privileged Time действительно показывает неприличные значения и нам надо что-то с этим делать.
4. Самое время обратиться к счетчику % Interrupt Time. Он отображает % времени, которое ЦП тратит на обработку прерываний. В идеале значение должно стремиться к 0, но на практике это бывает редко. Чаще всего нормальные значения составляют меньше 1%.
Норма % Interrupt Time — 5%
Если вы заметили ненормальные показания счетчика % Interrupt Time, это может говорить о проблемах с оборудованием, которое является причиной генерирования большого количества прерываний. Вообще отслеживать значения счетчика рекомендуется сразу после изменения аппаратной конфигурации и в случае аномального увеличения количества прерываний, принимать какие-то меры (например подобрать драйверы, с которыми устройство ведет себя лучше всего). Чтобы подкрепить свои наблюдения, можно обратить внимание на счетчик Interrupts/sec. Он показывает абсолютные значения прерываний в секунду.
Норма Interrupts/sec на каждом процессоре своя, оптимальные значения нужно определять эмпирическим путем совместно с данными % Interrupt Time
Допустим проблема была в недавно установленной сетевой карте. Вы поставили драйверы и проблема ушла сама собой и значения % Processor Time вернулись в нормальный диапазон. А что, если у вас изначально была другая ситуация? Про исключения из озвученного выше сценария я расскажу ниже.
Исключения из правил
В норме ЦП не должен переходить в состояние C3, то есть показания % C3 Time должны быть = 0
Подкрепить ваши наблюдения поможет счетчик C3 Transitions/sec, показывающий абсолютные значения переходов в состояние C3 в секунду. Почему именно C3? Дело в том, что начиная с C3, выход из состояний занимает значительное время и ЦП может попросту заниматься не тем, чем должен. Тем не менее, бывают проблемы и с C1, C2. Есть мнение 2 , что работе всем известного сервера 1С Предприятие может очень сильно мешать переход в состояния пониженного энергопотребления и рекомендуют вообще отключать такую возможность на уровне BIOS вашего сервера (правда рекомендация касается C1E).
Постоянный мониторинг счетчиков % C1 Time, % C2 Time, C1 Transitions/sec, C2 Transitions/sec, C3 Transitions/sec на мой взгляд излишен, но периодически стоит обращать на них внимание.
1.б Ситуация аналогичная — показания счетчика % Processor Time идеальны (стабильно
Мониторинг использования 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 и интерпретировать их вывод.
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, даже если они будут медленными. В любом случае – залогом правильного решения будет детальный анализ утилизации процессоров.
В этой главе мы узнали как эффективно управлять системными ресурсами.
User CPU time vs System CPU time?
Could you explain more about «user CPU time» and «system CPU time»? I have read a lot, but I couldn’t understand it well.
4 Answers 4
The difference is whether the time is spent in user space or kernel space. User CPU time is time spent on the processor running your program’s code (or code in libraries); system CPU time is the time spent running code in the operating system kernel on behalf of your program.
User CPU Time: Amount of time the processor worked on the specific program.
System CPU Time: Amount of time the processor worked on operating system’s functions connected to that specific program.
The term ‘user CPU time’ can be a bit misleading at first. To be clear, the total time (real CPU time) is the combination of the amount of time the CPU spends performing some action for a program and the amount of time the CPU spends performing system calls for the kernel on the program’s behalf. When a program loops through an array, it is accumulating user CPU time. Conversely, when a program executes a system call such as exec or fork, it is accumulating system CPU time.
Not the answer you’re looking for? Browse other questions tagged cpu or ask your own question.
Linked
Related
Hot Network Questions
Subscribe to RSS
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
site design / logo © 2021 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2021.12.13.40988
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.
Анализ ключевых показателей производительности — часть 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 содержится детальное описание ключевых счетчиков. Ниже описаны наиболее важные счетчики производительности: