Владелец VPS заходит в панель мониторинга или запускает команду uptime и видит три загадочных числа: 0.72, 1.34, 2.18. Через час там уже 4.80, 3.25, 1.90. Возникает вполне естественный вопрос: сервер перегружен или с ним все нормально?
Ответ нельзя получить, просто посмотрев на самое большое число.
Load Average часто воспринимают как процент загрузки процессора, хотя это совсем другой показатель. Значение 5 не означает, что CPU загружен на 5%, 50% или 500%. Более того, один сервер при Load Average 5 может работать совершенно нормально, а другой при значении 2 уже заметно тормозить.
Чтобы правильно читать эти цифры, нужно учитывать количество виртуальных процессоров, характер нагрузки и процессы, которые в данный момент хотят получить ресурсы системы.
Что на самом деле показывает Load Average
Посмотреть Load Average в Linux проще всего командой:
uptimeВ конце строки появятся три значения. Например:
load average: 0.42, 0.67, 0.81Те же показатели можно увидеть в top или непосредственно в системном файле:
cat /proc/loadavgПервое число характеризует нагрузку за последнюю минуту, второе за пять минут, третье за пятнадцать минут.
Но слово нагрузка здесь немного сбивает с толку. Load Average не показывает процент использования процессора. В Linux в расчет попадают задачи, которые выполняются или готовы выполняться, а также определенные задачи в непрерываемом ожидании, например ожидающие завершения операций ввода-вывода.
Проще представить очередь.
Есть кассы и есть покупатели. Один покупатель уже обслуживается, несколько ждут своей очереди. Load Average в таком упрощенном представлении помогает понять, сколько работы одновременно претендует на обслуживание системой.
Только роль касс выполняют процессорные ресурсы, а сама ситуация немного сложнее обычной очереди, потому что в Linux на показатель способны влиять и процессы, ожидающие I/O.
Почему показываются сразу три числа
Одно мгновенное значение мало говорит о состоянии сервера.
Предположим, каждую ночь запускается резервное копирование. На несколько минут нагрузка заметно увеличивается, после чего сервер возвращается к обычному состоянию.
Если посмотреть только на текущий момент, можно решить, что VPS постоянно перегружен.
Три временных интервала позволяют увидеть направление изменения нагрузки.
Допустим, uptime показывает:
load average: 6.20, 3.10, 1.40Краткосрочное значение значительно выше остальных. Вероятно, нагрузка недавно начала расти.
Теперь другой пример:
load average: 0.80, 2.40, 5.10Здесь картина противоположная. В течение последних пятнадцати минут сервер был значительно сильнее нагружен, но сейчас ситуация улучшается.
Именно сочетание трех чисел обычно полезнее одного отдельно взятого значения.
Почему Load Average нужно сравнивать с количеством vCPU
Представим VPS с одним виртуальным процессором.
Если одна вычислительная задача постоянно занимает этот процессор, ресурс фактически занят. Когда появляется еще одна такая же задача, ей приходится конкурировать за процессорное время.
Теперь представим сервер с восемью vCPU. Он способен одновременно выполнять значительно больше процессорной работы.
Поэтому одинаковый Load Average нельзя одинаково интерпретировать на этих двух машинах.
Узнать количество доступных Linux процессоров можно, например, командой:
nprocИли посмотреть сведения командой:
lscpuЕсли система видит четыре логических CPU, Load Average около 4 в ситуации преимущественно процессорной нагрузки совсем не означает катастрофу. У системы есть четыре вычислительных ресурса для выполнения работы.
На машине с одним CPU постоянный Load Average около 4 уже выглядит совсем иначе: работы существенно больше, чем один процессор способен обслуживать одновременно.
Правило Load Average равен количеству CPU полезно, но не абсолютно
Часто встречается удобное объяснение: если у сервера четыре CPU, Load Average до 4 нормальный, а все, что выше, означает перегрузку.
Для первого знакомства с показателем такое правило помогает. Использовать его как окончательный диагноз не стоит.
Причина в том, что Load Average учитывает не только задачи, которые непосредственно хотят выполнять инструкции на CPU.
В Linux в показатель попадают и задачи в непрерываемом ожидании. Типичный пример связан с операциями ввода-вывода.
В результате Load Average способен расти даже тогда, когда процессор не выглядит полностью загруженным.
Именно поэтому администратор не должен смотреть только на LA. Это отправная точка для диагностики, а не готовое заключение о состоянии сервера.
Почему сервер может иметь высокий Load Average при свободном CPU
Это одна из самых интересных ситуаций.
Владелец VPS открывает top и видит высокий Load Average. Кажется очевидным, что процессор должен быть загружен под сто процентов. Но CPU имеет заметный запас.
На первый взгляд показатели противоречат друг другу.
На самом деле причина может находиться совсем не в вычислительной мощности.
Представим сайт с большой базой данных. Несколько процессов одновременно запрашивают информацию, но хранилище отвечает медленно. Процессы ждут завершения операций. Процессор в это время не обязательно занят полезными вычислениями, однако количество ожидающей работы увеличивается.
Похожая картина может возникнуть во время интенсивного резервного копирования, работы с большим количеством файлов, тяжелых запросов к базе данных или проблем с дисковой подсистемой.
Поэтому высокий Load Average и высокий процент использования CPU не являются синонимами.
Что посмотреть кроме Load Average
Если сервер начал тормозить, сначала стоит открыть:
topили, если установлена соответствующая утилита:
htopПосмотрите, какие процессы потребляют процессорное время и память. Обратите внимание не только на общий Load Average, но и на состояние CPU.
Полезна и команда:
vmstat 1Она позволяет наблюдать за системой в динамике и увидеть, например, сколько процессов ожидают выполнения и что происходит с процессором и памятью.
Если проблема связана с диском, потребуется исследовать уже дисковую активность и время ожидания операций. Если заканчивается оперативная память, нужно смотреть использование RAM и swap. Если VPS не получает достаточно физического процессорного времени от гипервизора, полезным становится CPU Steal.
Получается своеобразная цепочка диагностики. Load Average говорит: у системы скопилась работа. Остальные показатели помогают понять, почему это произошло.
Один тяжелый процесс и много небольших процессов выглядят по-разному
Еще одна причина не делать выводы по одному числу заключается в характере приложения.
На сервере может работать один процесс, который активно использует CPU. А может одновременно появиться множество PHP-процессов после резкого роста посещаемости. Может выполняться тяжелый SQL-запрос. Может запуститься архивирование файлов.
Для пользователя результат иногда одинаков: страницы сайта начинают открываться медленнее.
Для администратора это совершенно разные проблемы.
В первом случае может потребоваться оптимизация конкретной задачи. Во втором стоит разбираться с обработкой параллельных запросов. В третьем исследовать базу данных. В четвертом достаточно перенести тяжелую фоновую операцию на другое время.
Load Average не сообщает название виновника. Он только показывает состояние общей очереди работы.
Как отличить кратковременный всплеск от настоящей перегрузки
Сервер не обязан постоянно иметь одинаковую нагрузку.
Пользователь публикует новую запись, CMS пересоздает кеш. Интернет-магазин импортирует каталог. По расписанию запускается резервное копирование. Поисковый робот активно обходит страницы. На сайт одновременно приходит больше посетителей.
Во всех этих случаях нагрузка может временно вырасти.
Если после выполнения задачи показатели быстро возвращаются к обычному уровню и пользователи не замечают проблем, само наличие всплеска еще не повод менять тариф.
Гораздо интереснее постоянная тенденция.
Допустим, у VPS два vCPU. Раньше большую часть дня Load Average находился значительно ниже двух. Через несколько месяцев он регулярно держится на уровне 3-5, а в часы посещаемости поднимается еще выше. Одновременно увеличивается время ответа сайта.
Вот такую ситуацию уже стоит исследовать.
Смотрите на график, а не только на терминал
Проверять сервер вручную полезно, но у этого метода есть очевидный недостаток: вы видите только настоящий момент.
Сайт мог тормозить двадцать минут назад, а сейчас работать идеально.
Поэтому для рабочего VPS значительно полезнее мониторинг с историей.
График за сутки или неделю позволяет увидеть повторяющиеся пики. Например, нагрузка растет каждую ночь в одно и то же время. Тогда первым подозреваемым становится задача по расписанию. Если рост совпадает с посещаемостью, нужно изучать приложение и обработку запросов. Если проблема появляется хаотично, придется сопоставлять LA с другими системными показателями.
История также помогает понять, действительно ли серверу стало тесно.
Одно значение 8 выглядит пугающе. Но если оно появилось на минуту во время технической операции, а остальные сутки сервер находился около 0.5, покупка более дорогого VPS может оказаться совершенно ненужной.
Load Average нужно оценивать вместе со скоростью сайта
В конечном счете сервер существует не ради красивых системных графиков.
Если это веб-сервер, важен результат: насколько быстро он обрабатывает запросы, нет ли ошибок, справляется ли с реальной посещаемостью.
Можно найти систему с довольно высоким LA, которая продолжает выполнять свою задачу в приемлемое время. А можно получить сравнительно скромные цифры и при этом иметь медленное приложение из-за базы данных, внешнего API или неправильной конфигурации.
Поэтому правильный вопрос звучит не так: какой Load Average считается хорошим?
Полезнее спросить: что происходит с производительностью сервера при таком Load Average?
Когда высокий Load Average означает, что пора менять тариф
Переход на более мощный VPS действительно способен решить проблему, но только если сервер упирается в ресурсы, которые новый тариф увеличит.
Предположим, приложение активно использует все доступные vCPU, очередь процессов регулярно растет, а увеличение нагрузки совпадает с замедлением сайта. Код и база данных уже проверены, очевидных аномалий нет.
Дополнительные вычислительные ресурсы в такой ситуации выглядят логичным решением.
Но если Load Average растет из-за медленного диска, увеличение только количества vCPU может почти ничего не изменить.
Если причина в недостатке памяти и постоянной работе swap, нужно разбираться с RAM.
Если виноват один неоптимизированный запрос к базе данных, более дорогой сервер способен лишь временно скрыть проблему.
А если виртуальная машина регулярно сталкивается с высоким CPU Steal, причина может находиться уже на уровне физического узла провайдера.
Не покупайте ресурсы только из-за одной цифры
Это, пожалуй, главное практическое правило.
Load Average удобен именно потому, что быстро дает общее представление о состоянии системы. Но его простота обманчива.
Значение 10 само по себе не говорит, что нужно срочно покупать новый сервер. Сначала необходимо знать количество CPU и понять, какие процессы формируют нагрузку.
Если вы выбираете VPS для сайта, полезно также учитывать возможность быстро перейти на более мощную конфигурацию. Проект может начать с небольшой нагрузки, а через год требования изменятся. Возможность увеличить CPU и RAM без сложного переноса иногда важнее покупки большого запаса ресурсов заранее.
На обычном виртуальном хостинге пользователь чаще видит готовые ограничения тарифа и не занимается системными метриками напрямую. На VPS ответственность меняется: вместе с большей свободой появляется возможность наблюдать за сервером гораздо глубже.
И Load Average становится одним из первых показателей, с которым стоит научиться работать.
Три числа в uptime не являются оценкой качества VPS и не показывают процент загрузки процессора. Они помогают увидеть, сколько работы в среднем находилось в состоянии выполнения или ожидания за разные интервалы времени.
Сравните их с количеством доступных CPU, посмотрите динамику, проверьте процессы, память, диск и состояние самого приложения. Только после этого становится понятно, действительно ли серверу не хватает мощности или высокая цифра возникла совсем по другой причине.
