Top load average что значит

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, ну и конечно же удачи! 🙂

Источник

Нагрузка на сервер: определение причин

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

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

Команда top

Главным инструментом в этом деле станет команда top. Результат её выполнения выглядит так:

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

Рассмотрим основные показатели, которые могут нас заинтересовать.

Средняя нагрузка на систему (load average)

Load Average — среднее значение загруженности системы за период времени (в дальнейшем LA). Три значения показывают усреднённую нагрузку за последние 1, 5 и 15 минут. LA является одним из самых спорных показателей. Можно найти множество противоречивых статей, какое значение считать нормальным. Обычно принимается, что значение 0 это простой ядра, а значение 1 это полная нагрузка ядра. Оценить показатель средней нагрузки можно только зная количество ядер в системе. Узнать сколько ядер доступно можно командой:

Видим, что на данной системе находится 12 физических ядер (6+6). Соответственно, нормальный показатель LA должен быть менее 12. Однако, на процессорах Intel используется технология Hyper-Threading, которая делит одно физическое ядро на два логических.

Соответственно, в данном случае в системе может быть одновременно 24 виртуальных процессора (потока).

Технология Turbo Boost позволяет процессору «разгоняться» и работать на частоте выше заявленной (т.е. выше 100%, выше единицы). Какой показатель LA считать нормальным в данном случае является предметом споров.

Параметр Cpu

Строка Cpu показывает сразу несколько параметров нагрузки:

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

Нагрузка на процессор (параметры sy, us, ni)

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

Также нужно добавить, что высокое значение ni не всегда будет отрицательно влиять на работоспособность сервера. Возможно, приоритет процессов был понижен специально, чтобы они выполнялись только в том случае, когда процессор будет свободен. Данные процессы не оказывают влияния на работу системы. Например, это могут быть процессы создания бекапов.

Пример диагностики проблем при высоком us и sy

На сервере top показывает следующие значения:

При этом LA больше 100.

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

Определение оверселлинга (параметр st)

Параметр st интересен для виртуальных машин. Можно сказать, что он отображает оверселлинг CPU на родительской ноде. Он будет отличаться от 0 в случае, если VDS требуется процессор, но гипервизор не может выделить CPU, так как он используется в данный момент другими VDS. В случае, если данный параметр принимает большие значения на вашей VDS (ориентировочно более 5-10% совместно с высоким LA) и это мешает вашей работе, то остается только написать в техподдержку с просьбой перенести VDS на другую ноду.

Нагрузка ввода-вывода (параметр wa)

Упрощенная модель состояний в Linux

Посмотреть состояние процессов в системе можно с помощью команды ps с опциями: ps aux

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

Пример нахождения причин высокого wa и load average

Смотрим командой ps aux | grep D процессы в состоянии D.

Нужно знать, что высокий wa внутри VDS, не всегда означает проблемы внутри контейнера. Проблемы также возможны на «родительской» ноде. Например, на ней не хватает I/O диска для всех VDS. Поэтому ваши процессы попадают в состояние ожидания. В таком случае нужно создать тикет в тех поддержку.

Нагрузка ввода-вывода: копаем глубже (atop)

Однако, дальнейшее описание в первую очередь будет относится к VDS на виртуализации KVM и выделенным серверам. На виртуализации OpenVZ мы не сможем воспользоваться полными возможности данной утилиты, и скорее всего вам придется обратиться в тех. поддержку.

Рассмотрим его вывод:

В строке DSK мы видим использование диска в данный момент. В строке busy в процентах указывается примерно сколько «ресурсов» диска потребляется в данный момент. Если там будет значение около 100% значит на диске, скорее всего, наблюдаются проблемы с операциями ввода/вывода. В случае использования VDS, данной строки может не быть и пугаться не стоит.

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

Как мы видим, процесс с идентификатором pid 539189 в данный момент ведет активную запись на диск. Узнать в какие файлы пишет данные этот процесс можно с помощью команды lsof.

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

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

Заключение

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

Источник

Как считается Load Average

Постановка вопроса

Недавно, во время собеседования в одну крупную компанию мне задали простой вопрос, что такое Load Average. Не знаю, на сколько правильно я ответил, но лично для себя пришло осознание, что точного ответа я на самом деле и не знаю.

Большинство людей наверняка знают, что Load Average — это среднее значение загрузки системы за некоторый период времени (1, 5 и 15 минут). Так же можно узнать некоторые подробности из данной статьи, про то, как этим пользоваться. В большинстве случаев этих знаний достаточно для того, что бы по значению LA оценивать загрузку системы, но я по специальности физик, и когда я вижу «среднее за промежуток времени» мне сразу становится интересна частота дискретизации на данном промежутке. А когда я вижу термин «ожидающие ресурсов», становится интересно, каких именно и сколько времени надо ждать, а так же сколько тривиальных процессов надо запустить, что бы получить за короткий промежуток времени высокий LA. И главное, почему ответы на эти вопросы не дает 5 минут работы с гуглом? Если вам данные тонкости так же интересны, добро пожаловать под кат.

Что-то здесь не так.

Для начала определимся с тем, что мы знаем. В общем виде Load Average это среднее количество ожидающих ресурсов ЦПУ процессов за один из трех промежутков времени. Так же нам известно, что это значение в нормальном состоянии находится в диапазоне от 0 до 1, и единица соответствует 100% загрузке одноядерной системы без перегруза. В дальнейшем я буду рассматривать систему как одноядерную, поскольку это проще и показательней.

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

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

В третьих, одноядерная система при 100% загрузке должна давать Load Average равный 1. Но здесь нет никакой зависимости от параметров этого ядра, хотя количество процессов может отличаться в разы. Данный вопрос может быть снят либо корректным определением «ожидающего ресурсов процесса», либо наличием какой-то нормировки на параметры ядра.

Литература

Найти ответы на поставленные вопросы оказалось не так уж и сложно. Правда только на английском языке, и не все так сходу стало понятно. Конкретно были найдены две статьи:
«Examining Load Average»
«UNIX Load Average»
Пользователь Rondo так же предложил вторую часть статьи с более подробным рассмотрением математического аппарата: «UNIX Load Average. Part 2»
А так же небольшой тест для тех, кто и так все понимает, указанный во второй статье.

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

Немного ядерной магии

Из данных материалов можно узнать, что каждому вызываемому процессу дается ограниченный промежуток времени на использование CPU, в стандартной архитектуре intel этот промежуток равен 10мс. Это целая сотая доля секунды и в большинстве случаев процессу столько времени не нужно. Однако, если какой-то процесс использовал все отведенное ему время, то вызывается аппаратное прерывание и система возвращает себе управление процессором. Помимо этого каждые 10мс увеличивая счетчик тиков (jiffies counter). Данные тики считаются с момента запуска системы и каждые 500 тиков (раз в 5 секунд) рассчитывается Load Average.

Код непосредственно расчета находится в ядре в файле timer.c (код приведен для версии 2.4, в версии 2.6 все это несколько рассредоточено, но логика не изменилась, дальше, надеюсь, тоже существенных изменений нет, но, честно говоря, последние релизы не проверял):

Как видно, рассчитываются по очереди те самые три значения LA, однако не указано, что именно считается, и как именно считается. Это тоже не проблема, код функции count_active_tasks() находится в том же файле, чуть выше:

А CALC_LOAD лежит в sched.h вместе с несколькими интересными константами:

Из всего вышеперечисленного можно сказать, что раз в 5 секунд ядро смотрит, сколько всего процессов находится в состоянии RUNNING и UNINTERRUPTIBLE (кстати в других UNIX системах это не так) и для каждого такого процесса увеличивает счетчик на FIXED_1, что равняется 1 вот такое

Однако помимо ответов на имевшиеся изначально вопросы разбор кода ставит и новые. Например, применима ли затухающая экспонента к сокращению числа ожидающих процессов? Если мы рассматриваем радиоактивный распад, то его скорость ограничена лишь количеством ядер, в нашем же случае, при большом количестве процессов все все упрется в пропускную способность CPU. Так же, если сравнить полученную формулу с экспоненциальным законом, становится видно, что , где T — продолжительность интервала набора данных (1, 5 или 15 минут). Таким образом разработчики ядра считают, что скорость уменьшения Load Average обратно пропорциональна продолжительности измерений, что несколько неочевидно, по крайней мере для меня. Ну и не сложно смоделировать ситуации, когда огромные значения LA не будут реально отображать загрузку системы, или наоборот.

В конечном счете складывается впечатление, что для расчета Load Average была выбрана сглаживающая функция, максимально быстро уменьшающая свое значение, что в целом логично для получения конечно числа, но не отображает реально происходящего процесса. И если кто-нибудь мне объяснит, почему именно экспонента и почему именно в таком виде, буду весьма признателен.

Источник

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 на одноядерной машине не всегда говорит о том, что в Вашей системе отсутствует запас по загрузке процессора. Требуется более внимательное изучение причин такого показателя. Кстати, это хорошая тема для нового поста на Хабре 🙂

Источник

[ Полезно ] Load average. «Загрузка сервера».

Данная заметка является переводом статьи из блога компании Scout. В статье дается простое и наглядное объяснение такого понятия, как load average. Статья ориентирована на начинающих Linux-администраторов, но, возможно, будет полезна и более опытным админам. Заинтересовавшимся добро пожаловать под кат.

Вероятно, Вы уже знакомы с понятием load average. Load average — это три числа, отображаемые при выполнении команд top и uptime. Выглядят они примерно так:
load average: 0,35, 0,32, 0,41
Большинство интуитивно понимают, что эти три числа обозначают средние значения загрузки процессора на прогрессивно увеличивающихся временных промежутках (одна, пять и пятнадцать минут) и чем меньше их значения — тем лучше. Большие числа свидетельствуют о слишком большой нагрузке на сервер. Но какие значения считать предельными? Какие значения являются «плохими», а какие — «хорошими»? Когда Вам следует просто волноваться о занчениях средней загрузки, а когда следует бросать другие дела и решать проблему так быстро, как это возможно?
Для начала, давайте разберемся, что же означает load average. Рассмотрим простейший случай: предположим, что у нас в наличии один сервер с одноядерным процессором.

$ uptime 09:14:44 up 1:20, 5 users, load average: 0,35, 0,32, 0,41
Здесь представлены показатели для системы с четырехъядерным процессором и мы видим, что имеется большой запас по нагрузке. Я даже не буду задумываться о ней, пока load average не превысит 3.70.

Какое среднее значение мне следует контролировать? Для одной, пяти или 15 минут?
Для значений, о которых мы говорили раньше (1.00 — почини это немедленно и т.д.), следует рассматривать временные промежутки в пять и 15 минут. Если загрузка Вашей системы превышает 1.00 на интервале в одну минуту, все в порядке. Если же загрузка превышает 1.00 на пяти- или 15-минутном интервале, Вам следует начать принимать меры (конечно, Вам следует также принимать во внимание количество ядер в Вашей системе).

Количество ядер важно для правильно понимания load average. Как мне его узнать?
Команда cat /proc/cpuinfo выводит информацию обо всех процессорах в вашей системе. Чтобы узнать количество ядер, «скормите» ее вывод утилите grep:

$ cat /proc/cpuinfo | grep ‘cpu cores’ cpu cores : 4 cpu cores : 4 cpu cores : 4 cpu cores : 4

Примечания переводчика
Выше представлен перевод самой статьи. Также много интересной информации можно почерпнуть из комментариев к ней. Так, один из комментаторов говорит о том, что не для каждой системы важно иметь запас по производтельности и не допускать значения загрузки выше 0.70 — иногда нам нужно чтобы сервер работал «на всю катушку» и в таких случаях load average = 1.00 — то, что доктор прописал.

Источник