Xpoint
   [напомнить пароль]

Linux: что означает load average?

2003-09-11 18:54:18 [обр] Дмитрий Котеров [досье]

Команда uptime выводит:

load average: 66.57, 62.86, 44.84

Эта же информация есть и в результатах top и w. В man-е написано:

The load averages are the average number of
process ready to run during the last 1, 5 and 15 minutes. This line
is just like the output of uptime(1). The uptime display may be tog-
gled by the interactive l command.

И я все равно не понимаю, в чем же изменяется этот load average? Какой у него смысл? Подскажите, пожалуйста.

спустя 32 минуты [обр] Владимир Палант [досье]
Каждый раз, когда scheduler операционной системы приостанавливает выполнение какого-то процесса (или этот процесс сам отдаёт процессор), он должен выбрать другой процесс и запустить его. Для этого у него есть список процессов, которые ждут, пока для них освободится процессор. load average это средняя длина этого списка.
спустя 2 часа 52 минуты [обр] Андрей Новиков [досье]
Это она у тебя действительно столько выводит? Задумываться об апгрейде надо уже после 10, но правильные админы больше 5 не допускают. (Disclamer: возможно в Линуксе абсолютные значения отличаются, но не думаю, что намного)
спустя 45 минут [обр] Сергей Чернышев AKA Drouk S. ;) [досье]
Андрей Новиков:
Да, в Линуксе 5 это уже loaded сервер ;) но 10 это уже конкретный апгрейд технологии. 66 я никогда и не видел ;))) По идее он должен уже мертвым бэть в этот момент (FreeBSD еще будет жить в чем ее приемущество).
спустя 1 час 15 минут [обр] Дмитрий Котеров [досье]

Как ни странно, живет и даже (почти) не тормозит. Я бы предположил, что «грамотность» админа как раз и заключается в том, чтобы больной жил, когда у других он бы давно скончался, но для такого утверждения у меня, увы, опыта не хватает. (-; А вообще, наверное, вы правы, надо апгрейд делать. В первую очередь — процессоры менять, правильно?..

Это все было, видимо, во время пика нагрузки. Сейчас, например, выдает "load average: 8.97, 8.21, 11.04".

Самое странное, что даже в моменты, когда было 60, idle в top-е был где-то 50 в среднем на обоих процессорах. То есть, нагрузка-то была не так и велика (если я правильно понимаю). В этой связи — вопрос: в тот момент было примерно 260 работающих процессов (не так мало, как мне кажется), причем где-то половина из них — чисто ждущих. Может ли load average из-за этого быть нерепрезентативным?

спустя 29 минут [обр] Андрей Новиков [досье]
Нет, он учитывает только процессы, которые хотят выполняться, а им не дают. Ожидающих ввода и просто спящих может быть сколько угодно.
спустя 8 часов [обр] Денис Гетман [досье]
 А вот и нет. В линуксе в отличии от фри считаются все подряд. Это старая шутка линуксового uptime.
Вот цитата с одного из форумов

You may have stuck processes wich doesn't run but count as active for
the load avg count. Almost all processes that get stuck in D state and
can't be killed increases the load avg by one per process stuck.

So look for processes in zombie state or D state. If you can't kill them
perhaps you will need to reboot.

If it increases slowly it could be another thing, but if it increases
suddenly at a fixed time it could be a cron job.

спустя 15 часов [обр] Сергей Чернышев AKA Drouk S. ;) [досье]
Что-то я слабо понимю как у вас там все пашет если idle 50 при 60 load avarage - может цифирки просто глюкнули?
спустя 23 минуты [обр] Дмитрий Котеров [досье]

А Вы думаете, я понимаю?.. Может, они и глюкнули, только тогда они глюкают постоянно вот уже года 2 как. Вот выдержки из top -bcn 1:

  7:01pm  up 3 days, 18:23,  0 users,  load average: 68.66, 67.02, 55.16
263 processes: 258 sleeping, 2 running, 3 zombie, 0 stopped
CPU0 states: 36.1% user, 36.1% system,  0.0% nice, 26.0% idle
CPU1 states: 24.0% user, 39.0% system,  0.0% nice, 36.1% idle

  7:01pm  up 3 days, 18:24,  0 users,  load average: 68.55, 67.16, 55.58
277 processes: 270 sleeping, 1 running, 6 zombie, 0 stopped
CPU0 states: 14.1% user, 10.0% system,  0.0% nice, 74.0% idle
CPU1 states:  4.1% user, 21.0% system,  0.0% nice, 73.0% idle

  7:02pm  up 3 days, 18:24,  0 users,  load average: 69.58, 67.54, 56.07
272 processes: 262 sleeping, 3 running, 7 zombie, 0 stopped
CPU0 states: 33.0% user, 28.0% system,  0.0% nice, 38.0% idle
CPU1 states: 35.1% user, 11.0% system,  0.0% nice, 52.0% idle

  7:02pm  up 3 days, 18:25,  0 users,  load average: 73.39, 68.73, 56.95
266 processes: 263 sleeping, 1 running, 2 zombie, 0 stopped
CPU0 states: 12.0% user, 10.0% system,  0.0% nice, 77.0% idle
CPU1 states: 12.0% user, 12.0% system,  0.0% nice, 74.0% idle

  7:03pm  up 3 days, 18:25,  0 users,  load average: 74.55, 69.30, 57.39
284 processes: 279 sleeping, 4 running, 1 zombie, 0 stopped
CPU0 states: 13.0% user, 11.0% system,  0.0% nice, 75.0% idle
CPU1 states:  5.0% user, 22.0% system,  0.0% nice, 71.0% idle

  7:03pm  up 3 days, 18:26,  0 users,  load average: 78.18, 70.77, 58.32
270 processes: 264 sleeping, 1 running, 5 zombie, 0 stopped
CPU0 states:  6.0% user, 14.0% system,  0.0% nice, 78.0% idle
CPU1 states: 21.0% user, 21.0% system,  0.0% nice, 57.0% idle

  7:04pm  up 3 days, 18:26,  0 users,  load average: 78.51, 71.46, 58.88
249 processes: 247 sleeping, 2 running, 0 zombie, 0 stopped
CPU0 states:  9.0% user, 14.0% system,  0.0% nice, 75.0% idle
CPU1 states:  9.0% user, 17.1% system,  0.0% nice, 72.0% idle

  7:04pm  up 3 days, 18:27,  0 users,  load average: 77.78, 72.07, 59.55
267 processes: 264 sleeping, 1 running, 2 zombie, 0 stopped
CPU0 states: 18.0% user, 11.0% system,  0.0% nice, 70.0% idle
CPU1 states: 22.0% user, 24.0% system,  0.0% nice, 53.0% idle

...

  7:40pm  up 3 days, 19:02,  3 users,  load average: 9.66, 12.53, 22.75
149 processes: 146 sleeping, 1 running, 2 zombie, 0 stopped
CPU0 states:  3.0% user, 12.1% system,  0.0% nice, 83.0% idle
CPU1 states:  8.0% user, 10.0% system,  0.0% nice, 81.0% idle

Ну и как вам?.. Особенно последняя строчка.

Денис Гетман[досье]
Процессов с D-состоянием просто-таки дофига, когда load average достигает пика. А когда он на минимуме, их почти совсем нет. Это что, зомби? Странно тогда, что они не удаляются. Может, просто апач по 30-40 запросов одновременно выполняет, оттого и зомби (все время новые)?

спустя 7 часов [обр] Сергей Чернышев AKA Drouk S. ;) [досье]
Да, видимо у вас из-за специфики огромного кол-ва процессов такое творится - у меня загрузка проца выше, но load avarage гораздо ниже всегда.
спустя 2 дня 1 час [обр] Денис Гетман [досье]
Дмитрий Котеров[досье]
 D - uninterruptible sleep, согласно _man ps_. Вот и не мешайте им спать. :-)
Насколько я помню, и скорее всего неточно, у старых ядер была проблема с прибиванием заснувших процессов, которая и приводила к таким проблемам. Поищите в гугле load averages, d-state и тому подобное - огребете кучу вопросов в форумах и совет изредка перегружать такие процессы.
 Серваки годами стоят, несмотря на этих зомби. Проще всего забить и смотреть по загрузке процессоров. Все равно веб-сервер грузит только СУБД и изредка апачевские дочки.
спустя 8 дней [обр] Юра Богорт [досье]

А можно я чуть-чуть "потуплю" здесь?

#!/usr/bin/perl

for( my $i = 10; $I--;)
{
   if(fork())
   {
      #родитель
   }
   else
   {
      while(1){;}
}
}

По идее если верить предыдущим постингам это должно убить Линукс!
Я так понимаю эти десять процессов всегда готовы и всегда ждут?
Вот только моя систему работала и с тремястами такими процессами заметно тормозив при этом правда и load average>300 наблюдался
Так что говорить что при load average>10 нужно думать об апгрейде несколько не своевременно ТЕМБОЛЕЕ для хостнг провайдера (мало ли там таких как я окажется :)) ИМХО конечно (житейская логика)

спустя 1 час 36 минут [обр] Дмитрий Котеров [досье]
Эти 10 процессов не «всегда ждут», а «всегда работают». Ожидание — это либо sleep, либо ожидание дискового ввода/вывода и т.д. А тут — классический busy wait.
спустя 2 месяца 5 дней [обр] Черноморец Сергей [досье]
если la больше единицы, а процессор на 100% не загружен, то скорее всего у вас интенсивный ввод/вывод
попробуйте посмотреть на статистику io, которую собирает sysstat (ключ -b для sar, по-моему)
сравните число io-операций при высокой la (можно посмотреть ключом -q) и при низкой
Powered by POEM™ Engine Copyright © 2002-2005