cpu avg что это такое
Load average
Наблюдая выводы таких команд, как top, htop, uptime, w и, возможно, других, пользователь наверняка обращал внимание на строку load average:
Расширяя обсуждение в «Общем обзоре стандартных средств наблюдений за системой», попробуем разобрать смысл этих чисел. Итак, проще говоря, числа отражают число блокирующих процессов в очереди на исполнение в определенный временной интервал, а именно 1 минута, 5 минут и 15 минут, соответственно. Понятие блокирующих процессов обычно хорошо освещают в последнее время, когда рассказывают о nginx. 🙂 В данном случае, блокирующий процесс — это процесс, который ожидает ресурсов для продолжения работы. Как правило, происходит ожидание таких ресурсов, как центральный процессор, дисковая подсистема ввода/вывода или сетевая подсистема ввода/вывода.
Высокие значения показателей load average говорят о том, что система не справляется с нагрузкой. Если речь идет о целевом сервере, работающем под высокой нагрузкой, то обычно полезно провести тонкую настройку операционной системы (сетевая подсистема, ограничение на количество одновременно открытых файлов и тому подобное). Высокая загрузка также может быть вызвана аппаратными проблемами, например, выходом из строя накопителя.
Для диагностики обратимся к другим полезным данным, предоставляемым выводом top. Строка Cpu(s) содержит информацию о распределении процессорного времени. Первые два значения непосредственно отражают работу CPU по обработке процессов:
Затяжные высокие (99-100%) показатели указывают на ЦП как на узкое место.
Параметр wa говорит о простое, связанным с вводом/выводом:
Выше 80% считается не совсем нормальным и явно указывает нам на то, что процессор проводит очень много времени в ожидании ввода/вывода (обычно это означает, что выходит из строя HDD или NIC).
Высоких uptime, низких load average, ну и конечно же удачи! 🙂
Linux: CPU Load – когда пора волноваться или что значит Load Average
load average: 0.09, 0.05, 0.01
Большинство людей знают, что обозначают эти цифры: они отображают среднюю нагрузку за определённое время (1, 5 и 15 минут), и знают, что чем меньшее значение – тем лучше. Большие же значения означают какие-то проблемы с нагрузкой на процессор. Но – какой порог? как выглядит “хорошее” и “плохое” значение Load Average? Когда начинать беспокоиться – а когда пора уже паниковать и срочно фиксить проблему?
Для начала – давайте рассмотрим, что именно обозначает Load Average. Начнём с простого примера – машина с одноядерным процессором.
Пример с движением по дороге
Одноядерный процессор можно представить себе как дорогу с однополосным движением. Представьте себе, что вы – оператор моста, по которому проходит эта дорога. Иногда движение по ней такое интенсивное, что машины выстраиваются в очередь для переезда. Вы хотите, что бы водители знали – какова скорость прохождения машин по вашему мосту. Самое простое решение – определить, сколько машин уже ожидают очереди на переезд моста: если машин в очереди нет – то водители будут знать, что могут проехать без проблем, а если машины скапливаются в очереди на подъезде к мосту – водители будут видеть, что им придётся простоять в этой очереди.
И так, оператор – какую систему измерения вы выберете? Как на счёт такой:
= load of 0.50
= load of 1.00
= load of 1.70
Это пример того, чем является загрузка процессора. “Машины” тут – процессы, занимающие процессорное время (“переезжают мост“), или стоящие в очереди на подъезде к нему. UNIX считает загрузку, как “длина в очереди на выполнение“: сумма процессов, которые в настоящие момент выполняются + количество процессов в очереди на обработку:
Как оператор моста, вы бы хотели, что бы машины (процессы) никогда не стояли в очереди. Так же и ваш процессор, в идеале, должен оставаться ниже 1.00. Так же, вы можете быть спокойны, если иногда возникают пики немного выше 1.00 – но вы должны начинать волноваться, если это происходит постоянно.
Так что – Load Average 1.00 является идеальным показателем?
Не совсем. Проблема нагрузки 1.00 в том, что у вас не остаётся “просвета” (запаса). На практике, многие системные администраторы придерживаются оптимального значения в 0.70:
А как на счёт многоядерных процессоров? У меня Load Average 3.00 – но всё работает отлично!
У вас четырёхъядерный процессор? Тогда – Load Average в 3.00 совершенно нормальное значение.
На многоядерных процессорах значение LA взаимосвязано с количеством процессоров. Использование на 100% отображается как 1.00 на одноядерной системе, 2.00 на двухъядерной, 4.00 на четырёх и так далее.
Если мы вернёмся к аналогии с мостом, то 1.00 значит, что одна полоса движения на мосту полностью занята. На мосту с одной полосой – это и будет 100% его “пропускной способности”. На двухполосном мосту – это уже 50%, т.к. только одна полоса занята полностью – но есть ещё одна, полностью свободная.
То же самое и с процессором – нагрузка в 1.00 будет 100% на одноядерной системе, а на двухъядерной – значение 2.00 будет 100% нагрузки.
Многоядерность vs многопроцессорность
Раз уж мы затронули эту тему – давайте поговорим о разнице между многоядерными и многопроцессорными системами. С точки зрения производительности – равна ли машина с одним двухъядерным процессоров – машине с двумя процессорами по одному ядру? Грубо говоря – да. Есть много тонкостей, связанных с кешированием, передачей процессов между процессорами и так далее. Несмотря на это, в целях вычисления итоговой нагрузки на процессор(ы) – важно общее количество ядер, независимо от того, на сколько физических процессоров они распределены.
Это приводит нас к ещё двум правилам:
Подведём итог
Давайте посмотрим на Load Average в выводе утилиты uptime :
Это двухъядерный процессор, значит у нас имеется большой запас производительности, и можно даже не задумываться о нагрузке, пока значение не достигнет хотя бы 1.7.
Далее, как на счёт остальных значений? 0.65 значит нагрузку за последнюю минуту, 0.42 – за последние 5 минут и 0.36 – за прошедшие 15 минут. Это приводит нас к вопросу:
За каким именно значением наблюдать? 1, 5 или 15 минут?
Помня правила, которые мы обсудили (1.00 == “Пора исправлять это“) – вам необходимо обращать внимание на значения 5 и 15 минут. Т.е., если на вашей машине бывают пики нагрузки за 1 минуту – это нормально. Если же значение 15-ти минут поднимается выше 1.00 и остаётся таким – пора заняться этим вопросом (конечно, учитывая момент, касающийся количества ядер в системе).
Значит, количество ядер в системе важный вопрос для выяснения реальной нагрузки. Как мне узнать – сколько ядер в моей системе?
так вы получите полную информацию о процессоре(ах).
А что бы получить просто число, без другой информации – выполните:
Оригинал статьи взят отсюда>>>. Замечания/предложения к переводу категорически приветствуются.
Анализ ключевых показателей производительности — часть 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 содержится детальное описание ключевых счетчиков. Ниже описаны наиболее важные счетчики производительности:
Сообщество InfoboxCloud
Администрирование
Категории
Прямой эфир
fadich 11 ноября 2015, 17:09
trukhinyuri 4 августа 2015, 04:41
trukhinyuri 23 января 2015, 14:46
trukhinyuri 30 октября 2014, 23:31
dimasmagadan 25 августа 2014, 09:12
trukhinyuri 15 января 2014, 12:06
trukhinyuri 21 ноября 2013, 23:29
Блоги
Что такое CPU Load Average в Linux и когда стоит волноваться? Какое облако обеспечит максимальную производительность?
Вероятно вы уже видели параметр Load Average. Это 3 числа, показываемых при выполнении команд uptime и top.
Большинство пользователей знают, что load average, это 3 числа, отражающих среднюю нагрузку за периоды времени в одну минуту, 5 минут и 15 минут. При этом меньшие числа лучше. Большие числа — либо есть проблема либо машина перегружена. Однако что является порогом, какие числа хороши а какие плохи? Когда следует предпринимать меры?
В конце статьи мы сравним облачные платформы InfoboxCloud по способности обеспечивать максимальную производительность (это всегда компромисс между производительностью и стоимостью).
Аналогия: трафик на дороге
Давайте начнем с простейшего случая, когда у сервера только один процессор, а далее разберем и более сложные случаи.
Одноядерный процессор похож на одну полосу с трафиком. При этом:
0.00 означает, что на этой полосе трафика нет вовсе. Фактически значение между 0.00 и 1.00 означает, что машина свободно проедет по полосе без притормаживаний.
1.00 означает, что вся полоса занята, но пробок нет.
Более 1.00 означает, что в полосу не все влезли и ждут в пробке.
Так идеальная загрузка 1.00?
Не совсем. С загрузкой 1.00 у вас нет запаса ресурса CPU.
Если загрузка более 0.70 — время подумать об увеличении ресурса CPU.
Если загрузка более 1.00 — нужно найти и исправить проблему, в противном случае будет выстраиваться очередь.
Если загрузка 5.0 и более — у вас серьезные проблемы и приложение или сайт будут явно тормозить.
Многопроцессорные системы. Загрузка 3.00 и ОК
Используется четырехядерный процессор? С загрузкой 3.00 действительно все ОК.
На многопроцессорных системах загрузка относительна числу доступных ядер. На 4х ядерном процессоре 100% загрузка: 4.00 — 4 полосы движения занято.
На какой из 3х параметров Load Average лучше смотреть?
Если загрузка 1.0 на первом минутном интервале — все в порядке. Если такая загрузка продолжается в течение 15 минут — повод задуматься об увеличении мощности CPU: добавлении ядер или частоты.
Причины для высокого Load Average при неизменной нагрузке
Высокий Load Average может быть следствием нехватки процессорного времени (или выставленных параметров CPU limit) или пропускной способности дисковой подсистемы (или низкого приоритета дисковой подсистемы).
Все виртуальные машины одинаковые?
Например, в облаке Virtuozzo Infrastructure скорость дисковой подсистемы программно не ограничена, а на VPS приоритет дисковой подсистемы понижен по сравнению с облаком (но VPS и дешевле).
В облаке Azure Pack Infrastructure гарантируется выделение от 25% до 90% CPU или 90% CPU (самый дорогой вариант, но и самый надежный) в зависимости от пожелания клиента (a ресурсы памяти и диска всегда гарантированы); на Virtuozzo Infrastructure гарантии выделения CPU нет (хотя есть внутренние регламенты по обеспечению процессорного времени CPU на Virtuozzo, обеспечивающие высокий уровень производительности, но программная гарантия есть только на Azure Pack Infrastructure).
Какой сервис выбрать? Если задача требует максимальной предсказуемости бизнес-приложений, нужно использовать Azure Pack Infrastructure (а еще на эту платформу при регистрации сейчас действует скидка 50% на первые 6 месяцев). Для веб-сайтов лучше всего себя показывает Virtuozzo Infrastructure, сочетая высокую производительность, гибкость и возможности автомасштабирования. Если цель: максимальная экономия, нужно использовать VPS от Infobox.
CPU Load: когда начинать волноваться?
Аналогия транспортного потока
Так Вы говорите, 1.00 — идеальное значание load average?
Что насчет многопроцессорных систем? Мой сервер показывает загрузку 3.00 и все ОК!
У Вас четырехпроцессорная система? Все в порядке, если load average равен 3.00.
В мультипроцессорных системах загрузка вычисляется относительно количества доступных процессорных ядер. 100% загрузка обозначается числом 1.00 для одноядерной машины, числом 2.00 для двуядерной, 4.00 для четырехъядерной и т.д.
Если вернуться к нашей аналогии с мостом, 1.00 означает «одну полностью загруженную полосу движения». Если на мосту всего одна полоса, 1.00 означает, что мост загружен на 100%, если же в наличии две полосы, он загружен всего на 50%.
То же самое с процессорами. 1.00 означает 100% загрузки одноядерного процессора. 2.00 — 100% загрузки двуядерного и т.д.
Многоядерность vs. многопроцессорность
Сведем все вместе
Давайте посмотрим на средние значения загрузки с помощью команды uptime :
Здесь представлены показатели для системы с четырехъядерным процессором и мы видим, что имеется большой запас по нагрузке. Я даже не буду задумываться о ней, пока load average не превысит 3.70.
Какое среднее значение мне следует контролировать? Для одной, пяти или 15 минут?
Количество ядер важно для правильно понимания load average. Как мне его узнать?
Команда cat /proc/cpuinfo выводит информацию обо всех процессорах в вашей системе. Чтобы узнать количество ядер, «скормите» ее вывод утилите grep :
Примечания переводчика
Выше представлен перевод самой статьи. Также много интересной информации можно почерпнуть из комментариев к ней. Так, один из комментаторов говорит о том, что не для каждой системы важно иметь запас по производтельности и не допускать значения загрузки выше 0.70 — иногда нам нужно чтобы сервер работал «на всю катушку» и в таких случаях load average = 1.00 — то, что доктор прописал.
Хабраюзер dukelion добавил в комментариях ценное замечание, что в некоторых сценариях, для достижения максимального КПД «железа», стоит держать значение load average несколько выше 1.00 в ущерб эффективности работы каждого отдельного процесса.
Хабраюзер enemo в комментариях добавил замечание о том, что высокий показатель load average может быть вызван большим количеством процессов, выполняющих в данный момент операции чтения/записи. То есть, load average > 1.00 на одноядерной машине не всегда говорит о том, что в Вашей системе отсутствует запас по загрузке процессора. Требуется более внимательное изучение причин такого показателя. Кстати, это хорошая тема для нового поста на Хабре 🙂