Для 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
Reassigned to maintainer.
Я бы не назвал это багом, скорее фича Fair Scheduler. Зато при таком планировании производительность VE не падает в случае загрузки HN. Насчет "Процессы из VPS распределяются планировщиком по процессорам равномерно, но не используют их полностью." надо смотреть на выводы vzcpucheck.
Ну, пусть будет называться фичей. Приведённая выше машина, 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 все имеющиеся ресурсы...
Думаю, это надо будет посмотреть ближе к 2.6.20
Указанное поведение исчезло с переходом на 2.6.18 - на последних ядрах (включая текущее 2.6.18-ovz-smp-alt12) распределение загрузки в HN снова равномерное по всем процессорам.
Раз починилось - уже не LATER
FIXED
