Виртуальная память в виртуализированных машинах (Swap File in VM?)
Каково мнение о разрешении виртуальной памяти внутри виртуальной машины?
Например, на хост-машине с 8 гигабайтами памяти я мог бы запускать по 4 виртуальные машины каждая с 2 гигабайтами (примерно), и не было бы замены хоста. Тем не менее, в каждой виртуальной машине я мог иметь файл подкачки объемом 2 ГБ, поэтому на виртуальном сервере было 4 ГБ используемой памяти, 2 физических и 2 виртуальных.
ИЛИ... Я мог бы дать каждой виртуальной машине 4 гигабайта "памяти" и заставить хост использовать 8 гигабайт реальной памяти и 8 гигабайт виртуальной памяти и не иметь файла подкачки в каждой виртуальной машине. Каждая виртуальная машина все еще будет иметь "4Gig", но подкачка будет происходить на хосте.
Неясная часть меня говорит о настройке подкачки страниц в каждом госте, как если бы вы были настоящим сервером, и у вас все хорошо. Но моя аналитическая сторона видит два главных преимущества в чрезмерной загрузке памяти хоста и отсутствии подкачки в виртуальной машине. Во-первых, ввод-вывод для виртуальной памяти затем обрабатывается хост-ОС, которая ближе к "голому железу", поэтому она должна быть быстрее. И, во-вторых, подкачка потребуется только в том случае, если на хосте не было доступной памяти. Если гость хочет 4Gig, но другие гости не используют их память, то никакой подкачки не потребуется.
Мысли?
3 ответа
Я не эксперт по виртуализации (на самом деле, я думаю, что в большинстве случаев это неправильный инструмент для работы), но из того, что я прочитал, нельзя не менять местами ваши гостевые ОС. Основная причина предотвращения перестановки заключается в том, что она позволяет ОС с одной догадкой захватывать большую часть пропускной способности ввода-вывода хоста.
Кроме того, вы не хотите притворяться, что ваши операционные системы предполагают, что у хоста больше физической памяти, чем у него, так как это приведет к сильной перестановке хоста, но отладка проблем производительности в операционных системах догадки будет очень сложной, поскольку с их точки зрения они не меняются местами, и ни один из инструментов уровня ОС в гостевой системе не покажет этого.
Это может быть даже с такими инструментами, как Xen и VmWare, вы не можете перезаписать память на хост-ОС из-за использования драйверов baloon-памяти.
Это будет сильно зависеть от последствий чрезмерного использования памяти на вашей хост-системе. Я был бы немного более чем раздражен, если бы, например, убийца нехватки памяти Linux убил мою виртуальную машину. Я стараюсь выделить для каждой гостевой ОС меньший, отдельный, предварительно выделенный, независимый от снимка виртуальный диск (если применимо к вашему решению для ВМ), убедиться, что файл, на котором размещен образ диска, не фрагментирован и / или на быстром диске, и настроить пространство подкачки гостя для размещения на этом виртуальном диске. Управление памятью гипервизора сегодня достаточно хорошо, чтобы не чувствовать разницу между перестановкой хоста OOM и перестановкой гостя OOM, и я могу настраивать поведение гостя независимо. Лучшее из обоих миров.
Собственный своп в ВМ - это лучшая изоляция ресурсов. Такая виртуальная машина не сможет перетащить хост со своими требованиями к оперативной памяти - она уже ограничена. А если вы установите своп на диски, отличные от системы виртуальной машины, вы можете даже использовать небезопасную политику кэширования.
Но "внешний" обмен - это, скорее, лучшее использование ресурсов.
Вот и все: изоляция против использования - ваш выбор.
Я бы не стал отдавать виртуальную память вашего гостя из-за проблем с вводом-выводом Также я бы не выделил виртуальной памяти вашего хоста и гостю слишком много физической памяти, поскольку гость на самом деле не осознавал, что использует виртуальную память, а не физическую память.
Что не оставляет вам никаких решений, кроме как приобрести больше памяти. Вы действительно не можете получить альтернативу для большего количества памяти. Это так дешево, если ваш сервер может поддерживать больше, я бы получил больше.