При настройке виртуальных машин на различных хост-системах, которые я использовал, будь то Hyper-V, VMware или KVM, я всегда выделял оперативную память в количествах, соответствующих конфигурациям физической памяти, например чтобы добавить 1 ГБ ОЗУ, я бы добавил 1024 МБ, для 6 ГБ ОЗУ я бы добавил 6 x 1024 = 6144 МБ.
Я понял, что никогда не задумывался о том, почему я это делаю, это был просто «То, как все делалось на предыдущем рабочем месте», которое я никогда не ставил под сомнение.
Итак, мой вопрос, помимо того факта, что это означает, что виртуализированные операционные системы могут аккуратно округлять выделенную оперативную память до ближайшего ГБ, есть ли какие-либо недостатки в выделении ОЗУ в количествах, которые не являются степенями двойки или кратными этому? например будет ли добавление 500 МБ ОЗУ, 750 МБ или 1001 МБ ОЗУ недостатком?
В качестве альтернативы, есть ли какие-либо преимущества, которые сделали бы этот способ работы рекомендуемым?
Я оставил вопрос открытым в отношении ОС хоста, так как мне было бы интересно узнать, существуют ли разные соображения для разных хостов.
Обратной стороны нет. Вы можете добавить то, что вам нужно в плане оперативной памяти. То же и для процессоров. Если вам нужно 3 виртуальных ЦП или 4 или 5, вы можете назначить по мере необходимости.
Некоторым администраторам нравится видеть кратные 512 и 1024, но на самом деле это не имеет значения.
Нет, преимуществ / недостатков нет. Системные администраторы, как правило, предпочитают круглый размер.
Я могу собрать очень маленькую систему Linux и дать ей 403 МБ оперативной памяти, система выделит то, что необходимо для ее работы. Но вы не найдете модулей оперативной памяти размером 403 МБ, потому что все работает со степенью 2. Так что просто округлите до того, что лучше всего подходит для вашей сборки.
Я использовал для виртуализации ОС Windows и Linux в своем единственном esxi и дал Ubuntu 768 МБ и Windows 3328 МБ, и это было хорошо для обоих, всего 4 ГБ. Если бы у меня было меньше барана, я бы просто его потерял.
Есть ли недостатки в распределении ОЗУ в количествах, не являющихся степенями двойки или кратными им?
Прежде всего. Помните, что каждое целое число кратно степени двойки. Итак, настоящий вопрос, который следует задать, заключается в том, следует ли вам ограничиваться определенными множителями или определенными степенями двойки.
Физические машины обычно имеют память, которая представляет собой небольшой множитель (1, 3 или 5) степени двойки. Но причины этого не относятся к виртуальным машинам.
Однако размеры страниц - это проблема, которая относится к виртуальным машинам. Существуют архитектуры, которые работают с двумя возможными размерами страниц. Распространенные 32-битные архитектуры поддерживают страницы размером ровно 4 КБ и 4 МБ. Обычные 64-битные архитектуры поддерживают страницы размером ровно 4 КБ и 2 МБ.
Если вы сохраните память, выделенную для виртуальной машины, всегда кратной 4 МБ, для базового кода будет более практичным использовать большие страницы для оптимизации производительности. По этим причинам я рекомендую стремиться к объему, кратному 4 МБ.
Я действительно ожидаю, что правильно спроектированное программное обеспечение округлит для вас размеры до кратных 4 МБ, если это будет более выгодно. Но если вы выберете для начала значение, кратное 4 МБ, вы будете меньше полагаться на программное обеспечение, которое правильно справляется с этими угловыми случаями.
Помимо этого, я предлагаю выделять виртуальным машинам оперативную память в количестве, которое является настолько точным, насколько вы можете предсказать их потребности. Если вы прогнозируете, что для оптимальной производительности виртуальной машине потребуется от 500 до 750 МБ, выделите 752 МБ. Я не вижу причин округлять это до 768 МБ или 1024 МБ.
В распределение памяти приятеля Метод, используемый некоторыми системами, предназначен для работы с степенями двойки. Однако этот метод с небольшими усилиями может быть адаптирован для работы с размерами, не равными степени двойки. Даже на физических машинах с размером памяти, кратным двум, по-прежнему вероятно, что часть физической памяти недоступна для партнера по распределению памяти. Таким образом, можно ожидать, что каждая ОС, использующая этот метод, будет обеспечивать работу памяти других размеров.