Bug 10157
| Summary: | OpenVZ kernel scheduler behavior | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Nikolay A. Fetisov <naf> |
| Component: | kernel-image-ovz-smp | Assignee: | Evgeny Sinelnikov <sin> |
| Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P2 | CC: | aspsk, boris, boyarsh, glebfm, ldv, mike, mithraen, rider, sbolshakov, shrek, sin, vitty, vsu, vvk, zerg |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
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 |
Description
Nikolay A. Fetisov 2006-10-18 20:05:33 MSD