Ужасная производительность диска VirtualBox (РЕШЕНО)
Производительность виртуальной машины зависит от выделенных ей ресурсов (количество ядер центрального процессора, количество оперативной памяти) и от количества запущенных программ в виртуальной машине и их требовательности к ресурсам. Это логично и работает примерно так, как интуитивно ожидается.
Но при интенсивном использовании диска в виртуальной машине её производительность падает непропорционально драматически. Например, установка пакета, содержащего большое количество файлов, в гостевой машине Linux может растянуться на часы! Это при том, что аналогичный пакет на реальном компьютере устанавливается за минуты. Обновление Windows могут замедлить работу виртуальной машины до полной её неработоспособности.
Всё это замедляет работу и портит впечатление от работы с виртуальными машинами.
Данную проблему можно исправить, включив «Кэширования ввода/вывода» для виртуального диска.
Чтобы включить «Кэширования ввода/вывода»:
Вы также можете проверить любые другие контроллеры и/или диски, чтобы увидеть, есть ли там эта опция.
Сохраните настройки и запустите виртуальную машину, и вы увидите большое улучшение производительности при интенсивном использовании диска.
Есть объяснение, почему эта нужная опция по умолчанию выключена — у неё есть некоторые недостатки. Если коротко, авторы VirtualBox исходят из концепции «безопасность важнее производительности». Рассмотрим подробнее, какие последствия может нести включение этой опции:
1. Отложенная запись через кэш ОС хоста менее безопасна. Когда гостевая ОС записывает данные, она считает данные записанными, даже если они фактически ещё не прибыли на физический диск. Если по какой-то причине запись не произойдёт (сбой питания, сбой хоста), вероятность потери данных увеличивается.
2. Файлы образов дисков обычно очень большие. Поэтому их кеширование может быстро израсходовать весь кэш ОС хоста. В зависимости от эффективности кэширования ОС хоста, это может сильно замедлить работу хоста, особенно, если несколько виртуальных машин работают одновременно. Например, в Linux хостах кэширование хоста может привести к тому, что Linux отложит все записи до момента, когда кэш хоста почти заполнен, и затем все эти изменения записываются в один раз, это может привести к остановке выполнение виртуальной машины на несколько минут. А это в свою очередь может привести к ошибке I/O (ввода-вывода) в гостевой системе, поскольку время запросов ввода-вывода истекло.
3. Напрасно расходуется физическая память, поскольку в гостевых операционных системах обычно имеются собственные кеши ввода-вывода, то включение ещё одного может привести к двойному кэшированию (как в гостевой, так и в хост машинах) без особого положительного эффекта.
Даже если отключить кэширование ввода-вывода хоста по указанным выше причинам, VirtualBox использует свой собственный небольшой кеш для буферизации записи, но не чтения кэширование, поскольку это обычно уже выполняется гостевой ОС. Кроме того, VirtualBox полностью поддерживает асинхронный ввод-вывод для своих виртуальных контроллеров SATA, SCSI и SAS через несколько потоков ввода-вывода.
На самом деле практика показывает, что данные не теряются, а включение данной настройки отлично сказывается на производительность.
Кроме описанного способа есть ещё один вариант для продвинутых пользователей. Суть в том, что в качестве диска виртуальной машины используется реальный USB диск. С такого диска можно загрузиться как в VirtualBox, так и на физическом компьютере. При этом производительность приближается к работе реального компьютера — никаких задержек, операции обновления и установки больших пакетов происходят с той же скоростью, как на реальном компьютере. О том, как это сделать, смотрите в статье «Как в VirtualBox загрузиться с USB».
Как ускорить работу VirtualBox?
Время от времени приходиться работать виртуальными машинами в VirtualBox, но вас категорически не устраивает скорость их работы? В этой статье мы постараемся рассказать как ускорить VirtualBox!
Будь вы разработчик ПО или веб-дизайнер или техно гик интересующийся новинками, медленная работа виртуальной машины не нравится ни кому. Одной из популярных виртуальных машин, к тому же еще и бесплатной, является Oracle Virtualbox.
Ускорить работу VirtualBox
О том как сделать так, чтобы виртуальные операционные системы работали в нем быстрее мы расскажем вам далее.
Комплектующие вашего сервера или ПК
Самым весомым аргументом в быстрой работе ОС в Virtualbox является высокопроизводительные комплектующие. Для более или менее комфортной работы вам потребуется:
На более медленном железе заставить быстро работать VirtualBox у вас не получиться, чтобы вы не делали.
Настраиваем UEFI/BIOS
Современные процессоры Intel и AMD обладают возможностью аппаратной виртуализации, включение этой опции в UEFI/BIOS может значительно ускорить работу виртуальной машины VirtualBox. Для этого необходимо включить параметры Intel VT-x или AMD-V.
Настраиваем VirtualBox
Теперь рассмотрим те опции которые следует включить или изменить в VirtualBox, для ускорения работы виртуальной машины.
Расположение виртуальных машин
Если ваш компьютер обладает более чем одним диском (HDD или SSD), то самой первоначальной настройкой которую стоит изменить — это «папка для машин по умолчанию». Выполнить данную настойку необходимо потому что, при работе отдельных программ и ОС могут вызвать задержки в дисковой подсистеме, чтобы этого не происходило, необходимо размещать «виртуалки» на другом диске.
Еще лучше, если это будет SSD диск. Единственно на что стоит обратить внимание, так это то, что не стоит указывать внешний накопитель, так скорость обращения чтения/записи будет значительно ниже, чем с внутренних дисков.
Чтобы задать «папку по умолчанию», вам необходимо на панели выбрать «Файл» и перейти во вкладку «Общее».
Настройки при создании виртуальных машин
Во время создания виртуальной машины следует обратить внимание на следующее параметры:
Настройка параметров виртуальной машины
После того как виртуальный жесткий диск был создан, можно выполнить настройку,
чтобы выделить ОС какие-либо ресурсы.
Раздел «Система»
В разделе «Система» вкладка «Процессор» поставьте галочку напротив «Включить PAE/NX» если вы виртуальной системе предоставили более 4 GB.
Укажите приемлемое количество ядер процессора.
Во вкладке «Ускорение» включите аппаратную виртуализацию поставив галочку напротив «Включить VT-x/AMD-V» и «Включить Nested Paging».
В выпадающем списке «Интерфейс паравиртуализации» укажите:
Раздел Дисплей
В разделе «Дисплей» поставьте галочку напротив «Ускорение: Включить 3D-ускорение», если вы используете ОС Windows, то также отметить и «Включить 2D-ускорение».
Задайте максимальное количество видеопамяти. Здесь стоит отметить что из интерфейса VirtualBox нельзя указать количество видео памяти более 128 МБ, чтобы указать больше (до 256 МБ), выполните следующие действия:
Раздел «Носители»
В разделе «Носители» выберите виртуальный контроллер SATA на котором будет установлено (или уже установлена) виртуальная машина и поставьте галочку напротив «кэширование ввода/вывода»
После установки виртуальной системы
После того как вы установите операционную систему в виртуальную машину, следует сразу же стоить подключить дополнения гостевой ОС и установить «драйвера» для виртуальных Windows или Linux и перезагрузить систему.
Что еще может ускорить работу VirtualBox?
Если вы выполнили все шаги, что мы написали выше, тогда дополнительную каплю в повышение производительности виртуальной системы вам помогут следующие действия:
Остались еще вопросы? Пишите их в комментариях, рассказывайте, что у вас получилось или наоборот!
Вот и все! Больше статей и инструкций читайте в разделе Статьи и Хаки Android. Оставайтесь вместе с сайтом Android +1, дальше будет еще интересней!
virtualbox медленно работает
ещё скажи, сколько оперативки выделил для ВМ, и сколько её всего в хосте. Ну и версия федоры интересна.
убунту с юнити очень сильно тормозит на виртуалке сносить юнити и ставить менее тормозное де
У тебя какой-то неправильный VB.
аппаратная виртуализация, конечно же, есть на процессоре, и включена в биосе? 😉
Какой диск используется, какая файловая ситема, какого возраста она?
Дело не только в тормознутости интерфейса, а системы в целом. Например, обновление пакетов из консоли в гостевой ОС происходит намного дольше (именно их распаковка/установка). Система задумывается над каждым чихом.
ну это и не в VB проблема. У меня тоже медленно ставится, причём на нормальное(не виртуальное) железо с 1.5Гб. _Очень_ медленно.
Но дело не в ней, т.к. такие тупняки абсолютно в любой гостевой ОС.
сейчас все дистры много памяти жрут на установке.
Система задумывается над каждым чихом.
Диск под гостевую ОС фиксированного размера или динамический? Если динамический, то затык может быть в этом.
Медленный диск и динамический образ.
Сделай preallocated.
🆘 Как исправить зависание Ubuntu в VirtualBox
Если вам интересно узнать о Linux, но его недостаточно для замены macOS или Windows, то запуск его на виртуальной машине – отличный вариант.
VirtualBox является одной из самых популярных виртуальных машин по множеству причин, одной из которых является то, что она бесплатна для использования.
Виртуальные машины – это сложные вещи, и когда что-то идет не так, сложно сказать, в чем проблема.
Это особенно верно, если вы работаете в Ubuntu и она постоянно зависает.
Если это происходит с вами, попытка выяснить, в чем проблема, может быть закончена разочарованием.
Отключить 3D ускорение
Независимо от того, используете ли вы Windows, macOS или даже Linux, 3D-ускорение может вызвать множество проблем в VirtualBox.
Хотя это звучит как то, что вам нужно, оно редко позволяет добиться реального повышения производительности.
Если вы сталкиваетесь с зависанием, попытайтесь отключиться его одним из первых.
В меню слева в VirtualBox щелкните правой кнопкой мыши виртуальную машину Ubuntu, с которой у вас возникли проблемы, затем выберите «Настройки».
Здесь щелкните вкладку «Отображение» и убедитесь, что «Включить 3D-ускорение» не выбрано.
Изменить количество виртуальных процессоров
Хотя компьютеры, продаваемые на компьютеры, обычно имеют только один физический процессор, они имеют несколько ядер, которые действуют как несколько процессоров.
Тем не менее, VirtualBox по умолчанию предоставляет только один виртуальный процессор, который, как было показано, вызывает проблемы с Ubuntu, особенно в последних версиях.
Если вы сталкиваетесь с зависанием, вы можете увеличить число процессоров с двух до четырех.
Щелкните правой кнопкой мыши на вашей виртуальной машине, выберите «Настройки» и перейдите на вкладку «Система».
Здесь выберите процессор в верхней части раздела и поднимайте ползунок до тех пор, пока число процессоров не станет равным двум.
Другие варианты
Существуют и другие варианты, которые, по мнению разных пользователей, решают проблемы с зависанием.
В том же разделе, где вы можете изменить количество процессоров, есть опция «Включить PAE / NX».
Отключите этот параметр, если он уже включен, или включите, если оно уже выключено,это может решить вашу проблему.
Вы также можете попробовать изменить настройки паравиртуализации.
Зайдите в Настройки, затем выберите Система и Ускорение.
Интерфейс паравиртуализации, скорее всего, будет установлен на «По умолчанию», но некоторые пользователи добились лучших результатов, установив его на «Минимальный».
Попробуйте другую версию VirtualBox
Ни одна программа не лишина ошибок, и это касается как Ubuntu, так и VirtualBox.
Некоторые пользователи обнаружили, что разные версии VirtualBox и Ubuntu иногда просто не ладят.
Если определенная версия Ubuntu никогда не зависала в прошлом, вы можете попробовать установить более старую версию VirtualBox.
И наоборот, вы можете попробовать запустить более новую версию Ubuntu.
Возможно, вы не только решите проблему зависания, но и получите новые функции.
Заключение
Надеемся, что один из приведенных выше вариантов решил вашу проблему с зависанием в Ubuntu.
Если у вас все еще есть проблемы, не теряйте надежду.
Попытка различных комбинаций вышеупомянутых вариантов могла бы быть решением для Вас.
Не позволяйте одному неудачному опыту отвлечь вас от использования Linux или виртуальных машин.
Почему виртуалки “на вырост” начинают тормозить, и что с этим делать новичку
Клиенты все чаще мигрируют в облака в погоне за гибкостью: здесь намного проще добавить диск, память и процессоры, если чего-то не хватает. Но иногда новички обнаруживают, что добавление ресурсов перестает помогать. Скорость работы не растет, а с бэкапом и восстановлением начинаются проблемы.
Сегодня вместе с @kvolodin мы расскажем, почему бесконечное увеличение ресурсов ВМ может вредить пользователям и как спланировать рост производительности очевидными, но действенными способами. Статья полезна тем, кто переехал или планирует переезд в облако и еще знакомится с нюансами облачной среды.
Очевидные причины: ограничения железа и бэкапов
Сейчас в нашем облаке добавление ресурсов сверх лимита можно ограничить на уровне софта. Если кто-то попробует выйти за пределы, сразу получит сообщение в интерфейсе Cloud Director:
Но так было не всегда. В старых версиях vCloud Director мы не могли жестко ограничить некоторые параметры и прописывали лимиты только в договоре. К сожалению, иногда информация из контракта даже не попадала к инженерам клиента, и они могли почувствовать последствия на своей шкуре.
Много лет назад мы предоставили клиенту квоту в 20 ТБ и предупредили про ограничение на диск в 16 ТБ. Резервное копирование данных делали с помощью Veeam Backup&Replication. Когда клиент вышел за пределы диска в 16 ТБ, все задачи на создание бэкапов просто зависли. Veeam не успевал забэкапить большую ВМ и на всякий случай оставлял неполный снэпшот, а затем создавал новый. Дерево снэпшотов стало расти слишком быстро, общая производительность диска тоже упала. Пришлось полночи заново создавать дерево снэпшотов, а затем переносить данные на диски поменьше.
В те времена от подобных инцидентов нас защищал мониторинг. Мы сразу видели непорядок на дашбордах и обращали внимание клиента на проблему. Трудность была в том, что в случае IaaS сами виртуалки оставались ответственностью клиента. Инженеру клиента нужно было самому пересоздавать ВМ, иногда с большим трудом.
Клиенту выделили квоту в 40 ТБ на СХД, а для диска ВМ прописали ограничение в 20 ТБ. Администратор клиента создал ВМ в 30 ТБ и разметил все дисковое пространство одним диском. Техподдержка обнаружила проблему, сообщила клиенту, что нужно пересоздать ВМ с дисками меньшего размера, но администраторы долго не выходили на связь.
В это время данные начали записываться на созданный диск большими темпами. Пока на СХД было свободное место, мы увеличивали размер дата-стора и ждали ответа от клиента. Но если бы расширять дата-стор дальше было невозможно, клиенту пришлось бы рисковать данными. Нужно было бы создать новый диск и перегнать данные на него. Миграция такой большой ВМ могла потребовать несколько дней, и оставалась вероятность неудачного переезда.
Базовые лимиты защищают клиента от многих проблем и позволяют обслуживать железо в штатном режиме. Мы не допускаем разрастания ВМ до пределов физического диска и избегаем трудностей с миграцией. Добавить ресурсы по запросу клиента по-прежнему можно, но только если в этом правда есть необходимость.
Но даже если физический лимит не превышен, могут возникнуть другие трудности.
Неочевидная работа гипервизора
Если виртуальная машина в облаке начинает тормозить и захлебываться, клиент чаще всего ищет причину в нехватке ресурсов. Увеличение виртуальной машины кажется логичным и быстрым ходом. Но в некоторых случаях расширение только ухудшает скорость работы.
У клиента регулярно возникали пиковые периоды активности. Раз в месяц нагрузка на системы увеличивалась и требовала больше процессоров. Клиент решил не отключать эти процессоры после пика, а оставить их про запас. Но в период низкой активности производительность упала и не давала выполнять рутинные задачи. Дело в том, что гипервизор “отодвинул” недозагруженные системы на второй план. Так работает планировщик: если ВМ не требует ресурсов, то в очереди она спускается ниже.
Клиенту облака по умолчанию доступна только информация из диспетчера задач и монитора ресурсов. Бывает и так, что на ОС клиент видит загрузку части ядер на 100%. В это же время мы на гипервизоре видим, что часть ядер не используется, потому что приложение не рассчитано на многопоточность. В таких ситуациях парадоксальным образом помогает именно уменьшение ресурсов до необходимого и достаточного уровня. После этого гипервизор лучше распределяет небольшие ВМ в очередях.
Некорректный сайзинг приложения в облаке
К сожалению, переезд приложения с физических хостов не всегда возможен “в лоб”. Даже если все работало на физических 24 процессорах, столько же процессоров в облаке не всегда решают проблему.
Один из клиентов перед переездом на новое железо решил временно разместить в облаке виртуальную АТС. Мы заглянули в документацию вендора и обнаружили явную несовместимость с vCloud Director. Производители АТС изначально не гарантировали стабильную работу своего приложения в облачной среде. Тем не менее, нашим инженерам удалось настроить работу софта с помощью нескольких хитростей. Клиент спокойно работал в облаке, пока не дождался поставки собственного железа. Но если бы он захотел внести изменения в настройки, возникли бы трудности.
У крупных производителей софта несовместимость с облаком сразу прописана в документах. Менее очевидно дело обстоит с самописным ПО.
Клиент заказал виртуальную машину для переезда собственного приложения в облако. Через пару месяцев работы софт начал сильно тормозить. При аудите выяснилось, что объемные файлы по умолчанию сохраняются в одну директорию и нагружают файловую систему. За несколько месяцев там накопились уже миллионы файлов, и для решения проблемы понадобилась новая архитектура с несколькими хранилищами.
Даже если случай не такой экстремальный, при переезде с физических хостов не помешает пересмотреть подход к сайзингу приложения, изменить модель потребления ресурсов.
Например, бывают ситуации, когда пользователь привык к быстрой работе на ноутбуке с высокочастотными процессорами, а в облаке сталкивается с низкой скоростью. Характеристики Enterprise-железа в дата-центре рассчитаны на долгосрочную работу в режиме 24/7 и не допускают пограничных состояний. Если такой пользователь разгонял процессоры на своем ноутбуке до опасного максимума, то в облаке он не сможет добиться тех же скоростей от похожего процессора.
Случается и так, что приложение рассчитано на высоконагруженную базу, но размещается в облаке на SATA-дисках. Клиент видит загрузку процессоров и увеличивает ресурс CPU, не подозревая проблемы именно с дисками.
В то же время облако дает лучшие результаты при оптимизации приложения под несколько хранилищ. На физических хостах у разработчика меньше возможностей для маневра: как правило, все хранится на локальных одинаковых дисках. В облаке появляется вариативность: можно выбрать разные диски для разных типов хранения и даже немного сэкономить.
Один из клиентов хранил в своей базе данные трекинговой системы за три года ― такой срок хранения был предусмотрен нормативом. После переезда в облако удалось разделить хранилище на “холодное” и “горячее”. Редко используемые данные перемещались на медленные и дешевые “холодные” диски, а востребованная информация оставалась на быстрых дисках в “горячем” хранилище.
Подозрительная активность на ВМ
Когда снижение производительности подкрадывается постепенно, то переход на более производительные диски может и правда решить проблему. Если же загрузка ресурсов выросла резко, скорее всего, дело в шифровальщике или залетном майнере криптовалюты.
Неправильная настройка облачного межсетевого экрана у новых клиентов встречается не так уж редко. Иногда администраторы разрешают на граничном маршрутизаторе всем и все, а потом забывают об этом. Если мошенник обнаруживает уязвимость и завладевает машиной, то он забирает все ресурсы сразу, и докидывание процессоров не решает проблему.
Откуда берутся лимиты на ресурсы в облаке
Ограничения на диск
Есть технические ограничения СХД. Яркий пример: блочный том многих моделей NetApp не может быть более 16 ТБ.
Мы как провайдер провели тесты производительности СХД и рассчитали оптимальный размер дата-стора.
Инфраструктура резервного копирования лучше справляется с бэкапом нескольких мелких объектов, чем одного большого.
Ограничения на CPU и память
Ограничен размер физического хоста, на котором располагаются ВМ клиентов.
При размере хоста 144 vCPU и 2 TБ памяти ВМ большего размера не получится создать при всем желании. (Cпасибо, кэп!)
Для оптимального обращения к памяти мы учитываем особенности работы мультипроцессорных систем. Мы уже рассказывали об этом в статье про первую виртуальную машину.
У клиента может быть сервис, который сам эффективно распределяет ресурсы памяти, ― тогда проблем не возникнет. В остальных же случаях нужно настраивать лимиты.
С помощью некоторых лимитов мы можем управлять виртуальной платформой и предоставлять предсказуемый сервис с соблюдением SLA.
Ограничения на IOPS
В облаке также встречаются клиенты, у которых намного выше среднего параметры IOPS: количество операций ввода/вывода. Чаще всего это происходит в трех случаях:
Клиент решил протестировать выделенные мощности на больших нагрузках.
У клиента наблюдается аномальная нагрузка, например, из-за некорректной работы самописного софта или вирусов.
Клиент установил высокопроизводительное приложение.
На любой из этих случаев мы задаем ограничения потребляемых дисковых мощностей, опираясь на результаты нагрузочного тестирования СХД. Сейчас можем ограничить каждый диск фиксированным значением IOPS или исходить из IOPS на ГБ.
Как новому клиенту вписаться в лимиты и обеспечить производительность
При планировании переезда в облако ознакомиться с документацией на ПО. Некоторые производители софта сразу указывают, что их приложение не работает в облачной среде.
До переезда протестировать работу приложения в облачной инфраструктуре. Большинство провайдеров позволяют клиентам брать пробный период и запускать синтетические тесты.
Не стесняться обращаться в техподдержку. Инженеры могут оценить производительность со стороны гипервизора и дать рекомендации.
Расти маленькими шагами: увеличить диски намного проще, чем резко их уменьшить. Увеличивать процессоры тоже лучше постепенно, начинать с одного ядра.
Расти не вертикально, а горизонтально. Например, не добавлять 8 процессоров на одну ВМ, а создать 4 ВМ по 2 процессора на каждой. Вдобавок это уменьшит площадь отказа.
Ставить виртуальные машины на внутренний мониторинг. В этом случае клиент может выбрать наиболее важные показатели работы ВМ и быстро получать оповещения об их состоянии. Это позволит вычислять неочевидные проблемы, которые не заметны на общем мониторинге.