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