Должны ли виртуальные машины Linux в VMware / ESX иметь раздел подкачки?

На установке VMware ESX, в чем отличие этих опций ?:

• виртуальная машина Linux с 1 ГБ ОЗУ и разделом подкачки 1 ГБ, а виртуальная машина использует оперативную память 1,5 ГБ
• виртуальная машина Linux с 1 ГБ ОЗУ и без раздела подкачки, а виртуальная машина использует оперативную память 1,5 ГБ

Я имею в виду, что в обоих случаях используется своп;

• в первом свопе делается раздел своп linux
• во втором случае VMware поменяет 512 МБ в пул хранения VMware.

Так есть ли смысл отдавать раздел подкачки виртуальной машине Linux?

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

1. Если у вас есть 1,5 ГБ оперативной памяти, выделенной для виртуальной машины без пространства файла / раздела, и она хочет использовать 1,5 ГБ + 1 МБ, она сообщит об ошибке нехватки памяти. С пространством подкачки он сможет поменять данные из активной памяти на диск.
2. Гостевая ОС намного лучше справляется с управлением памятью, чем хост. Вот почему существует такая технология, как раздувание памяти, потому что Хост может сделать обоснованные предположения о том, какая память сейчас не нужна, но гость знает на гораздо более интеллектуальном уровне (это предотвращает выгрузку памяти ОС, что может снизить производительность).

Да. Это способ 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:

Эвристический overcommit пытается определить, сколько памяти может дать система, если она освободит всю память, и ни один другой процесс не использует больше оперативной памяти, чем в настоящее время; Если вы просите больше, вам будет отказано в вашем распределении. В частности, теоретическое число «свободной памяти» рассчитывается путем сложения свободного пространства подкачки, свободной оперативной памяти (меньше 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, а применимо везде. Я чувствовал, что это может быть важно отметить.