Что такое load average linux

Обновлено: 05.07.2024

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

Фактически Load Average не является средним значением в обычном понимании среднего арифметического. Это дискретная функция, периодически рассчитываемая с момента запуска системы.

Содержание

Просмотр

Эти же числа отображаются в выводе команд w, top, htop.

Принцип расчёта

Подсчёт процессов

Показателем загрузки является число процессов, которые выполняются или ожидают ресурсов на выполнение. По сути это длина очереди.

Для Linux подсчитываются процессы в состояниях:

TASK_RUNNING (R): выполняющиеся и готовые к выполнению;
TASK_UNINTERRUPTIBLE (D): ожидание I/O.

В других UNIX-системах учитывают только R.

В старых версиях ядра Linux код выглядел так:

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

Таким образом, раз в 5 секунд ядро Linux смотрит, сколько всего процессов находится в состоянии RUNNING и UNINTERRUPTIBLE и для каждого такого процесса увеличивает счётчик. Получается целое число, которое характеризует загрузку системы.

Дальше его надо усреднить за какой-то промежуток времени.

Экспоненциальное сглаживание

Для усреднения за промежуток времени используется алгоритм exponentially-damped moving average (экспоненциально затухающее скользящее среднее).

Расчёт выполняется по формуле вида [math]L_t = \alpha L_ + (1-\alpha)\cdot N,[/math] где [math]N[/math] — текущая длина очереди процессов.

Так, для 1-минутного среднего используется [math]\alpha=e^> \approx 0.920[/math] .

Анализ

Для многопроцессорной или многоядерной системы значение LA, равное числу процессоров, означает полную загрузку.

Пример графика =

Допустим, полчаса работал один процесс, затем полчаса простоя.

Практические задания

Для каждого из указанных примеров

load average: 6.85 7.37 7.83
load average: 8.50 10.93 8.61
load average: 37.34 9.47 3.30

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

увеличивается;
уменьшается;
загрузка стабильна;
невозможно определить.

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

Linux - начинающим. Что такое Load Average и какую информацию он несет

С необходимостью правильно оценить нагрузку на систему сталкивается каждый системный администратор. Если говорить о Linux-системах, то одним из основных терминов, с которым придется столкнуться начинающему администратору окажется Load Average (средняя загрузка). Однако, если говорить о русскоязычном сегменте сети интернет, описание данного параметра сводится к общим малозначащим фразам, в то время как за этими простыми цифрами кроется глубокий пласт информации о работе системы.

Если обратиться к популярным источникам (Википедия), то можно найти примерно следующее:

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

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

Посмотреть текущую загрузку системы можно командной

Также ее значения выводят утилиты top и htop, а также множество других инструментов. В ответ мы получим что-то вроде:

Много это или мало? Хорошо или плохо? Давайте разбираться.

Чтобы понять, что такое загрузка системы следует обратиться к логике работы центрального процессора. Вне зависимости от того, мощный у вас процессор или слабый, многоядерный или нет, он выполняет некий программный код для некоторых процессов. Если процесс один, то вопросов нет, а вот когда их несколько? Надо как-то распределять ресурсы между ними и, желательно, равномерно, чтобы один процесс, "дорвавшись" до CPU, не оставил без вычислений другие.

Здесь можно провести аналогию, когда несколько игроков хотят поиграть на одной приставке. Что обычно делают в таких случаях? Договариваются о времени, скажем каждый играет по 15 минут, затем дает поиграть другому.

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

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

Если мы используем все тики за указанный промежуток времени и у нас не будет ожидающих сводного тика процессов, то мы получим загрузку процессора на 100% или load average (LA) равное 1.

Давайте рассмотрим следующую схему:

Для простоты мы будем использовать в расчетах более короткий интервал - 9 тиков. На схеме слева мы видим, что процессорные ресурсы сначала понадобились системе, затем браузеру и файловому менеджеру, потом активности в системе не было, затем еще один тик взял файловый менеджер и еще два браузер, последние два тика также не понадобились никому. Несложные расчеты показывают, что мы использовали 67% процессорного времени или load average системы составил 0,67.

Справа показана ситуация, когда каждый тик был занят своим процессом, но некоторые процессы так и не получили своего тика или не смогли получить, например, ждали окончания операции ввода-вывода. В таком случае загрузка процессора составит все те же 100%, но load average вырастет до 1,33, указывая на наличие очереди.

Чтобы лучше понять ситуацию давайте представим себе небольшой супермаркет, касса представляет собой аналог процессора, тик - среднее время обслуживания покупателя (скажем, 1 минута), а процессы - это покупатели. В разгар рабочего дня людей в магазине немного, и вы спокойно прошли на свободную кассу, рассчитались и пошли по своим делам. Это хорошо, но как оценить нагрузку на кассу? Для этого нужно взять некий промежуток времени, допустим 10 минут. Если за 10 минут в магазине кроме вас было еще три человека, то средняя загрузка составит 0,4.

А теперь зайдем в магазин вечером, все кассы заняты, и чтобы оплатить покупки придется ждать. Теперь если за 10 минут касса обслужила 10 человек и еще 10 стоят в очереди, то средняя загрузка будет равна 2, хотя касса загружена всего на 100%.

Вернемся к процессору и еще одному моменту, процессам, ожидающим окончания операций ввода-вывода (диск, сеть и т.п.). Во многих источниках указывается, что такие процессы искажают результат load average и мы можем получить высокие значения LA при отсутствии загрузки процессора. Да, это так. Посмотрим на еще одну схему ниже:

Как видим, из 9 тиков было использовано только 6, т.е. процессор загружен всего на 67%, но так как три процесса ждут данные от диска, то load average по-прежнему равен 1.

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

Искажают ли такие процессы значение load average? На наш взгляд нет. Следует понимать, что средняя загрузка - это не показатель производительности процессора, не результат бенчмарка, не текущая нагрузка, а отношение числа процессов, которым требуются вычислительные ресурсы системы к имеющимся в наличии ресурсам.

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

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

Подведем промежуточный итог. Load average показывает отношение имеющихся запросов на вычислительные ресурсы к количеству этих самых ресурсов (тиков). Для одного процессора (одного процессорного ядра) использование всех имеющихся ресурсов обозначает load average = 1. Причем это будет справедливо и для Core i7 и для Pentium I, хотя производительность у этих двух процессоров разная.

Теперь перейдем к многопроцессорности и многоядерности. При появлении второго процессора или второго ядра у нас появляются дополнительные вычислительные ресурсы, т.е. же самые 500 тиков. Но за эти 500 тиков система уже может обработать уже 1000 запросов, что покажет нам load average = 2.

Значит ли это, что производительность выросла в два раза? Нет! Производительность зависит от того, сколько вычислений способен произвести процессор в течении одного тика. Понятно, что более мощный процессор выполнит за этот промежуток времени больше вычислений, но оба из них сделают одинаковое число тиков (для каждого процессорного ядра). В многопроцессорных (многоядерных) системах часть процессорного времени вместо вычислений занимают задачи межпроцессорного взаимодействия, переключения контекста и т.д. Поэтому появление второго ядра никогда не даст 100% прироста производительности, но всегда позволяет обработать вдвое большее количество запросов.

Это хорошо видно на примере технологии Hyper-threading, которая позволяет сделать из одного физического ядра процессора два виртуальных. Физическая производительность ядра процессора, т.е. количество производимых им вычислений в единицу времени не меняется, но появляется, хоть и виртуальное, но второе ядро, а это еще 500 тиков. Как показывают тесты, прирост производительности от Hyper-threading составляет 15-30%, что еще раз подтверждает старую поговорку, что лучше плохо ехать, чем хорошо стоять. Второе ядро, хоть и виртуальное, позволяет обрабатывать вычислительные запросы тех процессов, которые в одноядерном варианте стояли бы в очереди.

Непонимание этого момента приводит к тому, что load average ошибочно связывают не с доступностью и достаточностью вычислительных ресурсов, а с производительностью процессора, что приводит к неверным выводам.

Например, переводчик довольно неплохой статьи на Хабре делает ошибочный вывод в отношении Hyper-threading:

Хабраюзер esvaf в комментариях интересуется, как интерпретировать значения load average в случае использования процессора с технологией HyperThreading. Однозначного ответа на данный момент я не нашел. В данной статье утверждается, что процессор, который имеет два виртуальных ядра при одном физическом, будет на 10-30% более производительным, чем простой одноядерный. Если принимать такое допущение за истину, считаю, при интерпретации load average стоит брать в расчет только количество физических ядер.

А Википедия вообще написала полную ерунду (что для технических статей там совсем не редкость):

Средняя нагрузка -- это не очень точная характеристика (хотя бы потому, что она определяет усреднённые значения). И если на компьютере есть несколько процессоров, то такой характеристике верить нельзя. Располагая двумя процессорами, можно (теоретически) одновременно выполнять в два раза большее число программ. Это означает, что средняя нагрузка 2.00 (на двухпроцессорном компьютере) будет эквивалентна средней нагрузке 1.00 (на однопроцессорном компьютере). На самом деле это не совсем так. Из-за дополнительной нагрузки, вызванной планированием и некоторыми другими факторами, двухпроцессорный компьютер не обеспечивает удвоения быстродействия по сравнению с однопроцессорным вариантом.

Убедиться, что это не так довольно легко. Если запустить бесконечный цикл командой

то мы обеспечим полную загрузку одного процессорного ядра и load average = 1 (в данный момент смотрим только на первые, минутные показания данного параметра).

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

Запустим пятый процесс:

Что изменилось? Загрузка процессора осталась на уровне 100%, это и понятно, выше головы не прыгнешь, но load average вырос до 5, что означает нехватку вычислительных ресурсов примерно на 20%. Таким образом понимание сути значения средней загрузки позволяет администратору однозначно сделать выводы о текущей ситуации, чего не скажешь, глядя просто на индикатор загрузки CPU.

Теперь касательно HyperThreading, виртуализации и т.п. случаев, когда процессор, с которым работает система далеко не соответствует физическому процессору, искусственно создадим данную ситуацию. Для этого запустим на хосте параллельно с виртуальной машиной какой-нибудь ресурсоемкий процесс, например, кодирование видео. Виртуальная машина будет рассчитывать на 4 полных процессорных ядра, а по факту получит в лучшем случае половину их производительности. Проверим?

На что следует обратить внимание? В текущих условиях виртуальная машина получает примерно 30-40% загрузки физического процессора. Внутри виртуалки мы видим ожидаемые 100% загрузки процессора, однако если обратить внимание на колонку CPU%, то мы увидим там весьма интересные значения 157-162% загрузки процессора. Почему так происходит? Внутри виртуальной системы тиков CPU хватает всем, но реально гипервизор не выделяет виртуалке процессорного времени. Но это все лирика, что нам показывает load average? Налицо недостаток вычислительных ресурсов - 4,55. Соответствует это реальному положению дел? Да. Нужно ли вносить какие-то коррективы? На наш взгляд - нет.

Теперь уберем стороннюю нагрузку. Гипервизор тут же передаст максимум ресурсов виртуальной машине.

Какие выводы мы можем сделать из этого примера? Что значение load average корректно отражает загрузку системы даже в тех условиях, когда иные показатели не дают корректного представления о происходящих процессах. Так нагрузка на CPU в 157% явно противоречит здравому смыслу, а вот LA = 4,55 вполне реально отражает ситуацию. Поэтому никаких корректив на виртуальные ядра, виртуализацию и т.п. вносить не надо. Load average является относительной величиной и от реальной производительности CPU не зависит в тоже время показывая наличие или дефицит вычислительных ресурсов.

Теперь разберемся с самими цифрами. Мы получаем три значения load average для промежутков в 1, 5 и 15 минут. Как гласит та же Википедия - это средние значения за указанный промежуток времени, что снова неправильно. Для отображения load average используется экспоненциально взвешенная скользящая средняя, подобный тип кривых используется для для сглаживания краткосрочных колебаний и выделения основных тенденций или циклов.

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

То, что подходит финансисту, наверняка подойдет и системному администратору. В чем основное преимущество скользящих средних? В том, что они позволяют выделить основные тенденции, отбросив кратковременные колебания. Это достоинство, а не недостаток, как пытается убедить нас Википедия:

Средняя нагрузка -- это не очень точная характеристика (хотя бы потому, что она определяет усреднённые значения).

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

Благодаря автору Хабра ZloyHobbit, который не поленился изучить исходный код Linux, можно точно смоделировать различные значения load average при заданной модели нагрузки. Мы смоделировали ситуацию, когда первые 30 минут единственное ядро CPU было нагружено на 100%, без ждущих в очереди процессов, в последующие полчаса нагрузка была полностью снята.

Как видим, разные периоды усреднения дают совершенно различные результаты, так LA 1 (1 min), начинает показывать реальные значения где-то через 4 минуты, LA 5 для отражения текущей нагрузки потребовалось уже 20 минут, а LA 15 за полчаса полной загрузки вышла только на 0,8.

О чем это говорит и как интерпретировать данные значения? Можно сказать, что LA 1 представляет собой недавнее прошлое (несколько минут назад), LA 5 прошлое (полчаса-час) и LA 15 отдаленное прошлое (несколько часов).

Теперь, располагая этим багажом знаний, мы можем правильно интерпретировать простые, на первый взгляд, три числа load average.

Для примера возьмем такое значение:

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

Говорит о том, что не так давно система испытывала значительные нагрузки в течении довольно продолжительного времени (полчаса-час).

А вот такая картина:

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

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

Теперь самое время дать ответы на вопросы, поставленные нами в начале статьи: "Много это или мало? Хорошо или плохо? " Для одного ядра мы считаем приемлемыми следующие значения:

LA 1 - может превышать 1.00, свидетельствуя о кратковременной пиковой нагрузке на систему.
LA 5 - не должен превышать 1.00, в противном случае налицо явный недостаток вычислительных ресурсов.
LA 15 - максимальное значение 0.7 - 0.8, но в любом случае не выше 1.0, в противном случае вы можете получить в три часа ночи звонок от руководства с вопросом: " А что это с нашим сервером. "

На многоядерной (многопроцессорной) системе значения load average следует откорректировать пропорционально числу ядер. Узнать их количество можно командой

Так, например, с учетом вышесказанного, для четырехядерной системы LA 15 не должен превышать 3.00, для двухядерной 1.5, а для одноядерной 0.75.

Теперь, понимая, что такое load average и каким образом формируются его значения вы всегда сможете быстро оценить производительность собственной системы и вовремя принять меры если в работе вашего сервера возникнут узкие места.

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

Самым простым способом посмотреть текущие показатели LA в Linux является выполнение команды uptime

По умолчанию команда выводит текущее время, время с момента старта сервера, количество пользователей в системе и характеристики LA

20:36:11 up 1:50, 1 user, load average: 1,09, 0,66, 0,66

up 1 hour, 52 minutes

Однако, LA в этом случае отображаться не будет

Показатели Load Average можно посмотреть открыв какой-либо анализатор состояния системы, например top

Load Average Linux: что такое LA и какие его значения следует считать большими

LA может считаться большим или малым в зависимости от количества ядер процессора.

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

Если применяется несколько процессоров необходимо пересчитывать их количество на количество используемых ядер и сопоставлять полученное число с показателями LA.

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

Как узнать сколько ядер используется Linux сервер

cpu cores : 2
cpu cores : 2
cpu cores : 2
cpu cores : 2

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

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

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

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

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

Постараемся ответить на вопрос: что делать в случае проблем на сервере, какие инструменты использовать и на что обращать внимание для диагностирования проблем производительности в операционной системе Linux .

Команда 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 считать нормальным в данном случае является предметом споров.

Были попытки вычислить нормальное значение LA эмпирическим путем. Но мы считаем это бессмысленным занятием. Дело в том, что в LA попадают также процессы, стоящие в очереди чтения/записи и не имеющие отношение к процессору, а также процессы с приоритетом, измененным с помощью команды nice . В случае если команда запущенна с низким приоритетом, она будет находится в очереди, но не будет оказывать влияния на реальную производительность.

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

Параметр Cpu

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

us (user)	Использование процессора пользовательским процессами
sy (system)	Использование процессора системным процессами
ni (nice)	Использование процессора процессами с измененным приоритетом с помощью команды nice
id (idle)	Простой процессора. Можно сказать, что это свободные ресурсы
wa (IO-wait)	Говорит о простое, связанным с вводом/выводом
hi (hardware interrupts)	Показывает сколько процессорного времени было потрачено на обслуживание аппаратного прерывания
si (software interrupts)	Показывает сколько процессорного времени было потрачено на обслуживание софтверного прерывания
st (stolen by the hypervisor)	Показывает сколько процессорного времени было «украдено» гипервизором

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

Рассмотрим подробнее остальные параметры Сpu .

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

Высокие значения sy , us и ni самые понятные и простые для диагностики, поскольку показывают нагрузку на CPU, создаваемую запущенными программами. Смотрим в выводе команды top процессы по столбцу %CPU и оптимизируем их при необходимости. Либо просто добавляем мощность CPU на сервер.

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

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

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

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

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

Заходим к пользователю frekbok и смотрим лог apache . Там видим такие POST -запросы, и множество им подобных:

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

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

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

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

Самый интересный показатель это wa . На современных серверах мощности процессора и памяти обычно хватает, а большинство проблем связаны с операциями ввода/вывода.

Высокие значения wa , а также высокий LA, обычно говорят о простое процессов в состоянии D-state , связанном с дисковой подсистемой или с сетевыми проблемами. Однако, нельзя забывать, что этот параметр относится ко всем операциям ввода/вывода. Например, на выделенном сервере это значение может вырасти при работе с USB-накопителем, ожидании ответа от сокета или быть вызвано другими причинами.

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

D-state — состояние непрерывного сна (процессы, которые ожидают освобождения потока ввода-вывода)
R-state — процесс активен в настоящее время (выполняется в данный момент)
S-state — состоянии ожидания (sleeping), т.е. он ожидает какого-то события или сигнала
Т-state — процесс приостановлен сигналом STOP или выполнением трассировки
Z-state — «зомби», процесс, завершивший свое выполнение, но присутствующий в системе, чтобы дать родительскому процессу считать свой код завершения

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

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

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

Видим, что в состоянии ожидания висит множество процессов exim4 . Скорее всего сервер был взломан и с него массово рассылают спам. Останавливаем exim и находим источник рассылки.

В случае, если у вас несколько VDS на ноде и необходимо найти источник нагрузки, нужно найти ту, с которой рассылается спам. Для этого можно использовать команду tcpdump -n | grep "smtp" , с помощью неё мы проанализируем почтовый трафик на порту 25, и обнаружим IP-адрес с которого выполняется рассылка спама.

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

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

Удобный инструмент для определения причин нагрузки — это atop c опциями: atop -l -c -d1

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

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

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

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

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

Вызов команды lsof -p539189 (подставляем pid-идентификатор нужного процесса) показал такой результат:

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

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

Заключение

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

В вычислениях UNIX загрузка системы (system load) является мерой объема вычислительной работы, которую выполняет компьютерная система. Средняя загрузка (load average) представляет собой среднюю загрузку системы за период времени. Обычно она представлена в виде трех чисел, которые представляют нагрузку на систему в течение последних одно-, пяти- и пятнадцатиминутных периодов.

Расчет нагрузки в стиле Unix

Все Unix и Unix-подобные системы генерируют безразмерную метрику из трех load average чисел в ядре. Пользователи могут легко запросить текущий результат из оболочки Unix, выполнив команду uptime:

Команды w и top показывают те же три числа средней нагрузки, что и ряд утилит с графическим пользовательским интерфейсом. В Linux к ним также можно получить доступ, прочитав файл /proc/loadavg.

Неактивный компьютер имеет число загрузки 0 (бездействующий процесс не учитывается). Каждый процесс, использующий ЦП или ожидающий его (очередь готовности или очередь выполнения) увеличивает номер загрузки на 1. Каждый завершающийся процесс уменьшает его на 1. Большинство систем UNIX учитывают только процессы в запущенном (на ЦП) или исполняемом (ожидающем ЦП) состоянии. Однако в Linux также есть процессы, находящиеся в непрерывном спящем режиме (обычно ожидающие активности диска), что может привести к заметно разным результатам, если многие процессы остаются заблокированными при вводе-выводе из-за загруженной или остановленной системы ввода-вывода. Это, например, включает блокировку процессов из-за сбоя сервера NFS или слишком медленного носителя (например, запоминающих устройств USB 1.x). Такие обстоятельства могут привести к повышенной средней нагрузке, которая не отражает фактического увеличения использования ЦП (но все же дает представление о том, как долго пользователям придется ждать).

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

С математической точки зрения, все три значения всегда усредняют всю загрузку системы с момента ее запуска. Все они распадаются экспоненциально, но распадаются с разной скоростью: экспоненциально затухают на е через 1, 5 и 15 минут соответственно. Следовательно, 1-минутная средняя нагрузка состоит из 63% (точнее: 1 - 1/е) нагрузки с последней минуты и 37% (1/е) средней нагрузки с момента запуска, исключая последнюю минуту. Для 5- и 15-минутных средних нагрузок такое же соотношение 63%/37% рассчитывается для 5 и 15 минут соответственно. Следовательно, технически неточно, что средняя нагрузка за 1 минуту включает только последние 60 секунд активности, так как она включает 37% активности из прошлого, но правильно сказать, что она включает в себя в основном последнюю минуту.

Интерпретация

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

Например, можно интерпретировать среднюю нагрузку "1.73 0.60 7.98" в однопроцессорной системе как:

в течение последней минуты система была перегружена в среднем на 73% (1,73 рабочих процесса, так что 0,73 процесса должны были ждать своей очереди для системы с одним ЦП в среднем)
в течение последних 5 минут ЦП простаивал в среднем 40% времени
в течение последних 15 минут система была перегружена в среднем на 698% (7,98 рабочих процессов, так что 6,98 процессов должны были ждать своей очереди для одной системы ЦП в среднем)

Это означает, что эта система (ЦП, диск, память и т. д.) могла бы выполнить всю работу, запланированную на последнюю минуту, если бы она была в 1,73 раза быстрее.

В системе с четырьмя процессорами средняя загрузка 3,73 означает, что в среднем 3,73 процесса готовы к запуску, и каждый из них может быть запланирован для ЦП.

В современных системах UNIX обработка потоков по отношению к средней нагрузке различается. Некоторые системы рассматривают потоки как процессы для целей расчета средней нагрузки: каждый поток, ожидающий запуска, добавляет 1 к нагрузке. Однако другие системы, особенно системы, реализующие так называемую многопоточность M:N (M:N threading), используют разные стратегии, такие как подсчет процесса ровно один раз для загрузки (независимо от количества потоков) или подсчет только потоков, открытых в данный момент пользовательским планировщиком потоков к ядру, который может зависеть от уровня конкурентности, установленного для процесса. Linux, похоже, считает каждый поток отдельно как добавление 1 к нагрузке.

Загрузка ЦП против утилизации ЦП

Сравнительное исследование различных показателей нагрузки показало, что информация о загрузке ЦП, основанная на длине очереди ЦП, намного лучше справляется с балансировкой нагрузки по сравнению с утилизацией ЦП. Причина, по которой длина очереди ЦП лучше, вероятно, состоит в том, что, когда хост сильно загружен, его утилизация ЦП, вероятно, будет близка к 100%, и она не может отражать точный уровень загрузки. Напротив, длина очереди ЦП может напрямую отражать величину нагрузки на ЦП. Например, две системы, одна с 3, а другая с 6 процессами в очереди, с большой вероятностью будут иметь коэффициент использования, близкий к 100%, хотя они, очевидно, различаются.

Расчет загрузки процессора

В системах Linux средняя загрузка не рассчитывается для каждого такта, а определяется значением переменной, которое основано на настройке частоты HZ и проверяется на каждом такте. Этот параметр определяет тактовую частоту ядра в герцах (раз в секунду) и по умолчанию равен 100 для тактов 10 мс. Действия ядра используют это количество тактов для определения времени. В частности, функция timer.c::calc_load(), которая вычисляет среднюю нагрузку, запускается каждые LOAD_FREQ = (5*HZ+1) тактов или примерно каждые пять секунд:

Массив avenrun содержит 1-минутное, 5-минутное и 15-минутное среднее значение. Макрос CALC_LOAD и связанные с ним значения определены в sched.h:

"Выборочное" вычисление средних значений нагрузки - довольно распространенное поведение; FreeBSD тоже обновляет значение каждые пять секунд. Интервал обычно не является точным, чтобы они не собирали процессы, запуск которых запланирован на определенный момент.

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