А объясните кто-нибудь про LA.

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

Так ожидающих выполнения или работающих ?

Если видим LA 1.00 1.30 1.40

то это значит что за последние 15 минут средняя длина очереди была 1.40 ?

Как так выходит, что она не 1400 (к примеру) ?

Вопрос в том, почему при недостатке производительности очередь не удлинняется сверх меры ?

Это понятно, я вам предельно упростил ситуацию для демонстрации того,

что при la > 1 непонятно как так получается, что нет массового отказа в обслуживании

процессов и как следствие пользователей.

Возникает ощущение, что это не длина вовсе, а что-то другое.

Длина была бы всё время <1, а потом весьма резко набирала бы сотни и тысячи единиц.

Работающих. Про ожидающих выполнения я наврал, именно работающих, выполняющихся в текущую единицу времени. Не знаю, как настроен Ваш веб-сервер, но вообще при компиляции в 4 потока LA=4 с копейками. Сколько потоков - столько и LA. Отказы в обслуживании клиенты не получают, т.к. либо увеличивается время обработки запроса, либо растёт очередь процессов, но система не запускает дополнительные потоки ввиду настройки. Где-то читал, что нормальная LA - 4 на одно ядро процессора. Отдельно еще смотрится на I/O, т.к. LA может быть почти нулевым (это нагрузка на процессор), а I/O уже может не вывозить.

Переводная статья с хабра говорит о 1LA на ядро -0.3 запаса на всех.

Вам-бы тоже почитать, там и про IO сказано, оно как-раз в LA включено.

Еще раз: почему очередь процессов не растет ? Если они поступают,

и не успевают обрабатываться, то крайне маловероятным выглядит

баллансирование на уровне 1-2, гораздо вероятнее было бы получить 1000-10000.

Если система не запускает больше "потоков апача", значит кто-то не получает

страниц-статики и уходит с 503.

Не обязательно. У вас же там не только апач, а еще другие сервисы. Прошелся по хабре. Лично как я понимаю - для сглаживания используется экспоненциальная функция (с целью не бить тревогу при кратковременных пиках). По поводу I/O противоречия со своими словами не вижу, т.к. часть процессов может ожидать какой-то другой процесс, выполняющий I/O и откровенно простаивать. Например, апач не выкидывает 503 сразу же - у него есть очередь на это, т.е. клиент может и подождать высвобождения потомка.

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

Вообще же, лично я склонен учитывать не только дисковую подсистему как ввод-вывод в данном контексте, но и оперативную память, правда она влияет на загрузку SYSTEM.

Тот же веб-сервер, обрабатывая в 2 раза больше кликов не будет нагружать систему в 2 раза больше по той причине, что все необходимые процессы уже запущены и апач не будет прибивать старый процесс и форкать новый, а использует уже существующий. Не будет повторных обращений к дискам/ОЗУ, т.к. все данные содержатся в кэше процессора или не будет дергать диск, т.к. данные уже закешированы в ОЗУ. На практике, LA больше 1 на ядро означает замедление работы каждого отдельного потока, но не означает понижение производительности системы и не означает отказ в обслуживании. И увеличение посещаемости в 2 раза не означает, что будет использоваться ресурсов в 2 раза больше.

Таким образом мы приходим к выводу, что LOAD AVERAGE это, скорее, не показатель нагрузки/каких-то проблем, а показатель _оптимальности_ использования системы, т.к. большее число потоков лишь замедляет выполнение вычислительных задач, но не означает отказ в обслуживании.

Т.е. там всё-таки экспонента ? С основанием в 10 ?

Если нагрузка такова, что очередь потихоньку заполняется, то её длине нет предела,

тут никакие тайм-ауты не помогут.

Вот этот пассаж мне и непонятен.

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

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

Там на хабре была аналогия с мостом.

Представьте мост по которому едет 1 автомобиль в секунду.

И поток через него в 2 автомобиля в секунду.

В первую секунду получите LA=2, потом 3, 4,5,6,7,8 и так до бесконечности.

(непроехавшие ведь копятся)

Остановится это все только тогда, когда "хвост пробки" вырастет настолько,

что в неё перестанут вставать (отказ в обслуживании), не ранее.

Стабилизация на уровне 2 возможна только если поток чётко 1 автомобиль,

но один раз был один лишний автомобиль. Подобный сценарий вызывает сомнение,

вряд ли так совпали звезды.

И между тем я наблюдаю как все работает с LA 1.00-2.00.

И "ни туда, ни сюда".

Переформулирую ответ, более упрощенно:

У Вас сайт с посещаемостью 100 человек в час. LA при этом = 1. Посещаемость выросла, стало 130 человек в час LA=1.15 - выросло число потоков, они обрабатываются медленнее, но примемлемо для клиентов. Т.е. через час человек уйдет в любом случае, на его место придёт новый, количество обрабатываемых процессов неизменно, но это не означает, что они все не успевают выполняться (!), так как для их выполнения используются разные ресурсы (один процесс жрёт CPU, второй - диск, третий - сеть, в итоге LA=3, хотя процессор загружен только одним процессом). НО, если LA поднимется выше какого-то значения, когда ресурсы системы будут утилизированы полностью, произойдет лавинообразный скачок и сервер рухнет в отказ в обслуживании.

Почему через два часа у меня опять LA=1.15 а не 1.25 или сколько там, ведь в очереди каждый час по 30 человек добавляется, по идее часов через 100 должна быть очередь в 30*100 человек... т.е. la>1 должно постоянно увеличиваться.

Идея о том, что они потребляют разные ресурсы интересна, надо обдумать.

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

Т.е. на некоторых задачах можно наблюдать и LA 300-400 и при этом система не остановится и не помрёт, например, если мы сделаем make kernel -j100 - получим LA ~80 (ну не сможет оно в 100 потоков обрабатывать, ибо некоторые вещи должны быть выполнены последовательно) и дикий расход памяти (30-60 Gb), но при этом система не упадёт и не остановит выполнение задач. А вот если это веб-сервер, клиент может просто не дождаться ответа странички и закрыть вкладку браузера (более 3 секунд - финита ля комедия), а в логах этого зафиксировано не будет - система завершит возложенную на неё задачу. Но нагрузка не постоянная во времени штука и может так получаться, что вот сейчас клиенты смотрели странички с задержкой в 1 секунду, LA подрос, а потом посещаемость снизилась и всё продолжает работать в штатном режиме без последствий, пока пик посещаемости не станет слишком сильным.

---------- Добавлено 23.09.2015 в 21:19 ----------

Если затык только по одному из ресурсов.

Я говорю у пропускной способности памяти. Оно просто не забито до отказа. Проц забит, а память не совсем, т.е. 1 от проца, 0.25 от памяти, 0.5 от диска к примеру.

---------- Добавлено 23.09.2015 в 21:21 ----------

Пиковая нагрузка держится 3-4 часа, дальше - спад.

---------- Добавлено 23.09.2015 в 21:23 ----------

Опять же, откуда берётся замечательная 4-ка? 1 - собственно, сам процессор + 1 - ввод-вывод в память +1 ввод-вывод на диск +1 ввод-вывод в сеть, выше - почти гарантированные проблемы.

Дедик, ВПС, какой, сколько ядер?