kvm и qemu host: есть ли предел для максимальных процессоров (Ubuntu 10.04)?

Сегодня мы столкнулись с действительно странным поведением на двух идентичных хостах kvm и qemu (Dell R910). Каждая из хост-систем имеет 4 x 10 ядер, что означает, что 40 физических ядер отображаются как 80 в операционной системе (Ubuntu Linux 10.04 64 Bit, Kernel 3.0).

Мы запустили 32-битную виртуальную машину Windows 2003 (1 ЦП, 1 ГБ ОЗУ, мы несколько раз меняли эти значения) на одном из узлов и заметили, что до начала процесса загрузки прошло 15 минут. В течение этих 15 минут отображается черный экран и ничего не происходит. libvirt и хост-система показывают, что процесс qemu-kvm для гостя почти простаивает. в этом процессе показаны только некоторые записи FUTEX, но ничего особенного.

После этих 15 минут виртуальная машина Windows неожиданно начинает загрузку и появляется логотип Windows. Через несколько секунд виртуальная машина готова к использованию. Сама виртуальная машина очень производительна, так что это не проблема производительности.

Мы пытались закрепить процессоры инструментами virsh и taskset, но это только ухудшало ситуацию.

Когда мы загружаем виртуальную машину Windows с компакт-диска Linux Live, в течение нескольких минут также появляется черный экран, но не дольше 15. При загрузке другой виртуальной машины на этом хосте (Ubuntu 10.04) она также имеет проблему черного экрана, а также здесь черный экран отображается только в течение 2-3 минут (вместо 15).

Итак, лето так: каждый гость на каждом из этих идентичных узлов страдает от простоя через несколько минут после запуска. Через несколько минут процесс загрузки неожиданно запускается. Мы заметили, что время простоя происходит сразу после инициализации BIOS гостя.

У одного из наших сотрудников была идея ограничить количество процессоров с maxcpus=40 (из-за наличия 40 физических ядер) в Grub (параметр ядра), и внезапно исчезло поведение "черного экрана в режиме ожидания".

Поиск по спискам рассылки KVM и Qemu, Интернету, форумам, серверам и другим различным сайтам на предмет известных ошибок и т. Д. Не дал никаких полезных результатов. Даже вопрос в IRC-каналах разработчиков не принес новых идей. Люди там рекомендуют нам использовать закрепление процессора, но, как было сказано ранее, это не помогло.

Теперь у меня вопрос: есть ли ограничение на количество процессоров для хост-системы qemu или kvm? Просмотр исходного кода этих двух инструментов показал, что KVM будет отправлять предупреждение, если на вашем хосте более 255 процессоров. Но мы даже не царапаем этот предел.

Некоторые вещи о хост-системе:

3.0.0-20-server
kvm 1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4
kvm-pxe 5.4.4-7ubuntu2
qemu-kvm 0.14.0+noroms-0ubuntu4
qemu-common 0.14.0+noroms-0ubuntu4
libvirt 0.8.8-1ubuntu6
4 x Intel(R) Xeon(R) CPU E7-4870  @ 2.40GHz, 10 Cores

Изменить: Также попробовал ядро ​​3.2 (с параметром maxcpus не используется) - к сожалению, это ухудшило ситуацию. dstat показывает растущее количество контекстных переключений:

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
  0   0  99   0   0   0|1164k  638k|   0     0 |   0     0 |4972  6319 
  0   1  99   0   0   0|   0     0 |3456B 4847B|   0     0 |  18k   33k
  0   1  99   0   0   0|   0     0 |6126B 4550B|   0     0 |  17k   33k
  0   1  99   0   0   0|   0     0 |1772B 4139B|   0     0 |  17k   33k
  0   1  99   0   0   0|   0     0 |5507B 3674B|   0     0 |  17k   32k

Нормальные значения будут около 7000 для этой системы с одной виртуальной машиной вверх.

Изменить: я запустил хост-системы с maxcpus = 40 в качестве параметра загрузки. virsh nodeinfo показывает 40 физических ядер и никаких гипер поточных.

При запуске виртуальной машины ее "перерыв при загрузке" по-прежнему составляет около 30 секунд. В течение этого времени количество переключений контекста возрастает с 300 (в секунду) до 600 000 (в секунду). После 30 секунд черного экрана виртуальная машина начинает нормальный процесс загрузки, и переключатели контекста снижаются до <7000 в секунду:

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
  1   2  97   0   0   0| 943k    0 |  26k   12k|   0     0 |  22k   40k
  3   7  84   6   0   0|  26M   64k|  71k   18k|   0     0 |  10k   16k
  1   1  97   1   0   0|5282k 2560B|9751B   15k|   0     0 |  13k   23k
  1   4  95   0   0   0|1216k    0 |  14k   18k|   0     0 | 295k  592k
  1   3  96   0   0   0|   0    52k|5518B 7299B|   0     0 | 228k  456k
  1   3  96   0   0   0|  12k   24k|1228B 1514B|   0     0 | 258k  518k
  1   4  96   0   0   0|   0     0 |  14k   32k|   0     0 | 280k  565k
  1   3  96   0   0   0|   0     0 |  19k   38k|   0     0 | 284k  573k
  1   3  96   0   0   0|   0     0 |6465B 7203B|   0     0 | 288k  581k
  1   3  96   0   0   0|   0   172k|  26k   11k|   0     0 | 290k  584k
  1   3  96   0   0   0|   0     0 |  23k   11k|   0     0 | 288k  580k
  1   3  96   0   0   0|   0    12k|5678B 4556B|   0     0 | 289k  583k
  1   3  96   0   0   0|   0     0 |1192B 2929B|   0     0 | 288k  580k
  1   3  96   0   0   0|   0     0 |6304B   10k|   0     0 | 272k  547k
  1   3  96   0   0   0|4096B   52k|8330B   14k|   0     0 | 300k  605k
  1   3  96   0   0   0|   0    24k|  11k   20k|   0     0 | 293k  591k
  1   3  96   0   0   0|   0     0 |  13k   28k|   0     0 | 291k  587k
  1   3  96   0   0   0|   0   512B|  10k   18k|   0     0 | 291k  587k
  2   3  95   0   0   0|   0     0 |6653B   10k|   0     0 | 167k  337k
  3   0  97   0   0   0|   0   160k|  23k 5524B|   0     0 |  10k   19k
  7   0  92   0   0   0|   0    36k|  22k 3335B|   0     0 | 949   924 
 10   0  90   0   0   0|   0     0 |5172B 3318B|   0     0 | 908   923 
  5   0  94   0   0   0|   0     0 |2234B 2825B|   0     0 | 846   875

Изменить: В соответствии с просьбой, я добавлю выдержку из strace -f -p:

25734 <... read resumed> "\16\0\0\0\0\0\0\0\376\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0"..., 128) = 128
25752 futex(0x927e60, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
25734 rt_sigaction(SIGALRM, NULL, {0x4b2300, ~[KILL STOP RTMIN RT_1], SA_RESTORER, 0x7fe09ac108f0}, 8) = 0
25734 write(8, "\1\0\0\0\0\0\0\0", 8)   = 8
25734 read(15, 0x7fffcea69f70, 128)     = -1 EAGAIN (Resource temporarily unavailable)
25734 timer_gettime(0x1, {it_interval={0, 0}, it_value={0, 0}}) = 0
25734 timer_settime(0x1, 0, {it_interval={0, 0}, it_value={0, 250000}}, NULL) = 0
25734 timer_gettime(0x1, {it_interval={0, 0}, it_value={0, 182592}}) = 0
25734 futex(0x927e60, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
25752 <... futex resumed> )             = 0
25734 <... futex resumed> )             = 1
25752 futex(0x927e60, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
25734 select(25, [7 10 14 15 16 17 18 24], [], [], {1, 0} <unfinished ...>
Источник

2 ответа

Решение

Как рекомендуют в одном из комментариев (спасибо cperrin88), Ubuntu 12.04 принесла решение. Некоторые параметры:

  • Ядро 3.2
  • 80 ядер (40 физических, 80 из-за Intel HT)
  • kvm 1: 84 + dfsg-0ubuntu16 + 1.0 + нормы + 0ubuntu13
  • kvm-ipxe 1.0.0 + git-3.55f6c88-0ubuntu1
  • qemu-kvm 1.0 + noroms-0ubuntu13
  • libvirt 0.9.8-2ubuntu17.1

Гость Windows теперь показывает панель загрузки в течение первых 30 секунд загрузки, а затем просто загружается (нормальное поведение).

Количество переключений контекста теперь очень мало по сравнению со сценарием, который у меня был ранее (между 200 и 24k в секунду).

Итак, проблема решена. Мне просто нужно выяснить, что изменилось (я думаю, это была ошибка в KVM).

Спасибо за все комментарии и ваши усилия!

Источник

Я встречал довольно много ошибок с KVM на Ubuntu 10.04. (который я все еще должен использовать), включая растущие кэши, которые меняются местами, и серьезные проблемы с производительностью.

Я рекомендую перейти на последнюю версию LTS в надежде, что она исправит несколько ошибок.

Источник
Другие вопросы по тегам