Bug 10157 - OpenVZ kernel scheduler behavior
: OpenVZ kernel scheduler behavior
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/kernel-image-ovz-smp)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2006-10-18 20:05 by
Modified: 2008-02-15 21:58 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2006-10-18 20:05:33
Для Hardware Node планировщик задач в ovz-smp#2.6.16-alt7 задействует только 
один процессор из доступных.
Т.е., на HN одновременно выполняется только одна задача, несмотря на наличие 
нескольких процессоров. 
Процессы из VPS распределяются планировщиком по процессорам равномерно, но не 
используют их полностью.

Проблема проявляется как на ядрах для i586, так и для x86_64. 
Подобное поведение делает нецелесообразным использование ядра на настольных 
многопроцессорных системах, где основная часть пользовательских процессов 
работает в пространстве HN.

При тех же настройках OpenVZ ovz-smp#2.6.16-alt3 равномерно распределяет 
нагрузку по процессорам как для процессов из HN, так и для процессов из VPS.

Steps to Reproduce:
Система - 2xOpteron-265, 2 ядра на процессор. Работающих VPS нет, сервис vz 
запущен. На одной из консолей запускался top, на другой - 4 процесса burnP6 из 
пакета cpuburn.
Actual Results:  
На ядре ovz-smp#2.6.16-alt7:

CPU0  :  0.0% us,  0.0% sy,  0.0% ni, 100.0% id,  0.0% wa,  0.0% hi,  0.0% si
CPU1  :  0.0% us,  0.0% sy,  0.0% ni, 100.0% id,  0.0% wa,  0.0% hi,  0.0% si
CPU2  :  0.0% us,  0.0% sy,  0.0% ni, 100.0% id,  0.0% wa,  0.0% hi,  0.0% si
CPU3  : 100.0% us,  0.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 8659 naf       25   0    20   12    4 R 26.7  0.0   0:04.50 burnP6
 8658 naf       25   0    24   12    4 R 25.7  0.0   0:04.51 burnP6
 8660 naf       25   0    20   12    4 R 24.3  0.0   0:04.53 burnP6
 8657 naf       25   0    20   12    4 R 23.3  0.0   0:04.52 burnP6


Expected Results:  
На ядре ovz-smp#2.6.16-alt3:

CPU0  : 100.0% us,  0.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
CPU1  : 99.7% us,  0.3% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
CPU2  : 100.0% us,  0.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
CPU3  : 100.0% us,  0.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
14422 naf       25   0    20   12    4 R 99.9  0.0   0:32.02 burnP6
14423 naf       25   0    20   12    4 R 99.9  0.0   0:31.65 burnP6
14421 naf       25   0    20   12    4 R 99.7  0.0   0:32.50 burnP6
14424 naf       25   0    16    8    4 R 99.7  0.0   0:31.28 burnP6
------- Comment #1 From 2006-10-22 14:48:29 -------
Reassigned to maintainer.
------- Comment #2 From 2006-10-26 01:56:37 -------
Я бы не назвал это багом, скорее фича Fair Scheduler. Зато при таком
планировании производительность VE не падает в случае загрузки HN. Насчет
"Процессы из VPS распределяются планировщиком по процессорам равномерно, но не 
используют их полностью." надо смотреть на выводы vzcpucheck.
------- Comment #3 From 2006-10-26 15:42:12 -------
Ну, пусть будет называться фичей.

Приведённая выше машина, 4 процессора. 1 VPS. Ядро -alt7.

# vzcpucheck -v
vpsid           units
-----------------------
0               1000
250202          1000
Current CPU utilization: 2000
Power of the node: 361879

Ограничений CPULIMIT нет.
Запускаем параллельно 4 штуки burnP6 в HN и VPS, соответственно.

На HN - полная загрузка 1 процессора, остальные бездействуют. Процессы делят
время примерно по-ровну, 23-26% на процесс. При дальнейшем увеличении загрузки
HN (добавлении процессов burnP6) они продолжают распределять по одному
процессору. Процессы время от времени мигрируют по камням, но все разом.

Назначение HN других значений cpulimit ситуацию не меняет. Кстати, при попытке
задать cpuunit где-то больше 120000 реально задаётся большее, т.к. при задании
cpuunit=120000  vzcpucheck показывает 125000, 200000 -> 250000, более 250000
задать нельзя.

На распределение процессов это всё равно не влияет, задействуется один процессор.


На VPS всё интереснее. 4 процесса - занимают 2 камня, причём один burnP6
монопольно живёт на одном из них, а три остальных делят второй. И не меняются.
5ый процесс запускается на третьем камне, и далее задействуются уже 3
процессора, с распределением времени на burnP6 - 100%,50%,50%,50%,50%.
Шестой burnP6 выравнивает распределение - все по 50%. 
Седьмой burnP6 даёт распределение 50%*4, 33%*3
Восьмой - 50%*4, 25*4
Девятый - 33%*9 - и по-прежнему один из процессоров не используется. И т.д.

Затем останавливаем процессы, и запускаем 8 штук заново одномоментно - и они
получают по 50% от каждого из процессоров!


Итого, данная фича:
а) не позволяет процессам в HN использовать более одного процессора
б) не позволяет VPS полностью загрузить процессоры системы при плавном
увеличении нагрузки, 
в) и в то же время позволяет резко возникшей нагрузке в VPS задействовать все
ресурсы процессора.

Для серверов с значительным числом равнозначных VPS, с чётким планированием
ресурсов и ограничений, данное поведение, похоже, правильное.
Но для настольных систем хотелось бы всё-таки использовать в HN все имеющиеся
ресурсы...
------- Comment #4 From 2007-04-05 23:36:52 -------
Думаю, это надо будет посмотреть ближе к 2.6.20
------- Comment #5 From 2007-04-06 09:18:41 -------
Указанное поведение исчезло с переходом на 2.6.18 - на последних ядрах (включая 
текущее 2.6.18-ovz-smp-alt12) распределение загрузки в HN снова равномерное по 
всем процессорам.
------- Comment #6 From 2008-02-15 21:57:37 -------
Раз починилось - уже не LATER
------- Comment #7 From 2008-02-15 21:57:58 -------
FIXED