CPU Load: когда начинать волноваться?

[@begemot_nn]

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

[@JCDenton]

У меня были такие же впечатления после прочтения оригинала. Собственно, поэтому и перевод появился.

[@shifttstas]

В таком же изложении с удовольствием бы прочитал статью про:

Хабраюзер enemo в комментариях добавил замечание о том, что выской показатель load average может быть вызван большим количеством процессов, выполняющих в данный момент операции чтения/записи. То есть, load average > 1.00 на одноядерной машине не всегда говорит о том, что в Вашей системе отсутствует запас по загрузке процессора. Требуется более внимательное изучение причин такого показателя. Кстати, это хорошая тема для нового поста на Хабре :-)

[@dukelion]

почитайте prutser.wordpress.com/2012/04/23/understanding-linux-load-average-part-1/

[@Ipeacocks]

просто аналогия с мостом и автомобилями хороша.

[@tyomitch]

Только первая картинка левая (и по ошибке совпадает со второй).
В оригинале

[@JCDenton]

Исправил. Спасибо!

[@hipoint]

«Я даже не буду задумываться о ней, пока load average не превысит 3.70.» (для системы на 4 ядра).
Т.е. правило 70% применяется к одному ядру, а не ко всей системе. Если применить ко всей системе, то будет 2.80
Хоть это и перевод, но можете уточнить как правильно?

[@JCDenton]

В оригинале у автора статьи двуядерный процессор и он пишет, что будет ждать значения 1.70. Видимо, умеется в виду, что пока есть «свободные» 30% хотя бы от одного ядра — все ОК.

[@jerom]

Вот только надо понимать, что это относительно верно для числодробилок. Если машина занимается активной раздачей статики, то даже la 50 может быть штатным значением.

[@JCDenton]

Собственно, в последнем пункте я про это и говорю.

[@jerom]

Не, я не про «и в таких случаях la = 1.00 — то, что доктор прописал». Я говорю, что LA становится странным при добавлении ввода-вывода и LA может превышать количество ядер раз в 10 в таких случаях. На него даже смотреть уже не стоит в таких случаях, чтоб не пугаться.

[@dukelion]

LA 50 не будет штатным значением, на 1-процессорной машине с LA 50 вы вряд ли сможете подключиться по SSH к ней.
А к статье надо добавить, что максимальная производительность достигается при LA > 1, т.е. иногда есть смысл держать LA повыше, чтобы более эффективно нагрузить «железо», в ущерб времени обработки отдельного запроса.

[@JCDenton]

Выглядит логично. Добавил информацию в основной пост.

[@jerom]

Когда однопроцессорная машина работает с медленным nfs сервером, то там и с la 500 можно нормально ssh-ем зайти.

[@dukelion]

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

[@youROCK]

Это при условии, что ваша директория .ssh не находится на этом самом NFS-сервере :))

[@Flex25]

Обоснуйте, пожалуйста, почему la 50 — это нормально при раздаче статики? Это как-то связано с тем, что очередь процессов может искусственно увеличиваться из-за медленных клиентов? И как в таком случае контроллировать la? Как выявить предел допустимого значения?

[@jerom]

В la добавляются напрямую все процессы, которые блокированы по io.

Представьте, что каждые 100 ms приходит 50 клиентов с запросом, мы добавляем их в очередь, ищем и находим им информацию, отдаём, 100 ms им постоять приходится. Это и будет la 50. При этом cpu загружен вообще не будет. И машина вполне резво отвечает, никто больше 100ms в среднем не ждёт.

[@ToSHiC]

Вообще говоря, смотреть, нагружен ли процессор в этом случае стоит, и смотреть надо на цифру %wa. Если у вас процессор всё время проводит там — дело плохо, пора тюнить софт и файловую систему (и, возможно, железо) под вашу нагрузку.

[@Meklon]

Утилита iotop спасает в таких случаях.

[@enemo]

Не упомянуто, что на linux в LA учитываются не только ждущие выполнения процессы, но и находящиеся в состоянии блокировки по i/o.
«However, Linux also includes processes in uninterruptible sleep states (usually waiting for disk activity), which can lead to markedly different results if many processes remain blocked in I/O due to a busy or stalled I/O system»
То есть высокий LA на линуксе можно получить и при простаивающих процессорах, надо смотреть комплекснее.

[@JCDenton]

Добавил замечание в основной пост. Спасибо!

[@MaxxxZ]

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

[@Nastradamus]

Моё грубое определение Load в Linux — это число процессов, находящихся в состоянии R (running or runnable (on run queue)) + число процессов в состоянии D (uninterruptible sleep (usually IO)). Load average усредняет эти значения по хитрой формуле (кажется, это экспоненциально взвешенное скользящее среднее).

Посмотреть статусы можно через ps.

Статья в таком виде не даёт никакого понимания о LA в Linux.

Мало того, LA в Linux вообще не информативен, ибо смешивает очередь I/O и очередь на выполнение процессором. Как я уже говорил, смотреть нужно в ps.

[@Nastradamus]

Кстати, на собеседованиях в крупные IT-компании обычно ждут именно такого определния LA. :)

[@JCDenton]

Отчасти, Вы правы. Но все же не стоит утверждать, что LA полностью бесполезен. Для грубой оценки потребления ресурсов CPU он вполне подходит.

[@dukelion]

LA — хороший показатель для оценки того, насколько в общем система «тормозит»

[@Nastradamus]

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

[@pansa]

Не правильно. Длительное нахождение процесса в D-state это не нормально независимо от количества дисков. Более того, если у вас нагрузка распределяется по физическим дискам, ожидание IO это ещё больший аларм.

[@Nastradamus]

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

[@pansa]

Я постоянно вижу всяческие разноообразные показатели la — от 0 и до 50. В некоторых случаях высокий LA это нормально, в некоторых случаях — нет, но корреляции с _количеством_ дисков, однако, нет вовсе.

[@MaxxxZ]

У меня есть один сервер на 4 камнях. LA 8-10, CPU Idle=90%. А оно работает…

Поэтому вы вводите в заблуждение LA это одно, CPU — другое. Они могут быть связаны. А могут быть и нет.

[@Rondo]

В старом посте про load average давали ссылку на замечательную статью, где я и прочитал про это самое «кспоненциально взвешенное скользящее среднее»,
Очень рекомендую к прочтению, можно даже добавить в пост.
Часть 1 www.teamquest.com/pdfs/whitepaper/ldavg1.pdf
Часть 2 www.teamquest.com/pdfs/whitepaper/ldavg2.pdf

[@SilverFire]

Видел своими глазами сервер с LA ~1200 из-за очереди на операции с хардом, при этом процессор был бодрячком:

# iostat -xk -t 10
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,82    0,00    0,08   19,39    0,00   79,70

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0,00   128,10    0,00   47,30     0,00   742,40    31,39   100,09 2515,35  21,14 100,00
sda1              0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00   0,00   0,00
sda2              0,00   128,10    0,00   47,30     0,00   742,40    31,39   100,09 2515,35  21,14 100,00
dm-0              0,00     0,00    0,00  159,70     0,00   638,80     8,00   399,56 2768,76   6,26 100,00
dm-1              0,00     0,00    0,00    0,00     0,00     0,00     0,00     0,00    0,00   0,00   0,00

Как видно, каждое обращение к диску в среднем ждало 2500мс до выполнения. Серверу жилось очень тяжело)

[@isden]

> Видел своими глазами сервер с LA ~1200 из-за очереди на операции с хардом, при этом процессор был бодрячком:

Я под 800-900 видел. Причем, хозяин сервака говорил, что это нормально и у него всегда так. И, что интересно, сайты на том сервачке бодро так шевелились и SSH работал.

[@urbain]

мне доводилось проводить экперимент над FreeBSD установленной под гипервизором VmWare — крутил настройки sysctl для достижения максимальной производительности сети.

стрелял в скрипт phpinfo() на апаче при помощи LOIC. LA доходил до 450. ОС при этом была способна управляться по SSH.
ядро, отданное виртуалке было одно.

[@merlin-vrn]

так видно же, что всё упёрлость в i/o: iowait = 19.39 — это много

[@esvaf]

А как считать если ядер 2, но с HT в системе видно 4 ядра?

[@JCDenton]

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

[@JCDenton]

Добавил немного информации на эту тему в основной пост. Не буду утверждать, что она 100% правильная.

[@esvaf]

Спасибо. Тогда количество ядер видимо можно узнать командой
cat /proc/cpuinfo | grep "core id" | sort | uniq | wc -l
Только не знаю насколько правильно она отработает на многопроцессорных системах — сейчас не на чем проверить.

[@JCDenton]

Я изменил пример получения количества ядер в статье — посмотрите там.

[@xandr0s]

На VDS это даст 0 результат

[@esvaf]

Проверил, действительно. Однако не совсем понятно что я должен там увидеть в данной ситуации — на моём vds видно два ядра при том, что процессор 4 ядерный 8 поточный (HT).

[@JCDenton]

removed

[@esvaf]

Я знаю что такое виртуализация и как она работает, вопрос в том, что при наличии, допустим, 4 ядер, мне ничего не мешает создать 8 виртуальных машин по 1 или 2 ядра каждая — и как в этом случае оценивать LA в рамках одной VM?

[@JCDenton]

В рамках виртуальной машины Вы увидите LA этой конкретной машины. Оценивать, я думаю, стоит также, как и для физической.

[@esvaf]

Хорошо, но если взять более абстрактную ситуацию — 1 одноядерный процессор, на котором крутятся 2 виртуальные машины, на которых в разное время может нагрузка доходить до предельной. При этом в гипервизоре ограничений не стоит. Что я должен увидить в LA простаивающей машины, если в этот момент вторая забивает ЦП на 100%?

[@youROCK]

Что вы должны увидеть — вопрос хороший, но по факту увидите 0.00 :)

[@ElleSolomina]

Скорее всего стоит считать как 4 ядра, не оглядываясь на реальную разницу в производительности.

[@gnomeby]

Всё верно, просто теперь при той же нагрузке LA будет на 10-30% большей.

[@ElleSolomina]

Благодарю, теперь окончательно для себя разобрался.

[@klirichek]

Просто подсчёт элементов в /proc/cpuinfo даст количество «логических» ядер. Которых в случае гипертрединга отображается вдвое больше, чем реальных. (Также необязательно пересчитывать элементы; достаточно глянуть на siblings).
А для физических ядер лучше смотреть на число cpu cores.
Как-то так:

$ cat /proc/cpuinfo | grep cores
cpu cores: 4
cpu cores: 4
cpu cores: 4
cpu cores: 4
cpu cores: 4
cpu cores: 4
cpu cores: 4
cpu cores: 4

(как раз тот случай — 4 физических ядра, 8 «логических»).

[@JCDenton]

Да, так корректнее. Поменял пример в основной статье.

[@dukelion]

А для LA как раз и имеют значение «логические» ядра. LA — это характеристика очереди исполнения, а гипертрединг как раз и увеличивает кол-во одновременных потоков исполнения.

[@fshp]

HT не увеличивает количество потоков. Только скорость переключения контекста.

[@dukelion]

Это внутри процессора, а для ядра ОС потоков больше работает, если они и блокируются внутри процессора, для ядра это незаметно.

[@charon]

когда я запускал клиент распределённых вычислений, то нагрузка была в районе 1 х количество ядер. При этом никаких тормозов, всё работало штатно.

[@achekalin]

> ШОЗАНАХ

Мне подумалось, что это слово нужно поставить первым в заголовке сообщений от системы диагностики:
«ШОЗАНАХ: Менее 9% места на диске»
«ШОЗАНАХ: LA постоянно держится выше 2.5»
«ШОЗАНАХ: Увеличение числа попыток логина по ssh»

Апофеозом было бы завести shozanah.ru, но как-то долго писать :)

[@masterbo]

С .ru не стоит уже «заморачиваться». А с остальным согласен.

[@merlin-vrn]

А если некоторые процессы имеют nice? Я вот часто запускаю процессы вроде компиляции с высоким nice (обычно 15, максимальное значение — 19). Оно отжирает весь проц, даёт LA «выше крыши», но система абсолютно не тормозит, так как если появляется задача с меньшим nice (например, 0 — по умолчанию), все эти процессы уступают ей дорогу.

[@flashvoid]

Добавлю прекрасное видео Брендана про Load avarage
youtu.be/ajtoLLGbwiI

Вообще судить о нагрузке системы по LA дело неблагодарное — где можно применить критерий 70% я вообще непредставляю. Обычно профиль нагрузки очень рваный и LA(5) каждый час показывает несколько пиков в 10 раз выше чем LA(15). Просто задания прилетают пачкой (серия HTTP запросов, пачка крон задач выровненных на одну минуту и т.п.), просто так написан софт который надо крутить на сервере — ничего тут не поделаешь.

LA может быть хорошим оповещением — если вырастает в 10 раз выше обычного — надо срочно спасать сервер пока контроль не потерял. Как правильно замечали про NFS (особенно с --hard) бывает и 1200 LA при отлично работающем сервере.

Так же неплохим критерием опасности является CPU idle — если среднее значение за день меньше 30% надо по этому поводу что-то предпринять.

Очень часто LA является указателем на нехватку памяти — мониторить свободную память в линуксе дело еще менее благодарное чем гадать на LA, но все вместе составляет симптом. Первейшее дело это запустить 'vmstat 1' и смотреть колонки r,b,si и so. Если в b какие неадекватные цифры, а в r единички и в то же время в si/so счетчик идет на тысячи и десятки тысяч — надо прям щаз убивать какой-то жирный процесс, а то можно потерять контроль.

[@JCDenton]

Профиль нагрузки сильно зависит от ее вида. На моих задачах LA может иметь приблизительно одинаковые значения на протяжении нескольких суток. Вы правильно заметили — резкое изменение показателя LA — это симптом. А проблемы может, на самом деле, и не быть. Нужно просто обращать внимание на колебания LA и исследовать причины его «нестандартного поведения».

[@flashvoid]

Ну остается только завидовать — графики вашего мониторинга можно в музей выставлять наверное.
Хотя… если только майнить бикойны или брутфорсить хеши ))

[@JCDenton]

Задача очень похожая по своей сути на майнинг биткойнов.

[@tyomitch]

Если среднее значение загрузки постоянно превышает 0.70, следует выяснить причину такого поведения системы во избежании проблем в будущем

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

[@merlin-vrn]

Не особо он отапливает. Он спит. Если dynticks в ядре, то и часы остановлены.

Но это значит, что можно было купить подешевле и он всё равно справился бы.

[@amarao]

Ахинея. LA показывает сколько процессов могло бы выполняться, но не выполняется из-за того, что блокированы. Если это LA по процессору, да, числа больше 1 — проблема.

Но любой дурак может изготовить себе LA over 9000 и не испытывать при этом никакого дискомфорта. Достаточно включить в биосе флопповод и начать с него читать в 9000 потоков. LA будет зашкаливать, системе будет пофигу.

[@VSOP_juDGe]

Ну т.е. если не заниматься такими извращениями, то статья правильная?

[@amarao]

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

LA не является показателем «хорошести» системы. LA показывает сколько процессов могло бы выполняться с точки зрения скедулера, но не выполняется. И только.

Для меня обычно la 00 обычно означает куда большие проблемы, чем высокий la. В принципе, если говорить про практические наблюдения, изменения LA (в любую сторону) в 2 раза (для более-менее значительного LA) или на 0.5 (если LA маленький) — повод для диагностики.

[@pansa]

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

Простите, но такими определениями вы еще больше путаницы вносите. Если у меня встали колом (на i/o) 1000 процессов и LA скакнул до 1005, это ну совершенно не значит, что на системе могло бы выполняться 1005 процессов. Вообще, что означает «выполняться» в данном случае?

Не путайте, люди сами запутаются =) Есть относительно понятная формула вычисления LA, не стоит напускать тумана.

[@amarao]

LA в линуксе показывает: сколько процессов задерживается скедулером процессора (то есть «готовы выполняться, но не выполняются») и сколько блокированы в IO (то есть готовы выполняться как только диск освободится).

Если LA с 1000 скакнул до 1005, то что произошло сказать нельзя. Это может быть ещё +5 процессов в IO, или, внезапно, 1000 процессов в IO и «CPU LA» в 5 (что ужас и страшно).

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

[@merlin-vrn]

дак и проц просто нагрузить можно — for i in `seq 1 100`; do screen -d dd if=/dev/zero of=/dev/null; done

[@SovGVD]

Помню LA около 600 =) По SSH даже зацепиться удалось, но толку мало, почти ниодна комманда не отзывалась, чудовищное ожидавние ввода/вывода, при попытке прибивать процессы они становисись зомбоками. Спасибо удаленному доступу к «кнопкам питания».

[@lesovsky]

Откуда такая привычка «cat somefile |grep something»? ведь можно сразу «grep something somefile».

[@Self_Perfection]

Думаю оттого, что народ практически не знает хоткеи readline, и поэтому им проще, столкнувшись со слишком большим выводом cat file, набрать
↑ | grep Чем набирать более рациональную команду. Подсказки:
grep Alt+.
↑ Home Alt-D grep

[@dezconnect]

что то мне подсказывает что в разных оболочках кардинально разные хоткеи… если вообще есть.

[@Self_Perfection]

Не слушайте «что-то», оно вам неправильно подсказывает.

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

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

А в ненормальных утилитых, вроде ораклового sqlplus, нормальный ридлайновый ввод можно получить, запуская их через rlwrap.

[@pavelsh]

А это что-то плохое? Нравится так народу. Нагляднее :)

[@dezconnect]

Один пример из мноооогих учебников =)

[@amarao]

Потому что грепы часто стекируются, а cat заменяется на что попало. «Особый» grep в начале отвлекает от pipе'а.

[@seventh]

А на моём Highscreen Spark (Android, 2 ядра) при включении опции для разработчиков — отображение загрузки ЦП, показывает
13.69 13.49 13.06
И так постоянно. Как это интерпретировать?

[@myardyas]

Автору и переводчику — спасибо за простое и понятное объяснение.

[@whoim]

Я как то словил на полчаса loadavg в 70 единиц.
Что это было, так и не понял…
Перевел часть виртуалок на другую ноду — больше такого не было.

[@mobilesfinks]

LA может быть высоким, но реально система будет ненагруженной. Будут просто висеть процессы со статусом D например.
Зачастую завершение этих процессов невозможно т.к. это uninterruptible sleep (usually IO). Помогает перезагрузка.