Решено: Необоснованная загрузка процессора (Debian "Lenny" 5.0)

[kokadzamba]

Всем привет!
Прошу помощи, так как самому не под силу разобраться с проблемой. В гуглятнике обыскался, но ничего не нашёл.
Суть проблемы:

Кручу игровой сервер. Раньше юзал Debian "Etch" 4.0 и в принципе был доволен, за исключением традиционно отстающих от жизни пакетов. Сейчас Debian "Lenny" 5.0 устраивает всем, но появилась небольшая проблема: процессор стал загружаться больше в 10 раз даже при простое.
Грешил на железо, но при установке на другой комп, на виртуальную машину всё повторяется.
Грузят проц игровые сервера, на которых даже при нулевом онлайне в топе видно 30 -50 % загрузки. А должно быть ноль % при нулевом онлайне.
В логах ничего особенного не увидел.
Ставлю Ubuntu (2.6-27) на виртуальную машину с теми же игровыми серверами - всё нормально, 0% в простое.
Процессор Intel Q6600
Linux version 2.6.26-1-amd64 (Debian 2.6.26-13lenny2) (dannf@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Fri Mar 13 17:46:45 UTC 2009
Предполагаю, что проблема в ядре, видимо "улучшилась" поддержка процессора.

Код: Выделить всё

top - 09:42:04 up  1:44,  1 user,  load average: 1.80, 1.56, 1.64
Tasks: 183 total,   3 running, 180 sleeping,   0 stopped,   0 zombie
Cpu0  : 23.6%us,  6.3%sy,  0.0%ni, 69.8%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu1  : 20.6%us,  5.6%sy,  0.0%ni, 73.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  : 19.9%us,  8.0%sy,  0.0%ni, 72.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  : 24.2%us, 16.6%sy,  0.0%ni, 58.9%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   8128696k total,  6008836k used,  2119860k free,    73096k buffers
Swap: 19534992k total,        0k used, 19534992k free,  3739908k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2966 XXXXX    20   0  279m 190m  12m R   23  2.4  21:41.23 srcds_i686
 2956 XXXXX    20   0  231m 128m  23m S   15  1.6   4:50.16 srcds_i486
 2727 XXXXX    20   0  148m 104m 6500 S   14  1.3  10:44.13 q4ded.x86
 2957 XXXXX    20   0  264m 126m  16m S   10  1.6  13:57.24 srcds_i686
 2681 XXXXX    20   0  131m  72m 7200 S   10  0.9   8:50.61 preyded.x86
 2564 XXXXX    20   0  127m  70m 5188 S    9  0.9  10:19.39 doomded.x86
 2963 XXXXX    20   0  203m 120m  17m S    8  1.5   6:30.87 srcds_i486
 2965 XXXXX    20   0  252m 112m  16m S    7  1.4   5:20.50 srcds_i686
 2962 XXXXX    20   0  194m  85m  18m S    6  1.1   6:06.97 srcds_i486
 2964 XXXXX    20   0  268m 130m  16m S    6  1.6   5:19.77 srcds_i686
 2958 XXXXX    20   0  213m 105m  16m S    6  1.3   5:39.01 srcds_i686
 2959 XXXXX    20   0  240m 118m  16m S    6  1.5   5:14.06 srcds_i686
 2960 XXXXX    20   0  231m 124m  16m R    6  1.6   8:55.02 srcds_i686
 3603 XXXXX    20   0 93568  77m 6944 S    5  1.0   3:47.83 hlds_i686
 2968 XXXXX    20   0  225m 121m  21m S    4  1.5   3:51.96 srcds_i486
 2967 XXXXX    20   0  224m 121m  21m S    3  1.5   3:46.82 srcds_i486
 2961 XXXXX    20   0  232m 129m  23m S    2  1.6   5:16.59 srcds_i486
 2570 XXXXX    20   0 32048  11m 1568 S    1  0.2   1:14.84 samp02Xsvr
 2559 XXXXX    20   0  269m 125m 2528 S    1  1.6   1:14.46 cod2_lnxded
 2782 XXXXX    20   0  131m  67m 5088 S    1  0.8   0:31.76 ucc-bin-linux-a
 3851 root      20   0 18956 1332  940 R    1  0.0   0:00.02 top
    1 root      20   0 10312  756  628 S    0  0.0   0:00.92 init
    2 root      15  -5     0    0    0 S    0  0.0   0:00.00 kthreadd
    3 root      RT  -5     0    0    0 S    0  0.0   0:00.00 migration/0
    4 root      15  -5     0    0    0 S    0  0.0   0:00.10 ksoftirqd/0
    5 root      RT  -5     0    0    0 S    0  0.0   0:00.82 watchdog/0
    6 root      RT  -5     0    0    0 S    0  0.0   0:00.00 migration/1
    7 root      15  -5     0    0    0 S    0  0.0   0:00.00 ksoftirqd/1
    8 root      RT  -5     0    0    0 S    0  0.0   0:00.02 watchdog/1
    9 root      RT  -5     0    0    0 S    0  0.0   0:00.00 migration/2
   10 root      15  -5     0    0    0 S    0  0.0   0:00.00 ksoftirqd/2
   11 root      RT  -5     0    0    0 S    0  0.0   0:00.02 watchdog/2
   12 root      RT  -5     0    0    0 S    0  0.0   0:00.00 migration/3
   13 root      15  -5     0    0    0 S    0  0.0   0:00.00 ksoftirqd/3
   14 root      RT  -5     0    0    0 S    0  0.0   0:00.02 watchdog/3
   15 root      15  -5     0    0    0 S    0  0.0   0:00.60 events/0
   16 root      15  -5     0    0    0 S    0  0.0   0:00.26 events/1
   17 root      15  -5     0    0    0 S    0  0.0   0:00.28 events/2
   18 root      15  -5     0    0    0 S    0  0.0   0:00.72 events/3
   19 root      15  -5     0    0    0 S    0  0.0   0:00.00 khelper
   56 root      15  -5     0    0    0 S    0  0.0   0:03.80 kblockd/0
   57 root      15  -5     0    0    0 S    0  0.0   0:00.08 kblockd/1
   58 root      15  -5     0    0    0 S    0  0.0   0:00.00 kblockd/2
   59 root      15  -5     0    0    0 S    0  0.0   0:00.00 kblockd/3
   61 root      15  -5     0    0    0 S    0  0.0   0:00.00 kacpid
   62 root      15  -5     0    0    0 S    0  0.0   0:00.00 kacpi_notify
  145 root      15  -5     0    0    0 S    0  0.0   0:00.00 ksuspend_usbd
  151 root      15  -5     0    0    0 S    0  0.0   0:00.00 khubd
  154 root      15  -5     0    0    0 S    0  0.0   0:00.00 kseriod
  209 root      20   0     0    0    0 S    0  0.0   0:00.00 pdflush

Почему напрягают проц абсолютно пустые сервера? На старом Debian'e такого не было.

[Frank]

Похоже, игровые сервера ни разу не с поддержкой многоядерных конфигураций. Попробуй разнести процессы так, чтобы каждый юзал одно ядро - возможно, загрузка банально из-за перемещений процессов с одного ядра на другое. Как привязывать процессы к нужным ядрам - man taskset

[kokadzamba]

Спасибо за совет! Сейчас поюзаю. Но тогда получается, что старое ядро 2.6.18-26 всё понимало, а старшее 2.6.26-1 уже плохо понимает?

[Frank]

А старое ядро тоже было SMP, или таки нет?
Скорей всего старое ядро не умело распаралеливать однопоточные процессы.

[kokadzamba]

Да, старое ядро тоже было с поддержкой SMP. Что меня и удивило. Там раньше было, что если оно ядро перегружается, то другое ему помогает. Загрузка одного из ядер достигала 180% при большом онлайне. Если я сейчас привяжу пару серверов к одному ядру, то оно может войти в "тупик"?
На Ubuntu с ядром 2.6.27 всё работает как часы (на виртуальной машине), в чём же разница?

[Frank]

ДЗагрузка одного из ядер достигала 180% при большом онлайне

Это нонсенс Одно ядро может быть загружено только на 100%, т.к. работать за двоих оно никак не может. 180% это уже как минимум на два ядра.
Чтобы в top видеть нагрузку поядерно, а не суммарно (которая на 4 ядра может достигать, соответственно, 400%), нужно нажать 1

[kokadzamba]

Я это и делаю, на скрине в первом посте это видно. Но загрузка одного из ядер может быть больше 100% аданазначна!
Другое ядро может отдавать ресурс первому при необходимости - это я видел не раз, например во время архивации или полной загрузки сервера DOOM3. Поэтому вижу 130-180% в пике.

[Frank]

Другое ядро может отдавать ресурс первому при необходимости

Какой ресурс и каким образом? Перепайкой конвейнеров? Телепортацией регистров?
Это всё равно, что утверждать, что два человека копают одной лопатой быстрее. Да, если один из них устаёт - но процессоры не знают усталости, и вдвоём считать одно арифметическое действие они не могут. Если процесс не может быть распаралелен - он исполняется только на одном ядре. Попытка выполнять его на нескольких ядрах приведёт к падению производительности и повышенной загрузке ядер, учавствующих в таком идиотизме. Фактически, чем больше ядер в этом учавствуют, тем больше времени они тратят на передачу процесса с одного ядра на другое, и тем выше % загрузки в "простое".

[kokadzamba]

Ну спорить я с этим не буду, что видел у себя то и написал.
Мы отошли от сути проблемы...
Что ещё можно сделать для нормальной загрузки процессора при простое?
Вопрос в том, что я просто обновился с Debian 4 до Debian 5 и такая проблема появилась.

[Frank]

развести процессы по ядрам с помощью taskset
кстати, это может быть проблемой системы виртуализации, особенно если это Virtualbox

[kokadzamba]

Тоесть ко всему ещё отключить технологию виртуализации в BIOS (vanderpool)? Этот пункт там не активный.
А как выключить её в ядре?

[Frank]

Я угадал, это VirtualBox?

[kokadzamba]

Я угадал, это VirtualBox?

Это вроде программа такая, но я её не знаю. Мой сервак у провайдера, а дома юзаю виртуальную машину VMware 6. Хочу сначала разобраться там, чтобы не убить систему на серваке. Проц дома тот же (Q6600) и чипсет похожий (965), и ведёт себя Debian 500 одинаково.
Нужно разобраться в причине загрузки процессора сначала на домашнем компе...
Мне очень нужен хороший совет, желательно с примерами команд, так как в Linux я всего год и много ещё предстоит изучить!
Frank, большое спасибо за ответы! Где ещё поколупать?

[Frank]

Возможно, дело в модели многозадачности, применяемой к процессам в дебиане. Поставьте прогу schedtool и покажите, например,

Код: Выделить всё

schedtool `pidof q4ded.x86`

[kokadzamba]

xxxxx:~# schedtool `pidof q4ded.x86`
PID 2727: PRIO 0, POLICY N: SCHED_NORMAL , NICE 0, AFFINITY 0xf

xxxxx:~# schedtool `pidof srcds_i686`
PID 8134: PRIO 0, POLICY N: SCHED_NORMAL , NICE 0, AFFINITY 0xf
PID 7782: PRIO 0, POLICY N: SCHED_NORMAL , NICE 0, AFFINITY 0xf
PID 6743: PRIO 0, POLICY N: SCHED_NORMAL , NICE 0, AFFINITY 0xf
PID 5260: PRIO 0, POLICY N: SCHED_NORMAL , NICE 0, AFFINITY 0xf
PID 2966: PRIO 0, POLICY N: SCHED_NORMAL , NICE 0, AFFINITY 0xf
PID 2965: PRIO 0, POLICY N: SCHED_NORMAL , NICE 0, AFFINITY 0xf
PID 2959: PRIO 0, POLICY N: SCHED_NORMAL , NICE 0, AFFINITY 0xf


Вот что показало, это нормально?

[Frank]

Нормально, в убунту такие же полиси и шедулер по дефолту. Ну и аффинити маска указывает, что процессы не привязаны к определённому ядру, а бегают с одного на другое, загружая ядра работой по переброске процесса. Вы бы таки развели процессы по ядрам, и посмотрели бы, пропадёт ли паразитная нагрузка.

[kokadzamba]

Спасибо, попробую!

[kokadzamba]

xxxxx:~# schedtool `pidof srcds_i686`
PID 2774: PRIO 0, POLICY N: SCHED_NORMAL , NICE 0, AFFINITY 0x1
Не помогло.
Проверял на Ubuntu-8.10-server-amd64 - та же песня, сори что выше ввёл в заблуждение по поводу нормальной загрузки на ней.
Сейчас ставлю для проверки Debian-500-i386. Запущу те же сервера на нём для проверки.

[kokadzamba]

Система 32 бит ведёт себя совсем по другому. Cpu0,Cpu1 не загружены, а процесс 3156 пишет, что загрузка 37%. Как это может быть?

Код: Выделить всё

top - 20:42:27 up 42 min,  3 users,  load average: 0.05, 0.39, 0.35
Tasks:  65 total,   3 running,  54 sleeping,   8 stopped,   0 zombie
Cpu0  :  0.4%us,  1.3%sy,  0.0%ni, 98.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  0.8%sy,  0.0%ni, 99.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2027624k total,  1976908k used,    50716k free,    26320k buffers
Swap:   578300k total,       80k used,   578220k free,  1772904k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3156 root      20   0  260m 121m  16m R   37  6.1   0:25.64 srcds_i686
    1 root      20   0  2100  688  588 S    0  0.0   0:01.62 init
    2 root      15  -5     0    0    0 S    0  0.0   0:00.00 kthreadd
    3 root      RT  -5     0    0    0 S    0  0.0   0:00.06 migration/0
    4 root      15  -5     0    0    0 S    0  0.0   0:06.08 ksoftirqd/0
    5 root      RT  -5     0    0    0 S    0  0.0   0:00.00 watchdog/0
    6 root      RT  -5     0    0    0 S    0  0.0   0:00.08 migration/1
    7 root      15  -5     0    0    0 S    0  0.0   0:00.18 ksoftirqd/1
    8 root      RT  -5     0    0    0 S    0  0.0   0:00.00 watchdog/1
    9 root      15  -5     0    0    0 S    0  0.0   0:01.26 events/0
   10 root      15  -5     0    0    0 S    0  0.0   0:00.14 events/1

[kokadzamba]

Порешалось установкой ядра 2.6.31.6 с патчем patch-2.6.31.6-rt19. Теперь 10 серверов в простое занимают 4%.