Комментарии 87
скажу честно — я сто лет не читал статей из серии «линукс для самых маленьких» (на русском) такого хорошего качества.
статья написана в стиле «до прочтения не знал что это такое, после прочтения — понял и запомнил на всю жизнь».
статья написана в стиле «до прочтения не знал что это такое, после прочтения — понял и запомнил на всю жизнь».
У меня были такие же впечатления после прочтения оригинала. Собственно, поэтому и перевод появился.
В таком же изложении с удовольствием бы прочитал статью про:
Хабраюзер enemo в комментариях добавил замечание о том, что выской показатель load average может быть вызван большим количеством процессов, выполняющих в данный момент операции чтения/записи. То есть, load average > 1.00 на одноядерной машине не всегда говорит о том, что в Вашей системе отсутствует запас по загрузке процессора. Требуется более внимательное изучение причин такого показателя. Кстати, это хорошая тема для нового поста на Хабре :-)
просто аналогия с мостом и автомобилями хороша.
«Я даже не буду задумываться о ней, пока load average не превысит 3.70.» (для системы на 4 ядра).
Т.е. правило 70% применяется к одному ядру, а не ко всей системе. Если применить ко всей системе, то будет 2.80
Хоть это и перевод, но можете уточнить как правильно?
Т.е. правило 70% применяется к одному ядру, а не ко всей системе. Если применить ко всей системе, то будет 2.80
Хоть это и перевод, но можете уточнить как правильно?
Вот только надо понимать, что это относительно верно для числодробилок. Если машина занимается активной раздачей статики, то даже la 50 может быть штатным значением.
Собственно, в последнем пункте я про это и говорю.
LA 50 не будет штатным значением, на 1-процессорной машине с LA 50 вы вряд ли сможете подключиться по SSH к ней.
А к статье надо добавить, что максимальная производительность достигается при LA > 1, т.е. иногда есть смысл держать LA повыше, чтобы более эффективно нагрузить «железо», в ущерб времени обработки отдельного запроса.
А к статье надо добавить, что максимальная производительность достигается при LA > 1, т.е. иногда есть смысл держать LA повыше, чтобы более эффективно нагрузить «железо», в ущерб времени обработки отдельного запроса.
Обоснуйте, пожалуйста, почему la 50 — это нормально при раздаче статики? Это как-то связано с тем, что очередь процессов может искусственно увеличиваться из-за медленных клиентов? И как в таком случае контроллировать la? Как выявить предел допустимого значения?
В la добавляются напрямую все процессы, которые блокированы по io.
Представьте, что каждые 100 ms приходит 50 клиентов с запросом, мы добавляем их в очередь, ищем и находим им информацию, отдаём, 100 ms им постоять приходится. Это и будет la 50. При этом cpu загружен вообще не будет. И машина вполне резво отвечает, никто больше 100ms в среднем не ждёт.
Представьте, что каждые 100 ms приходит 50 клиентов с запросом, мы добавляем их в очередь, ищем и находим им информацию, отдаём, 100 ms им постоять приходится. Это и будет la 50. При этом cpu загружен вообще не будет. И машина вполне резво отвечает, никто больше 100ms в среднем не ждёт.
Не упомянуто, что на 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 на линуксе можно получить и при простаивающих процессорах, надо смотреть комплекснее.
«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 на линуксе можно получить и при простаивающих процессорах, надо смотреть комплекснее.
Добавил замечание в основной пост. Спасибо!
Моё грубое определение Load в Linux — это число процессов, находящихся в состоянии R (running or runnable (on run queue)) + число процессов в состоянии D (uninterruptible sleep (usually IO)). Load average усредняет эти значения по хитрой формуле (кажется, это экспоненциально взвешенное скользящее среднее).
Посмотреть статусы можно через ps.
Статья в таком виде не даёт никакого понимания о LA в Linux.
Мало того, LA в Linux вообще не информативен, ибо смешивает очередь I/O и очередь на выполнение процессором. Как я уже говорил, смотреть нужно в ps.
Посмотреть статусы можно через ps.
Статья в таком виде не даёт никакого понимания о LA в Linux.
Мало того, LA в Linux вообще не информативен, ибо смешивает очередь I/O и очередь на выполнение процессором. Как я уже говорил, смотреть нужно в ps.
Кстати, на собеседованиях в крупные IT-компании обычно ждут именно такого определния LA. :)
Отчасти, Вы правы. Но все же не стоит утверждать, что LA полностью бесполезен. Для грубой оценки потребления ресурсов CPU он вполне подходит.
LA — хороший показатель для оценки того, насколько в общем система «тормозит»
у вас может быть система с массивом из 10 дисков, которая будет показывать LA 10 и это будет нормальной работой для такой системы.
У меня есть один сервер на 4 камнях. LA 8-10, CPU Idle=90%. А оно работает…
Поэтому вы вводите в заблуждение LA это одно, CPU — другое. Они могут быть связаны. А могут быть и нет.
Поэтому вы вводите в заблуждение LA это одно, CPU — другое. Они могут быть связаны. А могут быть и нет.
В старом посте про load average давали ссылку на замечательную статью, где я и прочитал про это самое «кспоненциально взвешенное скользящее среднее»,
Очень рекомендую к прочтению, можно даже добавить в пост.
Часть 1 www.teamquest.com/pdfs/whitepaper/ldavg1.pdf
Часть 2 www.teamquest.com/pdfs/whitepaper/ldavg2.pdf
Очень рекомендую к прочтению, можно даже добавить в пост.
Часть 1 www.teamquest.com/pdfs/whitepaper/ldavg1.pdf
Часть 2 www.teamquest.com/pdfs/whitepaper/ldavg2.pdf
Видел своими глазами сервер с LA ~1200 из-за очереди на операции с хардом, при этом процессор был бодрячком:
Как видно, каждое обращение к диску в среднем ждало 2500мс до выполнения. Серверу жилось очень тяжело)
# 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мс до выполнения. Серверу жилось очень тяжело)
> Видел своими глазами сервер с LA ~1200 из-за очереди на операции с хардом, при этом процессор был бодрячком:
Я под 800-900 видел. Причем, хозяин сервака говорил, что это нормально и у него всегда так. И, что интересно, сайты на том сервачке бодро так шевелились и SSH работал.
Я под 800-900 видел. Причем, хозяин сервака говорил, что это нормально и у него всегда так. И, что интересно, сайты на том сервачке бодро так шевелились и SSH работал.
мне доводилось проводить экперимент над FreeBSD установленной под гипервизором VmWare — крутил настройки sysctl для достижения максимальной производительности сети.
стрелял в скрипт phpinfo() на апаче при помощи LOIC. LA доходил до 450. ОС при этом была способна управляться по SSH.
ядро, отданное виртуалке было одно.
стрелял в скрипт phpinfo() на апаче при помощи LOIC. LA доходил до 450. ОС при этом была способна управляться по SSH.
ядро, отданное виртуалке было одно.
так видно же, что всё упёрлость в i/o: iowait = 19.39 — это много
А как считать если ядер 2, но с HT в системе видно 4 ядра?
Хороший вопрос. Постараюсь изучить его и дополнить пост. Если кто-то из более опытных товарищей поделится ссылкой или готовой информацией — с удовльствие добавлю в пост.
Добавил немного информации на эту тему в основной пост. Не буду утверждать, что она 100% правильная.
Спасибо. Тогда количество ядер видимо можно узнать командой
Только не знаю насколько правильно она отработает на многопроцессорных системах — сейчас не на чем проверить.
cat /proc/cpuinfo | grep "core id" | sort | uniq | wc -lТолько не знаю насколько правильно она отработает на многопроцессорных системах — сейчас не на чем проверить.
Я изменил пример получения количества ядер в статье — посмотрите там.
На VDS это даст 0 результат
Проверил, действительно. Однако не совсем понятно что я должен там увидеть в данной ситуации — на моём vds видно два ядра при том, что процессор 4 ядерный 8 поточный (HT).
removed
Я знаю что такое виртуализация и как она работает, вопрос в том, что при наличии, допустим, 4 ядер, мне ничего не мешает создать 8 виртуальных машин по 1 или 2 ядра каждая — и как в этом случае оценивать LA в рамках одной VM?
В рамках виртуальной машины Вы увидите LA этой конкретной машины. Оценивать, я думаю, стоит также, как и для физической.
Хорошо, но если взять более абстрактную ситуацию — 1 одноядерный процессор, на котором крутятся 2 виртуальные машины, на которых в разное время может нагрузка доходить до предельной. При этом в гипервизоре ограничений не стоит. Что я должен увидить в LA простаивающей машины, если в этот момент вторая забивает ЦП на 100%?
Скорее всего стоит считать как 4 ядра, не оглядываясь на реальную разницу в производительности.
Просто подсчёт элементов в /proc/cpuinfo даст количество «логических» ядер. Которых в случае гипертрединга отображается вдвое больше, чем реальных. (Также необязательно пересчитывать элементы; достаточно глянуть на siblings).
А для физических ядер лучше смотреть на число cpu cores.
Как-то так:
(как раз тот случай — 4 физических ядра, 8 «логических»).
А для физических ядер лучше смотреть на число 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 «логических»).
когда я запускал клиент распределённых вычислений, то нагрузка была в районе 1 х количество ядер. При этом никаких тормозов, всё работало штатно.
> ШОЗАНАХ
Мне подумалось, что это слово нужно поставить первым в заголовке сообщений от системы диагностики:
«ШОЗАНАХ: Менее 9% места на диске»
«ШОЗАНАХ: LA постоянно держится выше 2.5»
«ШОЗАНАХ: Увеличение числа попыток логина по ssh»
Апофеозом было бы завести shozanah.ru, но как-то долго писать :)
Мне подумалось, что это слово нужно поставить первым в заголовке сообщений от системы диагностики:
«ШОЗАНАХ: Менее 9% места на диске»
«ШОЗАНАХ: LA постоянно держится выше 2.5»
«ШОЗАНАХ: Увеличение числа попыток логина по ssh»
Апофеозом было бы завести shozanah.ru, но как-то долго писать :)
А если некоторые процессы имеют nice? Я вот часто запускаю процессы вроде компиляции с высоким nice (обычно 15, максимальное значение — 19). Оно отжирает весь проц, даёт LA «выше крыши», но система абсолютно не тормозит, так как если появляется задача с меньшим nice (например, 0 — по умолчанию), все эти процессы уступают ей дорогу.
Добавлю прекрасное видео Брендана про 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 счетчик идет на тысячи и десятки тысяч — надо прям щаз убивать какой-то жирный процесс, а то можно потерять контроль.
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 счетчик идет на тысячи и десятки тысяч — надо прям щаз убивать какой-то жирный процесс, а то можно потерять контроль.
Профиль нагрузки сильно зависит от ее вида. На моих задачах LA может иметь приблизительно одинаковые значения на протяжении нескольких суток. Вы правильно заметили — резкое изменение показателя LA — это симптом. А проблемы может, на самом деле, и не быть. Нужно просто обращать внимание на колебания LA и исследовать причины его «нестандартного поведения».
Если среднее значение загрузки постоянно превышает 0.70, следует выяснить причину такого поведения системы во избежании проблем в будущем
С другой стороны, если среднее значение загрузки редко превышает 0.70, то это значит, что треть всего времени процессор вхолостую отапливает дата-центр.
Ахинея. LA показывает сколько процессов могло бы выполняться, но не выполняется из-за того, что блокированы. Если это LA по процессору, да, числа больше 1 — проблема.
Но любой дурак может изготовить себе LA over 9000 и не испытывать при этом никакого дискомфорта. Достаточно включить в биосе флопповод и начать с него читать в 9000 потоков. LA будет зашкаливать, системе будет пофигу.
Но любой дурак может изготовить себе LA over 9000 и не испытывать при этом никакого дискомфорта. Достаточно включить в биосе флопповод и начать с него читать в 9000 потоков. LA будет зашкаливать, системе будет пофигу.
Ну т.е. если не заниматься такими извращениями, то статья правильная?
Нет. На практике высокий LA может быть вызван тупящими сетевыми файловыми системами, локальными дисками, ушедшим в дедлок разделом и т.д.
LA не является показателем «хорошести» системы. LA показывает сколько процессов могло бы выполняться с точки зрения скедулера, но не выполняется. И только.
Для меня обычно la 00 обычно означает куда большие проблемы, чем высокий la. В принципе, если говорить про практические наблюдения, изменения LA (в любую сторону) в 2 раза (для более-менее значительного LA) или на 0.5 (если LA маленький) — повод для диагностики.
LA не является показателем «хорошести» системы. LA показывает сколько процессов могло бы выполняться с точки зрения скедулера, но не выполняется. И только.
Для меня обычно la 00 обычно означает куда большие проблемы, чем высокий la. В принципе, если говорить про практические наблюдения, изменения LA (в любую сторону) в 2 раза (для более-менее значительного LA) или на 0.5 (если LA маленький) — повод для диагностики.
> LA показывает сколько процессов могло бы выполняться с точки зрения скедулера, но не выполняется. И только.
Простите, но такими определениями вы еще больше путаницы вносите. Если у меня встали колом (на i/o) 1000 процессов и LA скакнул до 1005, это ну совершенно не значит, что на системе могло бы выполняться 1005 процессов. Вообще, что означает «выполняться» в данном случае?
Не путайте, люди сами запутаются =) Есть относительно понятная формула вычисления LA, не стоит напускать тумана.
Простите, но такими определениями вы еще больше путаницы вносите. Если у меня встали колом (на i/o) 1000 процессов и LA скакнул до 1005, это ну совершенно не значит, что на системе могло бы выполняться 1005 процессов. Вообще, что означает «выполняться» в данном случае?
Не путайте, люди сами запутаются =) Есть относительно понятная формула вычисления LA, не стоит напускать тумана.
LA в линуксе показывает: сколько процессов задерживается скедулером процессора (то есть «готовы выполняться, но не выполняются») и сколько блокированы в IO (то есть готовы выполняться как только диск освободится).
Если LA с 1000 скакнул до 1005, то что произошло сказать нельзя. Это может быть ещё +5 процессов в IO, или, внезапно, 1000 процессов в IO и «CPU LA» в 5 (что ужас и страшно).
Таким образом, с сисадминской позиции, на устоявшейся системе важным является не LA, а его внезапное изменение.
Если LA с 1000 скакнул до 1005, то что произошло сказать нельзя. Это может быть ещё +5 процессов в IO, или, внезапно, 1000 процессов в IO и «CPU LA» в 5 (что ужас и страшно).
Таким образом, с сисадминской позиции, на устоявшейся системе важным является не LA, а его внезапное изменение.
дак и проц просто нагрузить можно — for i in `seq 1 100`; do screen -d dd if=/dev/zero of=/dev/null; done
Помню LA около 600 =) По SSH даже зацепиться удалось, но толку мало, почти ниодна комманда не отзывалась, чудовищное ожидавние ввода/вывода, при попытке прибивать процессы они становисись зомбоками. Спасибо удаленному доступу к «кнопкам питания».
Откуда такая привычка «cat somefile |grep something»? ведь можно сразу «grep something somefile».
Думаю оттого, что народ практически не знает хоткеи readline, и поэтому им проще, столкнувшись со слишком большим выводом cat file, набрать
↑ | grep Чем набирать более рациональную команду. Подсказки:
grep Alt+.
↑ Home Alt-D grep
↑ | grep Чем набирать более рациональную команду. Подсказки:
grep Alt+.
↑ Home Alt-D grep
что то мне подсказывает что в разных оболочках кардинально разные хоткеи… если вообще есть.
Не слушайте «что-то», оно вам неправильно подсказывает.
Во всех нормальных консольных юниксовых утилитах пользовательский ввод реализуется библиотекой readline.
Поэтому хоткеи одинаковые и присутствует история команд и в баше, и в питончике, запущенном в интерактивном режиме, и консольном клиенте mysql.
А в ненормальных утилитых, вроде ораклового sqlplus, нормальный ридлайновый ввод можно получить, запуская их через rlwrap.
Во всех нормальных консольных юниксовых утилитах пользовательский ввод реализуется библиотекой readline.
Поэтому хоткеи одинаковые и присутствует история команд и в баше, и в питончике, запущенном в интерактивном режиме, и консольном клиенте mysql.
А в ненормальных утилитых, вроде ораклового sqlplus, нормальный ридлайновый ввод можно получить, запуская их через rlwrap.
А это что-то плохое? Нравится так народу. Нагляднее :)
Один пример из мноооогих учебников =)
Потому что грепы часто стекируются, а cat заменяется на что попало. «Особый» grep в начале отвлекает от pipе'а.
А на моём Highscreen Spark (Android, 2 ядра) при включении опции для разработчиков — отображение загрузки ЦП, показывает
И так постоянно. Как это интерпретировать?
13.69 13.49 13.06И так постоянно. Как это интерпретировать?
Автору и переводчику — спасибо за простое и понятное объяснение.
Я как то словил на полчаса loadavg в 70 единиц.
Что это было, так и не понял…
Перевел часть виртуалок на другую ноду — больше такого не было.
Что это было, так и не понял…
Перевел часть виртуалок на другую ноду — больше такого не было.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CPU Load: когда начинать волноваться?