Пользователь
0,0
рейтинг
24 марта 2014 в 11:38

Разработка → CPU Load: когда начинать волноваться? из песочницы

Данная заметка является переводом статьи из блога компании Scout. В статье дается простое и наглядное объяснение такого понятия, как load average. Статья ориентирована на начинающих Linux-администраторов, но, возможно, будет полезна и более опытным админам. Заинтересовавшимся добро пожаловать под кат.

Вероятно, Вы уже знакомы с понятием load average. Load average — это три числа, отображаемые при выполнении команд top и uptime. Выглядят они примерно так:
load average: 0,35, 0,32, 0,41

Большинство интуитивно понимают, что эти три числа обозначают средние значения загрузки процессора на прогрессивно увеличивающихся временных промежутках (одна, пять и пятнадцать минут) и чем меньше их значения — тем лучше. Большие числа свидетельствуют о слишком большой нагрузке на сервер. Но какие значения считать предельными? Какие значения являются «плохими», а какие — «хорошими»? Когда Вам следует просто волноваться о занчениях средней загрузки, а когда следует бросать другие дела и решать проблему так быстро, как это возможно?
Для начала, давайте разберемся, что же означает load average. Рассмотрим простейший случай: предположим, что у нас в наличии один сервер с одноядерным процессором.

Аналогия транспортного потока


Одноядерный процессор похож на дорогу с одной полосой движения. Представьте себе, что Вы управяете движением машин по мосту. Иногда, Ваш мост загружен настолько сильно, что машинам приходится ждать в очереди чтобы проехать по нему. Вы хотите дать людям понять, как долго им придется ждать чтобы перебраться на другую сторону реки. Хорошим способом сделать это будет показать как много машин ждут в очереди в конкретный момент времени. Если машин в очереди нет, подъезжающие водители будут знать, что они сразу смогут проехать по мосту. В противном случае, они будут понимать, что придется ждать своей очереди.
Итак, Управляющий Мостом, какую систему обозначений Вы будете использовать? Как насчет такой:
  • 0.00 означает, что на мосту нет ни одной машины. Фактически, значения от 0.00 до 1.00 означают отсутствие очереди. Подъезжающая машина может воспользоваться мостом без ожидания;
  • 1.00 означает, что на мосту находится как раз столько автомобилей, сколько он может вместить. Все еще идет хорошо, но, в случае увеличения потока машин, возможны проблемы;
  • Значения, превышающие 1.00 означают наличие очереди на въезде. Насколько большой? Например, значение 2.00 показывает, что в очереди стоит столько же автомобилей, сколько движется по мосту. 3.00 означает, что мост полностью занят и в очереди ожидает в два раза больше машин, чем он может вместить. И так далее.

imageload average = 1.00
imageload average = 0.50
imageload average = 1.70
Вот базовое значение загрузки процессора. «Машины» обрабатываются с использованием промежутков процессорного времени («пересекают мост»), либо ставятся в очередь. В Unix это называется длина очереди выполнения: количество всех процессов, выполняемых в данный момент времени, плюс количество процессов, ожидающих в очереди.
Вам, как управляющему мостом, хотелось бы, чтобы машины-процессы никогда не ждали в очереди. Таким образом, предпочтительно, чтобы загрузки процессора была всегда ниже 1.00. Периодически возможны всплески трафика, когда загрузка будет превышать 1.00, но если она постоянно превышает данное значение — это повод начать волноваться.

Так Вы говорите, 1.00 — идеальное значание load average?


Не совсем. Проблема со значением 1.00 в том, что у Вас не остается запаса. На практике, многие системные администраторы проводят черту на отметке 0.70:
  • Практическое правило «Требуется присмотр»: 0.70. Если среднее значение загрузки постоянно превышает 0.70, следует выяснить причину такого поведения системы во избежании проблем в будущем;
  • Практическое правило «Почини это немедленно!»: 1.00. Если средняя загрузка системы превышает 1.00, необходимо срочно найти причину и устранить ее. В противном случае, Вы рискуете быть разбуженным посреди ночи и это точно не будет весело;
  • Практическое правило «Щас же 3 ночи!!! ШОЗАНАХ??!!»: 5.00. Если среднее значение загрузки процессора превышает 5.00, у Вас серьезные проблемы. Сервер может подвисать или работать очень медленно. Скорее всего, это произойдет в худший из возможных моментов. Например, посреди ночи или когда Вы выступаете с докладом на конференции.

Что насчет многопроцессорных систем? Мой сервер показывает загрузку 3.00 и все ОК!


У Вас четырехпроцессорная система? Все в порядке, если load average равен 3.00.
В мультипроцессорных системах загрузка вычисляется относительно количества доступных процессорных ядер. 100% загрузка обозначается числом 1.00 для одноядерной машины, числом 2.00 для двуядерной, 4.00 для четырехъядерной и т.д.
Если вернуться к нашей аналогии с мостом, 1.00 означает «одну полностью загруженную полосу движения». Если на мосту всего одна полоса, 1.00 означает, что мост загружен на 100%, если же в наличии две полосы, он загружен всего на 50%.
То же самое с процессорами. 1.00 означает 100% загрузки одноядерного процессора. 2.00 — 100% загрузки двуядерного и т.д.

Многоядерность vs. многопроцессорность


Что лучше: один процессор с двумя ядрами или два отдельных процессора? С точки зрения производительности, оба этих решения примерно равны. Да, примерно. Здесь существут множество нюансов, связанных с величиной кэша, переключениями процессов между процессорами т.д. Несмотря на это, единственной важной для измения загрузки системы характеристикой является общее количество ядер вне зависимости от того, на скольких физических процессорах они находятся.
Что приводит нас к еще двум практическим правилам:
  • «Количество ядер = максимальная загрузка». На многоядерной системе, загрузка не должна превышать количества доступных ядер;
  • «Ядра — они и в Африке ядра». То, как ядра распределены по процессорам — неважно. Два четырехъядерных = четыре двуядерных = восем одноядерных процессоров. Имеет значение лишь общее число ядер.

Сведем все вместе


Давайте посмотрим на средние значения загрузки с помощью команды uptime:
~$ uptime
 09:14:44 up  1:20,  5 users,  load average: 0,35, 0,32, 0,41

Здесь представлены показатели для системы с четырехъядерным процессором и мы видим, что имеется большой запас по нагрузке. Я даже не буду задумываться о ней, пока load average не превысит 3.70.
Какое среднее значение мне следует контролировать? Для одной, пяти или 15 минут?

Для значений, о которых мы говорили раньше (1.00 — почини это немедленно и т.д.), следует рассматривать временные промежутки в пять и 15 минут. Если загрузка Вашей системы превышает 1.00 на интервале в одну минуту, все в порядке. Если же загрузка превышает 1.00 на пяти- или 15-минутном интервале, Вам следует начать принимать меры (конечно, Вам следует также принимать во внимание количество ядер в Вашей системе).
Количество ядер важно для правильно понимания load average. Как мне его узнать?

Команда cat /proc/cpuinfo выводит информацию обо всех процессорах в вашей системе. Чтобы узнать количество ядер, «скормите» ее вывод утилите grep:
~$ cat /proc/cpuinfo | grep 'cpu cores'
cpu cores	: 4
cpu cores	: 4
cpu cores	: 4
cpu cores	: 4

Примечания переводчика


Выше представлен перевод самой статьи. Также много интересной информации можно почерпнуть из комментариев к ней. Так, один из комментаторов говорит о том, что не для каждой системы важно иметь запас по производтельности и не допускать значения загрузки выше 0.70 — иногда нам нужно чтобы сервер работал «на всю катушку» и в таких случаях load average = 1.00 — то, что доктор прописал.

PS


Хабраюзер dukelion добавил в комментариях ценное замечание, что в некоторых сценариях, для достижения максимального КПД «железа», стоит держать значение load average несколько выше 1.00 в ущерб эффективности работы каждого отдельного процесса.

PPS


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

PPPS


Хабраюзер esvaf в комментариях интересуется, как интерпретировать значения load average в случае использования процессора с технологией HyperThreading. Однозначного ответа на данный момент я не нашел. В данной статье утверждается, что процессор, который имеет два виртуальных ядра при одном физическом, будет на 10-30% более производительным, чем простой одноядерный. Если принимать такое допущение за истину, считаю, при интерпретации load average стоит брать в расчет только количество физических ядер.
@JCDenton
карма
32,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (85)

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

    • +5
      У меня были такие же впечатления после прочтения оригинала. Собственно, поэтому и перевод появился.
      • 0
        В таком же изложении с удовольствием бы прочитал статью про:
        Хабраюзер enemo в комментариях добавил замечание о том, что выской показатель load average может быть вызван большим количеством процессов, выполняющих в данный момент операции чтения/записи. То есть, load average > 1.00 на одноядерной машине не всегда говорит о том, что в Вашей системе отсутствует запас по загрузке процессора. Требуется более внимательное изучение причин такого показателя. Кстати, это хорошая тема для нового поста на Хабре :-)
    • +2
      просто аналогия с мостом и автомобилями хороша.
      • 0
        Только первая картинка левая (и по ошибке совпадает со второй).
        В оригинале
        • +1
          Исправил. Спасибо!
  • +1
    «Я даже не буду задумываться о ней, пока load average не превысит 3.70.» (для системы на 4 ядра).
    Т.е. правило 70% применяется к одному ядру, а не ко всей системе. Если применить ко всей системе, то будет 2.80
    Хоть это и перевод, но можете уточнить как правильно?
    • 0
      В оригинале у автора статьи двуядерный процессор и он пишет, что будет ждать значения 1.70. Видимо, умеется в виду, что пока есть «свободные» 30% хотя бы от одного ядра — все ОК.
  • +2
    Вот только надо понимать, что это относительно верно для числодробилок. Если машина занимается активной раздачей статики, то даже la 50 может быть штатным значением.
    • 0
      Собственно, в последнем пункте я про это и говорю.
      • 0
        Не, я не про «и в таких случаях la = 1.00 — то, что доктор прописал». Я говорю, что LA становится странным при добавлении ввода-вывода и LA может превышать количество ядер раз в 10 в таких случаях. На него даже смотреть уже не стоит в таких случаях, чтоб не пугаться.
    • +4
      LA 50 не будет штатным значением, на 1-процессорной машине с LA 50 вы вряд ли сможете подключиться по SSH к ней.
      А к статье надо добавить, что максимальная производительность достигается при LA > 1, т.е. иногда есть смысл держать LA повыше, чтобы более эффективно нагрузить «железо», в ущерб времени обработки отдельного запроса.
      • 0
        Выглядит логично. Добавил информацию в основной пост.
      • НЛО прилетело и опубликовало эту надпись здесь
      • +3
        Когда однопроцессорная машина работает с медленным nfs сервером, то там и с la 500 можно нормально ssh-ем зайти.
        • +1
          Правда ваша, но это очень частный случай. SSH, т.к. использует и процессор и диск и сеть, чаще всего тормозит при высоком LA, но исключения, конечно, бывают.
        • +1
          Это при условии, что ваша директория .ssh не находится на этом самом NFS-сервере :))
    • 0
      Обоснуйте, пожалуйста, почему la 50 — это нормально при раздаче статики? Это как-то связано с тем, что очередь процессов может искусственно увеличиваться из-за медленных клиентов? И как в таком случае контроллировать la? Как выявить предел допустимого значения?
      • +2
        В la добавляются напрямую все процессы, которые блокированы по io.

        Представьте, что каждые 100 ms приходит 50 клиентов с запросом, мы добавляем их в очередь, ищем и находим им информацию, отдаём, 100 ms им постоять приходится. Это и будет la 50. При этом cpu загружен вообще не будет. И машина вполне резво отвечает, никто больше 100ms в среднем не ждёт.
        • +3
          Вообще говоря, смотреть, нагружен ли процессор в этом случае стоит, и смотреть надо на цифру %wa. Если у вас процессор всё время проводит там — дело плохо, пора тюнить софт и файловую систему (и, возможно, железо) под вашу нагрузку.
        • 0
          Утилита iotop спасает в таких случаях.
  • +9
    Не упомянуто, что на 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 на линуксе можно получить и при простаивающих процессорах, надо смотреть комплекснее.
    • 0
      Добавил замечание в основной пост. Спасибо!
    • +9
      Моё грубое определение Load в Linux — это число процессов, находящихся в состоянии R (running or runnable (on run queue)) + число процессов в состоянии D (uninterruptible sleep (usually IO)). Load average усредняет эти значения по хитрой формуле (кажется, это экспоненциально взвешенное скользящее среднее).

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

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

      Мало того, LA в Linux вообще не информативен, ибо смешивает очередь I/O и очередь на выполнение процессором. Как я уже говорил, смотреть нужно в ps.
      • +1
        Кстати, на собеседованиях в крупные IT-компании обычно ждут именно такого определния LA. :)
      • 0
        Отчасти, Вы правы. Но все же не стоит утверждать, что LA полностью бесполезен. Для грубой оценки потребления ресурсов CPU он вполне подходит.
        • 0
          LA — хороший показатель для оценки того, насколько в общем система «тормозит»
          • 0
            у вас может быть система с массивом из 10 дисков, которая будет показывать LA 10 и это будет нормальной работой для такой системы.
            • 0
              Не правильно. Длительное нахождение процесса в D-state это не нормально независимо от количества дисков. Более того, если у вас нагрузка распределяется по физическим дискам, ожидание IO это ещё больший аларм.
              • 0
                Где-то видел пример такого LA. Кажется, это было в какой-то статье яндекса.
                В живую не видел )
                • 0
                  Я постоянно вижу всяческие разноообразные показатели la — от 0 и до 50. В некоторых случаях высокий LA это нормально, в некоторых случаях — нет, но корреляции с _количеством_ дисков, однако, нет вовсе.
      • 0
        В старом посте про load average давали ссылку на замечательную статью, где я и прочитал про это самое «кспоненциально взвешенное скользящее среднее»,
        Очень рекомендую к прочтению, можно даже добавить в пост.
        Часть 1 www.teamquest.com/pdfs/whitepaper/ldavg1.pdf
        Часть 2 www.teamquest.com/pdfs/whitepaper/ldavg2.pdf
    • +1
      Видел своими глазами сервер с 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мс до выполнения. Серверу жилось очень тяжело)
      • 0
        > Видел своими глазами сервер с LA ~1200 из-за очереди на операции с хардом, при этом процессор был бодрячком:

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

          стрелял в скрипт phpinfo() на апаче при помощи LOIC. LA доходил до 450. ОС при этом была способна управляться по SSH.
          ядро, отданное виртуалке было одно.
      • 0
        так видно же, что всё упёрлость в i/o: iowait = 19.39 — это много
  • +3
    А как считать если ядер 2, но с HT в системе видно 4 ядра?
    • +1
      Хороший вопрос. Постараюсь изучить его и дополнить пост. Если кто-то из более опытных товарищей поделится ссылкой или готовой информацией — с удовльствие добавлю в пост.
    • 0
      Добавил немного информации на эту тему в основной пост. Не буду утверждать, что она 100% правильная.
      • 0
        Спасибо. Тогда количество ядер видимо можно узнать командой
        cat /proc/cpuinfo | grep "core id" | sort | uniq | wc -l
        Только не знаю насколько правильно она отработает на многопроцессорных системах — сейчас не на чем проверить.
        • 0
          Я изменил пример получения количества ядер в статье — посмотрите там.
        • 0
          На VDS это даст 0 результат
          • 0
            Проверил, действительно. Однако не совсем понятно что я должен там увидеть в данной ситуации — на моём vds видно два ядра при том, что процессор 4 ядерный 8 поточный (HT).
            • 0
              removed
              • 0
                Я знаю что такое виртуализация и как она работает, вопрос в том, что при наличии, допустим, 4 ядер, мне ничего не мешает создать 8 виртуальных машин по 1 или 2 ядра каждая — и как в этом случае оценивать LA в рамках одной VM?
                • 0
                  В рамках виртуальной машины Вы увидите LA этой конкретной машины. Оценивать, я думаю, стоит также, как и для физической.
                  • 0
                    Хорошо, но если взять более абстрактную ситуацию — 1 одноядерный процессор, на котором крутятся 2 виртуальные машины, на которых в разное время может нагрузка доходить до предельной. При этом в гипервизоре ограничений не стоит. Что я должен увидить в LA простаивающей машины, если в этот момент вторая забивает ЦП на 100%?
                    • 0
                      Что вы должны увидеть — вопрос хороший, но по факту увидите 0.00 :)
    • 0
      Скорее всего стоит считать как 4 ядра, не оглядываясь на реальную разницу в производительности.
      • 0
        Всё верно, просто теперь при той же нагрузке LA будет на 10-30% большей.
        • 0
          Благодарю, теперь окончательно для себя разобрался.
  • +1
    Просто подсчёт элементов в /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 «логических»).
    • 0
      Да, так корректнее. Поменял пример в основной статье.
    • 0
      А для LA как раз и имеют значение «логические» ядра. LA — это характеристика очереди исполнения, а гипертрединг как раз и увеличивает кол-во одновременных потоков исполнения.
      • 0
        HT не увеличивает количество потоков. Только скорость переключения контекста.
        • 0
          Это внутри процессора, а для ядра ОС потоков больше работает, если они и блокируются внутри процессора, для ядра это незаметно.
  • 0
    когда я запускал клиент распределённых вычислений, то нагрузка была в районе 1 х количество ядер. При этом никаких тормозов, всё работало штатно.
  • +3
    > ШОЗАНАХ

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

    Апофеозом было бы завести shozanah.ru, но как-то долго писать :)
    • +1
      С .ru не стоит уже «заморачиваться». А с остальным согласен.
  • +1
    А если некоторые процессы имеют nice? Я вот часто запускаю процессы вроде компиляции с высоким nice (обычно 15, максимальное значение — 19). Оно отжирает весь проц, даёт LA «выше крыши», но система абсолютно не тормозит, так как если появляется задача с меньшим nice (например, 0 — по умолчанию), все эти процессы уступают ей дорогу.
  • +2
    Добавлю прекрасное видео Брендана про 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 счетчик идет на тысячи и десятки тысяч — надо прям щаз убивать какой-то жирный процесс, а то можно потерять контроль.
    • 0
      Профиль нагрузки сильно зависит от ее вида. На моих задачах LA может иметь приблизительно одинаковые значения на протяжении нескольких суток. Вы правильно заметили — резкое изменение показателя LA — это симптом. А проблемы может, на самом деле, и не быть. Нужно просто обращать внимание на колебания LA и исследовать причины его «нестандартного поведения».
      • 0
        Ну остается только завидовать — графики вашего мониторинга можно в музей выставлять наверное.
        Хотя… если только майнить бикойны или брутфорсить хеши ))
        • 0
          Задача очень похожая по своей сути на майнинг биткойнов.
  • 0
    Если среднее значение загрузки постоянно превышает 0.70, следует выяснить причину такого поведения системы во избежании проблем в будущем

    С другой стороны, если среднее значение загрузки редко превышает 0.70, то это значит, что треть всего времени процессор вхолостую отапливает дата-центр.
    • +1
      Не особо он отапливает. Он спит. Если dynticks в ядре, то и часы остановлены.

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

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

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

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

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

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

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

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

            Таким образом, с сисадминской позиции, на устоявшейся системе важным является не LA, а его внезапное изменение.
    • 0
      дак и проц просто нагрузить можно — for i in `seq 1 100`; do screen -d dd if=/dev/zero of=/dev/null; done
  • 0
    Помню LA около 600 =) По SSH даже зацепиться удалось, но толку мало, почти ниодна комманда не отзывалась, чудовищное ожидавние ввода/вывода, при попытке прибивать процессы они становисись зомбоками. Спасибо удаленному доступу к «кнопкам питания».
  • 0
    Откуда такая привычка «cat somefile |grep something»? ведь можно сразу «grep something somefile».
    • 0
      Думаю оттого, что народ практически не знает хоткеи readline, и поэтому им проще, столкнувшись со слишком большим выводом cat file, набрать
      ↑ | grep Чем набирать более рациональную команду. Подсказки:
      grep Alt+.
      ↑ Home Alt-D grep
      • 0
        что то мне подсказывает что в разных оболочках кардинально разные хоткеи… если вообще есть.
        • +1
          Не слушайте «что-то», оно вам неправильно подсказывает.

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

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

          А в ненормальных утилитых, вроде ораклового sqlplus, нормальный ридлайновый ввод можно получить, запуская их через rlwrap.
    • +1
      А это что-то плохое? Нравится так народу. Нагляднее :)
    • 0
      Один пример из мноооогих учебников =)
    • +2
      Потому что грепы часто стекируются, а cat заменяется на что попало. «Особый» grep в начале отвлекает от pipе'а.
  • 0
    А на моём Highscreen Spark (Android, 2 ядра) при включении опции для разработчиков — отображение загрузки ЦП, показывает
    13.69 13.49 13.06
    И так постоянно. Как это интерпретировать?
  • 0
    Автору и переводчику — спасибо за простое и понятное объяснение.
  • –1
    Я как то словил на полчаса loadavg в 70 единиц.
    Что это было, так и не понял…
    Перевел часть виртуалок на другую ноду — больше такого не было.
    • 0
      LA может быть высоким, но реально система будет ненагруженной. Будут просто висеть процессы со статусом D например.
      Зачастую завершение этих процессов невозможно т.к. это uninterruptible sleep (usually IO). Помогает перезагрузка.

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