Оптимизация программного обеспечения для виртуальных машин

Question

Если вы знаете, что ваше программное обеспечение (не драйвер, не часть операционной системы, а просто приложение) будет работать в основном в виртуализированной среде, существуют ли стратегии оптимизации вашего кода и/или настроек компилятора?Или какие-нибудь руководства о том, что вам следует и не следует делать?

Речь идет не о приросте производительности на 0,0x%, но, возможно, просто возможно, есть простые вещи, которые радикально улучшат производительность, или вещи, которые кажутся простыми, но, как известно, являются катастрофическими в виртуализированных средах.Например, включить CONFIG_PARAVIRT в сборке ядра легко и это может значительно повысить производительность.Сейчас ищу подобные приложения, если они есть.

В моем случае это будет код C++ и, возможно, VMWare, но я хочу, чтобы вопрос был максимально независимым от языка/продукта.Интересно, существуют ли вообще такие стратегии или это будет пустая трата времени - ведь концепция виртуализации заключается в том, что вам не нужно слишком сильно об этом заботиться.

Answer 1

Единственный совет, который я могу вам дать, это осторожное использование mlock()/mlockall()..высматривая водителей воздушных шаров с ошибками.

Например, если гость Xen загружается с 1 ГБ, а затем увеличивается до 512 МБ, очень типично, что привилегированный домен НЕ смотрит на то, сколько памяти на самом деле обещало процессам паравиртуализированное ядро ​​(т. е.Зафиксировано_AS).На самом деле, при использовании Xen, если это значение не размещено в Xenbus, привилегированный хост понятия не имеет, что будет делать такой воздушный шар.Полагаю, это тоже совпадает с KVM, смотря как настроено ядро..но ваш вопрос предполагает, что мы ничего не знаем о таких вещах :)

Итак, защищайте вещи (будьте осторожны, но благоразумны), которые просто невозможно выгрузить, всегда учитывайте сценарий «небо падает».

Аналогично, использование posix_fadvise()/posix_madvise(), чтобы сообщить ядру PV, насколько вам нужна или не нужна буферизация, всегда является хорошей идеей.

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

Я не часто использую KVM (пока), хотя планирую изучить его подробнее в будущем.Однако 90% того, что я пишу в последнее время, специально разработано для работы на паравиртуализированных гостях Xen.Извините, что я немного ориентирован на Xen/C, но мой опыт именно в этом, и pv_ops находится в основной ветке (скоро также xen-0 ops) :)

Хороший вопрос, кстати :)

Редактировать:

Когда я сказал «осторожный, но осмотрительный», я имел в виду на шаг выше консерватора.Если ваша программа выделяет некоторую структуру заданий, необходимую большинству функций, заблокируйте ее.Если вы выделяете буферы для чтения огромных файлов, не блокируйте их..и обязательно вызовите posix_fadvise(), чтобы сообщить ядру, что вы собираетесь получить к нему доступ только один раз (если это так).Кроме того, обязательно сообщите ядру об использовании файлов, отображаемых в памяти, особенно если они служат для организации параллелизма.

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

Извините за двусмысленность.Лучшая фраза, которую я смог придумать, была «осторожна, но благоразумна».

Answer 2

Я обнаружил, что все дело в вводе-выводе.

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

Обмен особенно вреден: он полностью снижает производительность виртуальной машины, даже немного, поскольку ввод-вывод очень медленный.

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

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

Answer 3

Мой единственный совет - держите память и IO по возможности на низком уровне.

IO в виртуальной машине довольно медленный по сравнению с физическим оборудованием. Если вы можете избежать этого, то избегайте этого.

Answer 4

Вещи, которые медленны на реальном оборудовании, еще медленнее, когда система виртуализирована. От того, насколько медленнее они станут, зависит от используемой технологии виртуализации.

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

Если возможно, представьте, что вы пишите для десятилетнего компьютера. Если ваше приложение будет работать на настольном ПК или ноутбуке 1999 года, оно должно работать нормально.