Bug 10157 - OpenVZ kernel scheduler behavior
Summary: OpenVZ kernel scheduler behavior
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: kernel-image-ovz-smp (show other bugs)
Version: unstable
Hardware: all Linux
: P2 normal
Assignee: Evgeny Sinelnikov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-18 20:05 MSD by Nikolay A. Fetisov
Modified: 2008-02-15 21:58 MSK (History)
15 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolay A. Fetisov 2006-10-18 20:05:33 MSD
Для 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 Dmitry V. Levin 2006-10-22 14:48:29 MSD
Reassigned to maintainer.
Comment 2 Konstantin A Lepikhov (L.A. Kostis) 2006-10-26 01:56:37 MSD
Я бы не назвал это багом, скорее фича Fair Scheduler. Зато при таком
планировании производительность VE не падает в случае загрузки HN. Насчет
"Процессы из VPS распределяются планировщиком по процессорам равномерно, но не 
используют их полностью." надо смотреть на выводы vzcpucheck.



Comment 3 Nikolay A. Fetisov 2006-10-26 15:42:12 MSD
Ну, пусть будет называться фичей.

Приведённая выше машина, 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 Konstantin A Lepikhov (L.A. Kostis) 2007-04-05 23:36:52 MSD
Думаю, это надо будет посмотреть ближе к 2.6.20
Comment 5 Nikolay A. Fetisov 2007-04-06 09:18:41 MSD
Указанное поведение исчезло с переходом на 2.6.18 - на последних ядрах (включая 
текущее 2.6.18-ovz-smp-alt12) распределение загрузки в HN снова равномерное по 
всем процессорам.
Comment 6 Mikhail Gusarov 2008-02-15 21:57:37 MSK
Раз починилось - уже не LATER
Comment 7 Mikhail Gusarov 2008-02-15 21:57:58 MSK
FIXED