Низкая производительность VirtualBox под Win10 - PullRequest
Новая
       44

Низкая производительность VirtualBox под Win10

1 голос
/ 04 ноября 2019

У нас есть система сборки, которая еще несколько недель назад занимала около 1,5 часов для полной сборки каждого целевого устройства.

В какой-то момент она была увеличена примерно до 3,5 часов, что,потому что мы строим для примерно девяти различных целей, мы увеличили время сборки с четырнадцати часов до примерно тридцати двух. Виртуальная машина, работающая на моем компьютере с Win10 (гость - Ubuntu 16.04), была скопирована на компьютер с Win7. Виртуальная машина была полностью неизменной с точки зрения ее настройки, типа дисков и т. Д. Машина была также очень похожа (тот же процессор, диски и т. Д.).

Кроме того, я изначально запускал VirtualBox 5.x, в то время как на коробке Win7 было 6.0.12, но я неНе думаю, что это проблема, так как обновление до 6.0.14 на моей коробке не изменилось. Даже перемещение диска виртуальной машины на SSD на моем компьютере не принесло особого облегчения, а это означает, что он почти наверняка привязан к процессору.

Каждый блок Win7, на котором работала виртуальная машина, собирался за 1,5 часа.

Тогда изменение только , которое мы внесли в этот ящик, было обновлением на месте до Win10, и, о чудо, сборки теперь также занимают 3,5 часа каждая.

Небольшое исследование показывает, что есть несколько людей, имеющих проблемы с VirtualBox / Win10 как хостом, так и гостем, но данный совет (увеличение видеопамяти, перебалансировка процессоров / памяти между хостом и гостем, включение / отключение ускорения видеои т. д.), похоже, ничего не исправляет.

Мы обдумываем несколько идей, таких как:

  • запуск Ubuntu на голом металле, но это, очевидно, затрудняет перемещение виртуальных машин
  • , где работают эти гости Ubuntu поверх Linux хостов, поэтому, если проблема заключается в Win10, мы получим повышение производительности при сохранении мобильности виртуальной машины;
  • придерживается Win10, но использует VMWare Player, а не VirtualBox (в настоящее время тестируется, чтобы убедиться, что это жизнеспособно);
  • возвращается к Win7 для коробок сборки, но я не думаю, что ИТ будут счастливыс этим предложением (т. е. без надежды снежинки на то, чтобы быть одобренным :-)).

Есть ли у кого-нибудь еще идеи о том, как идти вперед?

1 Ответ

3 голосов
/ 04 ноября 2019

Мы провели некоторое расследование, и оказалось, что виновником является смягчение Spectre2 / Meltdown, представленное в Windows 10.

Мы обнаружили на нескольких веб-сайтах, что воздействие было различным, но оно было наиболее вреднымдля создания ферм серверов и блоков разработчика (см., например, здесь ):

enter image description here

При отключении защиты с помощью GibsonИсследовательский инструмент InSpectre (разумеется, после проверки безопасности машины), количество сборок снова уменьшилось до полутора часов на цель.

Теперь нам просто нужно выяснить, какидти вперед в этом. Возможно, нам придется использовать машины с воздушными пробками, у которых уже есть готовый источник.

Некоторые дополнительные подробности. Все наши машины для разработчиков CPUID 306c3 Haswell, которые особенно сильно пострадали от смягчения. Мы собираемся протестировать его на более современном процессоре CPUID 810f10 (AMD Ryzen 5), чтобы увидеть, будет ли влияние меньше.

Если это так, мы можем купить несколько таких. В любом случае этот ответ будет обновлен с результатами.

Надеюсь, это будет окончательное обновление. Хотя первоначально нам удалось восстановить скорость, отключив средства смягчения Призрака / Расплавления на хосте Windows , это не было действительно жизнеспособным решением, учитывая возможность взлома.

Казалось, дальнейшее расследование показалочто, хотя VirtualBox пострадали в этой среде, VMware нет. Итак, мы пошли искать что-то, чтобы объяснить разницу.

В конце концов, мы столкнулись с этой веткой , которая описывала похожую проблему, и, попробовав одно из предложенных решений, мы обнаружили, что можемвосстановить скорость без компрометации операционной системы хоста.

Решение состоит в том, чтобы, пока ваша виртуальная машина выключена (не приостановлена), запустите следующую команду: 

vboxmanage modifyvm VM_NAME --spec-ctrl on

где VM_NAME должно быть заменено вашим действительным именем виртуальной машины (полученным с vboxmanage list vms). Затем, после перезапуска виртуальной машины, она должна снова работать с нормальной скоростью.

К сожалению, это означает, что мое экономическое обоснование получения новых компьютеров Threadripper для всей команды разработчиков теперь рухнуло. Блин, интернет: -)

...