Что означает la в hiveos
Что такое LA (load average) и как правильно его рассчитывать?
Узнать нагрузку на сервере можно прописав команду w через SSH консоль.
Что нужно знать о LA?
Значение LA рассчитывается исходя из процессов, которые выполняются и находятся в очереди на выполнение (CPU, RAM, I/O). В большей степени на LA влияет загруженность процессора, которая в свою очередь является одним из основных факторов повышенной нагрузки на сервере.
1(единица) LA = 100% нагрузка на 1 ядро CPU. Соответственно, когда на VPS два ядра, то допустимая средняя нагрузка может достигать 2 LA:
Если нагрузка растёт и превышает количество ядер и держится продолжительное время, то несмотря на это, Ваш сервер продолжает работать. В данном случае, LA увеличивает очередь запросов на выполнение и в случае с виртуализацией KVM / OpenVZ данная нагрузка начинает негативно влиять на физический сервер, на котором находится Ваш VPS.
Как правило, мы не реагируем на всплески нагрузки (например, когда выполняется бэкап или выгрузка товаров в 1с), но если мы видим, что LA на физическом сервере гораздо выше нормы, то будем вынуждены предпринять меры, т.к. это будет иметь негативный эффект для всех клиентов на данном физическом сервере.
- load average, la, cpu, нагрузка, vds, vps, cputime 5 Пользователи нашли это полезным
Похожие статьи
Если у вашего сайта не отображаются латинские буквы, как в данном примере:То вам необходимо.
Для VPS/VDS Сервера мы предлагаем панель управления ISPmanager Lite совершенно бесплатно*.
Данная услуга предназначена для клиентов, которые заказали «выделенный сервер» или «VPS/VDS.
Мануал написан для тех, у кого установлена панель управления ISPmanager Lite и операцинная.
У Вас выскакивает ошибка «Конвертация в UTF-8 не поддерживается на стороне сервера» при.
GPU ЧаВо
Ферма постоянно перезагружается. Если через Hive Shell включить logs-on, на что обращать внимание?
Когда риг уйдет в оффлайн, Hive Shell разъединится, а на экране как раз останутся именно эти строки.
Как снизить энергопотребление GPU?
Для снижения потребления ваших GPU (при использовании Hive OS), вы можете указать параметры напряжения ядра и памяти индивидуально для каждой карты.
Для этого зайдите на вашем воркере в раздел Разгон и укажите нужные значения в профиле разгона. Обратите внимание, что в графе Состояние памяти вы можете указать как индекс состояния 0, 1, или 2, так и напряжение в мВт.
Так же для снижения энергопотребления вы можете воспользоваться режимом агресивного андервольтинга:
Как проверить, есть ли интернет на GPU риге?
Ошибка 511. Почему она возникает?
Данная ошибка возникает в большинстве случаев из за неисправности райзера видеокарты. Проверьте разъем питания на райзере на предмет подгоревшего провода, и замените райзер.
Что такое DPM на видеокартах AMD?
Производитель с большим запасом выставляет вольтаж для каждой ступени частоты ядра. Наша задача для выбранной частоты ядра, прописанной в DPM, подобрать наименьшее значение вольтажа, но при этом чтобы карта продолжала копать стабильно. Так мы получаем пониженное потребление без потери производительности. Это и есть даунвольт. Пример даунвольтов:
Как риги объединить/перенести на другую ферму?
Перейдите в настройки рига:
Затем перейдите на нижнюю часть страницы и нажмите Расширенные настройки:
Выберите из выпадающего списка нужную ферму, и нажмите на кнопку Перенос:
Запуск mc на риге
Как через Hive-Shell проверить, действительно ли завис риг?
Зайдите по Hive Shell на рабочий риг, находящийся в той же локальной сети что и зависший.
Введите вот эту команду: ssh [email protected]”Ip_адрес_неработающего_рига” :
Далее введите свой пароль от этого рига. Последний ip-адрес рига можно посмотреть на панели управления Hive OS.
Теперь можно проверить, действительно ли риг завис или отключился, или же это какой-то «глюк» сервера веб-интерфейса. Команда exit возвращает каждый раз по цепочке обратно.
Что такое LA (Load Average)?
Load Average (средняя нагрузка) — это среднее количество исполняемых процессов в течение определённого времени. Например, если часовая средняя нагрузка равна 10, то это означает (для однопроцессорной системы), что в любой момент времени в течение этого часа 1 процесс выполняется, а 9 готовы к выполнению (то есть не блокированы для ввода/вывода) и ждут, когда процессор освободится.
Если у вас Celeron G3930 с двумя ядрами, то LA 2 свидетельствует о 100% загрузке системы. Для Ethash это очень ненормально, а вот для современных алгоритмов — вполне подходит.
Максимальное значение LA может быть каким угодно. Это длина очереди к процессору, выраженная в количестве ядер этого процессора. LA всегда считалось в количестве вычислительных устройств, требуемых для выполнения всей текущей очереди задач.
При майнинге Beam и Cuckoo на слабых процессорах, LA может доходить до 3-4. Если не нравится красный цвет индикатора, вы всегда можете настроить пороговое значение вот здесь:
Три значения: LA сейчас / среднее LA за 5 минут / среднее LA за 15 минут.
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 и остаётся таким – пора заняться этим вопросом (конечно, учитывая момент, касающийся количества ядер в системе).
Значит, количество ядер в системе важный вопрос для выяснения реальной нагрузки. Как мне узнать – сколько ядер в моей системе?
так вы получите полную информацию о процессоре(ах).
А что бы получить просто число, без другой информации – выполните:
Оригинал статьи взят отсюда>>>. Замечания/предложения к переводу категорически приветствуются.
Load Average в Linux: разгадка тайны
Средние значения нагрузки (Load averages) — это критически важная для индустрии метрика. Многие компании тратят миллионы долларов, автоматически масштабируя облачные инстансы на основании этой и ряда других метрик. Но на Linux она окутана некой тайной. Отслеживание средней нагрузки на Linux — это задача, работающая в непрерываемом состоянии сна (uninterruptible sleep state). Почему? Я никогда не встречал объяснений. В этой статье я хочу разгадать эту тайну, и создать референс по средним значениям нагрузки для всех, кто пытается их интерпретировать.
Средние значения нагрузки в Linux — это «средние значения нагрузки системы», показывающие потребность в исполняемых потоках (задачах) в виде усреднённого количества исполняемых и ожидающих потоков. Это мера нагрузки, которая может превышать обрабатываемую системой в данный момент. Большинство инструментов показывает три средних значения: для 1, 5 и 15 минут:
По этому набору из трёх значений вы можете оценить динамику нагрузки, что безусловно полезно. Также эти метрики полезны, когда требуется какая-то одна оценка потребности в ресурсах, например, для автоматического масштабирования облачных сервисов. Но чтобы разобраться с ними подробнее, нужно обратиться и к другим метрикам. Само по себе значение в диапазоне 23—25 ничего не значит, но обретает смысл, если известно количество процессоров, и если речь идёт о нагрузке, относящейся к процессору.
Вместо того, чтобы заниматься отладкой средних значений нагрузки, я обычно переключаюсь на другие метрики. Об этом мы поговорим ближе к концу статьи, в главе «Более подходящие метрики».
История
Изначально средние значения нагрузки показывают только потребность в ресурсах процессора: количество выполняемых и ожидающих выполнения процессов. В RFC 546 есть хорошее описание под названием «TENEX Load Averages», август 1973:
[1] Средняя нагрузка TENEX — это мера потребности в ресурсах CPU. Это среднее количество исполняемых процессов в течение определённого времени. Например, если часовая средняя нагрузка равна 10, то это означает (для однопроцессорной системы), что в любой момент времени в течение этого часа 1 процесс выполняется, а 9 готовы к выполнению (то есть не блокированы для ввода/вывода) и ждут, когда процессор освободится.
Версия на ietf.org ведёт на PDF-скан графика, нарисованного вручную в июле 1973, демонстрирующего, что эта метрика используется десятилетиями:
source: https://tools.ietf.org/html/rfc546
Сегодня можно найти в сети исходный код старых операционных систем. Вот фрагмент из TENEX (начало 1970’s) SCHED.MAC, на макроассемблере DEC:
А вот фрагмент из современной Linux (include/linux/sched/loadavg.h):
В Linux тоже жёстко прописаны константы на 1, 5 и 15 минут.
Аналогичные метрики были и в более старых системах, включая Multics, которая содержала экспоненциальное среднее значение очереди планируемых заданий (exponential scheduling queue average).
Три числа
Три числа — это средние значения нагрузки для 1, 5 и 15 минут. Вот только они на самом деле не средние, и не для 1, 5 и 15 минут. Как видно из вышеприведённого кода, 1, 5 и 15 — это константы, используемые в уравнении, которое вычисляет экспоненциально затухающие скользящие суммы пятисекундного среднего значения (exponentially-damped moving sums of a five second average). Так что средние нагрузки для 1, 5 и 15 минут отражают нагрузку вовсе не для указанных временных промежутков.
Если взять простаивающую систему, а затем подать в неё однопоточную нагрузку, привязанную к процессору (один поток в цикле), то каким будет одноминутное среднее значение нагрузки спустя 60 секунд? Если бы это было просто среднее, то мы получили бы 1,0. Вот график эксперимента:
Визуализация эксперимента по экспоненциальному затуханию среднего значения нагрузки.
Так называемое «одноминутное среднее значение» достигает примерно 0,62 на отметке в одну минуту. Доктор Нил Гюнтер подробнее описал этот и другие эксперименты в статье How It Works, также есть немало связанных с Linux комментариев на loadavg.c.
Непрерываемые задачи Linux
Внедрение непрерываемого состояния означает, что в Linux средние значения нагрузок могут увеличиваться из-за дисковой (или NFS) нагрузки ввода/вывода, а не только ресурсов процессора. Всех, кто знаком с другими ОС и их средними нагрузками на процессор, включение этого состояния поначалу сильно смущает.
Зачем? Зачем это было сделано в Linux?
Существует несметное количество статей по средним нагрузкам, многие из которых упоминают про nr_uninterruptible в Linux. Но я не видел ни одного объяснения, или хотя бы серьёзного предположения, почему начали учитывать это состояние. Лично я предположил бы, что оно должно отражать более общие потребности в ресурсах, а не только применительно к процессору.
В поисках древнего патча для Linux
Есть старинные репозитории Linux (1 и 2), но и в них отсутствует описание этого изменения. Стараясь найти хотя бы дату его внедрения, я изучил архив на kernel.org и обнаружил, что оно было в 0.99.15, а в 0.99.13 ещё не было. Однако версия 0.99.14 отсутствовала. Мне удалось её отыскать и подтвердить, что искомое изменение появилось в Linux 0.99.14, в ноябре 1993. Я надеялся, что мне поможет описание этого релиза, но и здесь я не нашёл объяснения:
«Изменения в последнем официальном релизе (p13) слишком многочисленны, чтобы их перечислять (или даже вспомнить). » — Линус
Он упомянул лишь основные изменения, не связанные со средним значением нагрузки.
По дате мне удалось найти архивы почтовой рассылки kernel и конкретный патч, но более старое письмо было датировано аж июнем 1995:
«Во время работы над системой, позволяющей эффективнее масштабировать почтовые архивы, я случайно уничтожил текущие архивы (ай-ой)».
Я начал ощущать себя проклятым. К счастью мне удалось обнаружить старые архивы почтовой рассылки linux-devel, вытащенные из серверного бэкапа, зачастую хранящиеся как архивы дайджестов. Я просмотрел более 6000 дайджестов, содержащих свыше 98 000 писем, из которых 30 000 относились к 1993 году. Но ничего не нашёл. Казалось, исходное описание патча потеряно навеки, и ответа на вопрос «зачем» мы уже не получим.
Происхождение непрерываемости
Но вдруг на сайте oldlinux.org в архивированном файле почтового ящика за 1993 я нашёл это:
Было просто невероятно прочитать о размышлениях 24-летней давности, ставших причиной этого изменения. Письмо подтвердило, что изменение в метрике должно было учитывать потребности и в других ресурсах системы, а не только процессора. Linux перешла от «средней нагрузки на процессор» к чему-то вроде «средней нагрузки на систему».
Упомянутый пример с диском с более медленной подкачкой не лишён смысла: снижая производительность системы, потребность в ресурсах (исполняемые и ждущие очереди процессы) должна расти. Однако средние значения нагрузки снижались, потому что они учитывали только состояния выполнения процессора (CPU running states), но не состояния подкачки (swapping states). Маттиас вполне справедливо считал это нелогичным, и потому исправил.
Непрерываемость сегодня
Но разве средние значения нагрузки в Linux иногда не поднимаются слишком высоко, что уже нельзя объяснить дисковым вводом/выводом? Да, это так, хотя я предполагаю, что это следствие новой ветви кода, использующей TASK_UNINTERRUPTIBLE, не существовавшего в 1993-м. В Linux 0.99.14 было 13 ветвей кода, которые напрямую использовали TASK_UNINTERRUPTIBLE или TASK_SWAPPING (состояние подкачки позднее убрали из Linux). Сегодня в Linux 4.12 почти 400 ветвей, использующих TASK_UNINTERRUPTIBLE, включая некоторые примитивы блокировки. Вероятно, что одна из этих ветвей не должна учитываться в среднем значении нагрузки. Я проверю, так ли это, когда снова увижу, что значение слишком высокое, и посмотрю, можно ли это исправить.
Я написал Маттиасу и спросил, что он думает 24 года спустя о своём изменении среднего значения нагрузки. Он ответил через час:
«Суть «средней нагрузки» — предоставить численную оценку занятости системы с точки зрения человека. TASK_UNINTERRUPTIBLE означает (означало?), что процесс ожидает чего-то вроде чтения с диска, что влияет на нагрузку системы. Система, сильно зависящая от диска, может быть очень тормозной, но при этом среднее значение TASK_RUNNING будет в районе 0,1, что совершенно бесполезно».
Так что Маттиас до сих пор уверен в правильности этого шага, как минимум относительно того, для чего предназначался TASK_UNINTERRUPTIBLE.
Но сегодня TASK_UNINTERRUPTIBLE соответствует большему количеству вещей. Нужно ли нам менять средние значения нагрузки, чтобы они отражали потребности в ресурсах только процессора и диска? Peter Zijstra уже прислал мне хорошую идею: учитывать в средней нагрузке task_struct->in_iowait вместо TASK_UNINTERRUPTIBLE, потому что это точнее соответствует вводу/выводу диска. Однако это поднимает другой вопрос: чего мы хотим на самом деле? Хотим ли мы измерять потребности в системных ресурсах в виде потоков выполнения, или нам нужны физические ресурсы? Если первое, то нужно учитывать непрерываемые блокировки, потому что эти потоки потребляют ресурсы системы. Они не находятся в состоянии простоя. Так что среднее значение нагрузки в Linux, вероятно, уже работает как нужно.
Чтобы лучше разобраться с непрерываемыми ветвями кода, я хотел бы измерить их в действии. Потом можно оценить разные примеры, измерить затраченное время и понять, есть ли в этом смысл.
Измерение непрерываемых задач
Вот внепроцессорный (off-CPU) флейм-график с production-сервера, охватывающий 60 секунд и показывающий только стеки ядра, на котором я оставил только состояние TASK_UNINTERRUPTIBLE (SVG).
График отражает много примеров непрерываемых ветвей кода:
Если вы не знакомы с флейм-графиками: можете покликать по блокам, изучить целиком стеки, отображающиеся как колонки из блоков. Размер оси Х пропорционален времени, потраченному на блокирование вне процессора, а порядок сортировки (слева направо) не имеет значения. Для внепроцессорных стеков выбран голубой цвет (для внутрипроцессорных стеков я использую тёплые цвета), а вариации насыщенности обозначают разные фреймы.
Я сгенерировал график с помощью своего инструмента offcputime из bcc (для работы ему нужны eBPF-возможности Linux 4.8+), а также приложения для создания флейм-графиков:
Для изменения выходных данных с микросекунд на миллисекунды я использую awk. Offcputime «—state 2» соответствует TASK_UNINTERRUPTIBLE (см. sched.h), это опция, которую я добавил ради этой статьи. Впервые это сделал Джозеф Бачик с его инструментом kernelscope, который тоже использует bcc и флейм-графики. В своих примерах я показываю лишь стеки ядра, но offcputime.py поддерживает и пользовательские стеки.
Что касается вышеприведённого графика: он отображает только 926 мс из 60 секунд, проведённые в состоянии непрерываемого сна. Это добавляет к нашим средним значениям нагрузки всего 0,015. Это время, потраченное некоторыми cgroup-ветвями, но на этом сервере не выполняется много дисковых операций ввода/вывода.
А вот более интересный график, охватывающий только 10 секунд (SVG):
Более широкая башня справа относится к блокируемому systemd-journal в proc_pid_cmdline_read() (чтение /proc/PID/cmdline), что добавляет к среднему значению нагрузки 0,07. Слева более широкая башня page fault, тоже заканчивающаяся на rwsem_down_read_failed() (добавляет к средней нагрузке 0,23). Я окрасил эти функции пурпурным цветом с помощью поисковой фичи в моём инструменте. Вот фрагмент кода из rwsem_down_read_failed() :
Имеет ли смысл учитывать эти ветви кода в средней нагрузке? Я бы сказал, да. Эти потоки остановлены посреди выполнения и заблокированы. Они не простаивают. Им требуются ресурсы, хотя бы и программные, а не аппаратные.
Анализируем средние значения нагрузки в Linux
Можно ли полностью разложить на компоненты среднее значение нагрузки? Вот пример: на простаивающей 8-процессорной системе я запустил tar для архивирования нескольких незакэшированных файлов. Приложение потратило несколько минут, по большей части оно было блокировано операциями чтения с диска. Вот статистика, из трёх разных окон терминала:
Я также построил внепроцессорный флейм-график исключительно для непрерываемого состояния (SVG):
Средняя нагрузка в последнюю минуту составила 1,19. Давайте разложим на составляющие:
В сумме получается 1,15. Не хватает ещё 0,04. Частично сюда могут входить округления и ошибки измерения сдвигов интервала, но в основном это может быть из-за того, что средняя нагрузка представляет собой экспоненциально затухающую скользящую сумму, в то время как другие используемые метрики (pidstat, iostat) являются обычными средними. До 1,19 одноминутная средняя нагрузка равнялась 1,25, значит что-то из перечисленного всё ещё тянет метрику вверх. Насколько? Согласно моим ранним графикам, на одноминутной отметке 62 % метрики приходилось на текущую минуту, а остальное — на предыдущую. Так что 0,62 x 1,15 + 0,38 x 1,25 = 1,18. Достаточно близко к полученному 1,19.
В этой системе работу выполняет один поток (tar), плюс ещё немного времени тратится потоками воркеров ядра, так что отчёт Linux о средней нагрузке на уровне 1,19 выглядит обоснованно. Если бы я измерял «среднюю нагрузку на процессор», то мне показали бы только 0,37 (расчётное значение из mpstat), что корректно только для процессорных ресурсов, но не учитывает тот факт, что нужно обрабатывать более одного потока.
Надеюсь, этот пример показал вам, что эти числа берутся не с потолка (процессор + непререрываемые), и вы можете сами разложить их на составляющие.
Смысл средних значений нагрузки в Linux
Я вырос на операционных системах, в которых средние значения нагрузок относились только к процессору, так что Linux-вариант всегда меня напрягал. Возможно, настоящая проблема заключается в том, что термин «средняя нагрузка» так же неоднозначен, как «ввод-вывод». Какой именно ввод/вывод? Диска? Файловой системы? Сети. Аналогично, средние нагрузки чего? Процессора? Системы? Эти уточнения помогли мне понять:
Есть и другой возможный тип метрики: «средние значения нагрузки на физические ресурсы», куда входит нагрузка только на физические ресурсы (процессор и диск).
Возможно, когда-нибудь мы начнём учитывать в Linux и другие нагрузки, и позволим пользователям выбирать, что они хотят видеть: средние нагрузки на процессор, на диск, на сеть и так далее. Или вообще использовать всё вместе.
Что такое «хорошие» или «плохие» средние нагрузки?
Некоторые люди вычислили пороговые значения для своих систем и рабочих нагрузок: они знают, что когда метрика превышает значение Х, то задержка приложения вырастает и клиенты начинают жаловаться. Но никаких конкретных правил здесь нет.
Применительно к средней нагрузке на процессор кто-то может делить значения на количество процессоров и затем утверждать, что если соотношение больше 1,0, то могут возникнуть проблемы с производительностью. Это довольно неоднозначно, поскольку долгосрочное среднее значение (как минимум одноминутное) может скрывать в себе разные вариации. Одна система с соотношением 1,5 может прекрасно работать, а другая с тем же соотношением в течение минуты может работать быстро, но в целом производительность у неё низкая.
Однажды я администрировал двухпроцессорный почтовый сервер, который в течение дня работал со средней процессорной нагрузкой в диапазоне от 11 до 16 (соотношение между 5,5 и 8). Задержка была приемлемой, никто не жаловался. Но это экстремальный пример: большинство систем будут проседать при нагрузке/соотношении в районе 2.
Применительно к средним значениям нагрузки в Linux: они ещё более неоднозначны, поскольку учитывают разные типы ресурсов, так что не получится просто поделить на количество процессоров. Они полезны для относительного сравнения: если вы знаете, что система хороша работает при значении в 20, а сейчас 40, то пришло время посмотреть на другие метрики, чтобы понять, что происходит.
Более подходящие метрики
Рост средних нагрузок в Linux означает повышение потребности в ресурсах (процессоры, диски, некоторые блокировки), но вы не уверены, в каких. Чтобы пролить на это свет, можно использовать другие метрики. Например, для процессора:
Первые две — метрики использования, последние три — метрики насыщения (saturation metrics). Метрики использования полезны для оценки рабочей нагрузки, а метрик насыщения — для идентификации проблем с производительностью. Лучшая метрика насыщения для процессора — измерение задержки очереди выполнения (или диспетчера): это время, проведённое задачей/потоком в состоянии готовности к выполнению, но вынужденным ждать своей очереди. Это позволяет вычислить тяжесть проблем с производительностью. Например, какая часть времени тратится потоком на задержки диспетчера. А измерение длины очереди позволяет предположить лишь наличие проблемы, а её серьёзность оценить сложнее.
В Linux 4.6 функция schedstats ( sysctl kernel.sched_schedstats ) стала настраиваться ядром, и по умолчанию выключена. Подсчёт задержек (delay accounting) отражает ту же метрику задержки диспетчера из cpustat, и я предложил добавить её также в htop, чтобы людям было проще ею пользоваться. Проще, чем, к примеру, собирать метрику длительности ожидания (задержка диспетчера) из недокументированных выходных данных /proc/sched_debug:
Помимо процессорных метрик, можете анализировать метрики использования и насыщения для дисковых устройств. Я анализирую их в методе USE, у меня есть Linux-чеклист.
Хотя существуют более явные метрики, это не означает, что средние значения нагрузки бесполезны. Они успешно используются в политиках масштабирования облачных микросервисов наряду с другими метриками. Это помогает микросервисам реагировать на увеличение разных типов нагрузки, на процессор или диски. Благодаря таким политикам безопаснее ошибиться при масштабировании (теряем деньги), чем вообще не масштабироваться (теряем клиентов), так что желательно учитывать больше сигналов. Если масштабироваться слишком сильно, то на следующий день можно будет найти причину.
Одна из причин, по которой я продолжаю использовать средние нагрузки, — это их историческая информация. Если меня просят проверить низкопроизводительные инстансы в облаке, я логинюсь и выясняю, что одноминутное среднее значение нагрузки гораздо ниже пятнадцатиминутного, то это важное свидетельство того, что я слишком поздно заметил проблему с производительностью. Но на просмотр этих метрик я трачу лишь несколько секунд, а потом перехожу к другим.
Заключение
В 1993 году Linux-инженер обнаружил нелогичную работу средних значений нагрузки, и с помощью трёхстрочного патча навсегда изменил их с «со средних нагрузок на процессор» на «средние нагрузки на систему». С тех пор учитываются задачи в непрерываемом состоянии, так что средние нагрузки отражают потребность не только в процессорных, но и в дисковых ресурсах. Обновлённые метрики подсчитывают количество работающих и ожидающих работы процессов (ожидающих освобождения процессора, дисков и снятия непрерываемых блокировок). Они выводятся в виде трёх экспоненциально затухающих скользящих сумм, в уравнениях которых используются константы в 1, 5 и 15 минут. Эти три значения позволяют видеть динамику нагрузки, а самое большое из них может использоваться для относительного сравнения с ними самими.
С тех пор в ядре Linux всё активнее использовалось непрерываемое состояние, и сегодня оно включает в себя примитивы непрерываемой блокировки. Если считать среднее значение нагрузки мерой потребности в ресурсах в виде выполняемых и ожидающих потоков (а не просто потоков, которым нужны аппаратные ресурсы), то эта метрика уже работает так, как нам нужно.
Я откопал патч, с которым было внесено это изменение в Linux в 1993-м — его было на удивление трудно найти, — содержащий исходное объяснение его автора. Также с помощью bcc/eBPF я замерил на современной Linux-системе трейсы стеков и длительность нахождения в непрерываемом состоянии, и отобразил это на внепроцессорном флем-графике. На нём отражено много примеров состояний непрерываемого сна, такой график можно генерировать, когда нужно объяснить необычно высокие средние значения нагрузки. Также я предложил вместо них использовать другие метрики, позволяющие глубже понять работу системы.
В заключение процитирую комментарий из топа kernel/sched/loadavg.c исходного кода Linux:
Этот файл содержит волшебные биты, необходимые для вычисления глобального среднего значения нагрузки. Это глупое число, но люди считают его важным. Мы потратили много сил, чтобы эта метрика работала на больших машинах и tickless-ядрах.