Les machines virtuelles Linux dans VMware / ESX doivent-elles avoir une partition de swap?

Sur une configuration VMware ESX, quelle est la différence de ces options?:

• une machine virtuelle Linux avec 1 Go de RAM et 1 Go de partition d'échange et la machine virtuelle utilise 1,5 Go de RAM
• une machine virtuelle Linux avec 1 Go de RAM et aucune partition de swap et la machine virtuelle utilise 1,5 Go de RAM

Je veux dire, dans les deux cas, le swap est utilisé;

• dans le premier swap se fait sur la partition swap linux
• dans le second cas, VMware échangera 512 Mo vers le pool de stockage VMware.

Est-il donc utile de donner une partition d'échange aux machines virtuelles Linux?

Ignorant le fait que les gens ont affaire à des raisons spécifiques au système d'exploitation, j'ai deux raisons pour lesquelles c'est une mauvaise idée de ne pas fonctionner avec une partition / un fichier d'échange.

1. Si vous disposez de 1,5 Go de RAM alloué à une machine virtuelle sans fichier / partition d'espace et qu'elle souhaite utiliser 1,5 Go + 1 Mo, elle signalera une erreur de mémoire insuffisante. Avec l'espace de swap, il sera en mesure d'échanger des données de la mémoire active et sur le disque.
2. Le système d'exploitation invité fait un bien meilleur travail de gestion de la mémoire que l'hôte. C'est pourquoi une technologie comme le gonflement de la mémoire existe parce que l'hôte peut faire des suppositions éclairées sur la mémoire qui n'est pas nécessaire pour le moment, mais l'invité le sait à un niveau beaucoup plus intelligent (cela empêche la mémoire du système d'exploitation d'être échangée, ce qui pourrait tuer vos performances).

Oui. C'est la voie Unix.

Unix (même Linux) s'attend à pouvoir échanger.
De mauvaises choses se produisent lorsque le système ne peut pas échanger (soit parce qu'il a été mal configuré sans partition de swap, soit parce que l'espace de swap est plein). Sous Linux, l'une de ces mauvaises choses est le tueur de mémoire, qui plongera un couteau à l'arrière du programme qui, selon lui, utilise le plus de RAM (les serveurs de base de données sont une cible préférée).

À quoi vous êtes-vous /proc/sys/vm/overcommit_memoryfixé? De la documentation du noyau:

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.

Ainsi, si vous utilisez 1, il n'y a pas de différence. Si vous utilisez 2 et aucun fichier d'échange Linux, aucun processus ne pourra allouer 512 Mo de mémoire (virtuelle). Le résultat n'est pas clair pour 0.

Modifier: à partir de http://utcc.utoronto.ca/~cks/space/blog/linux/LinuxVMOvercommit, voici comment fonctionne 0:

Le sur-engagement heuristique tente de déterminer la quantité de mémoire que le système pourrait vous donner s'il récupérait toute la mémoire qu'il pouvait et qu'aucun autre processus n'utilisait plus de RAM qu'il ne l'est actuellement; si vous demandez plus que cela, votre allocation est refusée. En particulier, le nombre théorique de «mémoire libre» est calculé en ajoutant de l'espace de swap gratuit, de la RAM libre (moins 1 / 32e si vous n'êtes pas root) et tout l'espace utilisé par le cache de tampon unifié et les données de noyau étiquetées comme récupérables. (moins quelques pages réservées).

Il utilise donc également l'échange dans le calcul. En général, je suivrais la recommandation RHEL de:

M = Amount of RAM in GB, and S = Amount of swap in GB, then
If M < 2
    S = M *2
Else
    S = M + 2

Les partitions de swap peuvent être potentiellement plus rapides, en particulier dans les situations où le disque racine est presque plein et vous ne pouvez pas créer un fichier de swap en une seule pièce sans fragmentation, sans parler de la surcharge qui pourrait être créée par le système de fichiers et, le cas échéant, des choses comme LVM.

Mais les performances des deux machines seront de toute façon nul si vous gardez 33% de vos besoins en mémoire sur le disque.

Veuillez consulter le lien suivant: https://help.ubuntu.com/community/SwapFaq

Fondamentalement, à moins que vous n'ayez besoin d'hiberner ou d'utiliser plus de mémoire que vous n'en allouez à la machine virtuelle, il n'y a aucun avantage significatif à une partition de swap.

Je n'ai pas utilisé de partition / fichier d'échange sur aucune de mes machines Linux depuis des années.

L'avantage évident pour l'échange est que lorsque votre machine tombe en panne, vous pouvez toujours créer un vidage sur incident. Corrigez-moi si je me trompe, mais afaik ce n'est pas possible sans échange. Ce n'est pas spécifique à VMWare bien sûr, mais s'applique plutôt n'importe où. J'ai pensé qu'il pourrait être important de le souligner.