Load average 8 на машине с 4 ядрами, значит машине нужны ядра. Эту фразу я произносил на планёрке. Никто не возразил. Чего я никогда не делал, так это не поднимал это число нарочно больше чем одним способом. Поднял, на тихом сервере с 4 ядрами, где больше ничего не крутится.
Первый прогон загоняет 4 процесса в чистый арифметический цикл, а это самое близкое к определению нагрузки на процессор, что я могу собрать. Второй прогон запускает 8 процессов, пишущих на диск. Оба поднимают load average выше 8. Про процессор из них только один.
Число отстаёт сильнее, чем принято думать
Перед интересной частью скучная, которая скучной не оказалась. Четыре цикла стартуют при load 0.18. Процессор стоит на 100 процентах с первой же секунды, то есть машина занята полностью и сразу.
После целой минуты четырёх насыщенных ядер минутное среднее показывает 2.67. Не 4. Это затухающее среднее с постоянной в 60 секунд, поэтому через минуту ты видишь примерно 63 процента происходящего. Остаток доходит только через 3 или 4 минуты.
Во время аварии это режет в обе стороны. Машина, которая только что ушла под воду, выглядит на две трети настолько плохо, насколько ей плохо. Машина, которую только что спасли, выглядит плохо ещё 3 минуты.
Та же восьмёрка, собранная из другого
Дальше диск. 8 процессов пишут по 300 мегабайт в цикле, минуя страничный кеш, чтобы записи действительно уходили на устройство.
Load 8.10, при этом процессор делает настоящую работу 36.5 процента времени. Ждёт диск он 63.3 процента. 7 из 8 писателей в любой момент сидят в непрерываемом сне. Это то состояние, которое Linux считает наравне с готовыми к счёту. Именно это решение и делает число непроцессорным.
Пара и есть смысл замера. 8.19 и 8.10 это одна и та же тревога на дашборде. Одна лечится ядрами. Вторая лечится быстрым диском или тем, чтобы писать меньше, а ядра при ней простаивают на две трети.
Где я споткнулся
Первая попытка сделать дисковую половину диск не мерила вовсе. Я заставил 8 писателей звать fdatasync, но позволил страничному кешу забрать записи. Прогон вернул load 8.19 при процессоре на 99 процентов и без единого заблокированного процесса, то есть левую рамку с той картинки. Я написал замер копирования памяти и назвал его давлением на диск.
Лечится это обходом кеша, чтобы записи доходили до устройства. Честная версия числа слева звучит так: оно настоящее, оно равно 8.19, про диск оно не говорит ничего.
Чего я не проверял
Достаточно ли часто ядро пересчитывает это число, чтобы верить ему на шаге в 5 секунд: считает оно по таймеру, а не на каждое изменение, так что мои замеры вполне могли читать его округление. Считается ли так же непрерываемый сон на сетевом хранилище, а это как раз тот случай, который важен в датацентре. И как всё это выглядит внутри контейнера, где load average принадлежит хосту, а лимиты живут в cgroup. Жду, что там своя разновидность вранья.
Узкое утверждение про ту самую фразу, которую я говорил. Load 8 на 4 ядрах не означает, что упёрлись в процессор. Прежде чем говорить про ядра, надо посмотреть, чем заняты процессы: та же восьмёрка бывает четырьмя ядрами арифметики, а бывает семью процессами, ждущими устройство, которое от покупки машины побольше быстрее не станет.