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

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

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

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

Ответ 1

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

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

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

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

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

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

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

Edit:

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

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

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

Ответ 2

Я нашел, что это все о I/O.

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

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

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

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

Ответ 3

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

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

Ответ 4

То, что медленнее на реальном оборудовании, еще медленнее, когда система виртуализирована. Это зависит от используемой технологии виртуализации, насколько медленнее они становятся.

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

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