В настройке VMware ESX в чем разница между этими параметрами ?:
То есть в обоих случаях используется своп;
Так есть ли смысл предоставлять Linux VM раздел подкачки?
Игнорируя тот факт, что люди имеют дело с причинами, специфичными для ОС, у меня есть две причины, по которым не работать с разделом / файлом подкачки - плохая идея.
Да. Это способ Unix.
Unix (даже Linux) надеется чтобы иметь возможность поменять местами.
Плохие вещи происходит, когда система не может выполнить подкачку (либо потому, что она была неправильно сконфигурирована без раздела подкачки, либо из-за того, что пространство подкачки заполнено). В Linux одна из таких плохих вещей - это убийца нехватки памяти, который вонзит нож в заднюю часть программы, которая, по его мнению, использует больше всего оперативной памяти (серверы баз данных - любимая цель).
Что у тебя есть /proc/sys/vm/overcommit_memory установлен в? Из документации ядра:
0 - Heuristic overcommit handling. Obvious overcommits of
address space are refused. Used for a typical system. It
ensures a seriously wild allocation fails while allowing
overcommit to reduce swap usage. root is allowed to
allocate slightly more memory in this mode. This is the
default.
1 - Always overcommit. Appropriate for some scientific
applications.
2 - Don't overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable percentage (default is 50) of physical RAM.
Depending on the percentage you use, in most situations
this means a process will not be killed while accessing
pages but will receive errors on memory allocation as
appropriate.
Таким образом, если вы используете 1, разницы нет. Если вы используете 2 и нет файла подкачки linux, то ни один процесс не сможет выделить 512 МБ (виртуальной) памяти. Результат не ясен для 0.
Изменить: От http://utcc.utoronto.ca/~cks/space/blog/linux/LinuxVMOvercommit вот как работает 0:
Эвристическая избыточная фиксация пытается определить, сколько памяти система может предоставить вам, если она освободит всю память, которую могла, и ни один другой процесс не использовал бы больше оперативной памяти, чем в настоящее время; если вы просите больше, вам будет отказано. В частности, теоретическое количество «свободной памяти» рассчитывается путем сложения свободного пространства подкачки, свободной оперативной памяти (за вычетом 1/32, если вы не являетесь пользователем root) и всего пространства, используемого объединенным буферным кешем и данными ядра, которые помечены как восстанавливаемые. (без некоторых зарезервированных страниц).
Таким образом, он также использует своп в расчетах. В общем, я бы следовал рекомендациям RHEL:
M = Amount of RAM in GB, and S = Amount of swap in GB, then
If M < 2
S = M *2
Else
S = M + 2
Разделы подкачки могут быть потенциально быстрее, особенно в ситуациях, когда корневой диск почти заполнен, и вы не можете создать файл подкачки целиком без фрагментации, не говоря уже о накладных расходах, которые могут быть созданы файловой системой и, если применимо, такими вещами, как LVM.
Но производительность обеих машин в любом случае будет отстой, если вы сохраните на диске 33% требований к памяти.
См. Следующую ссылку - https://help.ubuntu.com/community/SwapFaq
По сути, если вам не нужен спящий режим или не используется больше памяти, чем вы выделяете для виртуальной машины, у раздела подкачки нет значительных преимуществ.
Я не использовал раздел / файл подкачки ни на одной из моих Linux-машин в течение многих лет.
Очевидным преимуществом подкачки является то, что когда ваша машина выходит из строя, вы все равно можете создать аварийный дамп. Поправьте меня, если я ошибаюсь, но, черт возьми, без свопа это невозможно. Конечно, это не относится к VMWare, а скорее применяется везде. Я чувствовал, что это может быть важно указать.