Pourquoi devons-nous définir un espace de swap deux fois plus grand que notre mémoire physique?


11

Lorsque nous voulons configurer un système Linux, il est courant de définir un espace de swap deux fois plus grand que votre mémoire physique. Je veux savoir pourquoi avons-nous besoin de cela, et comment se fait cette suggestion?

Réponses:


8

La réponse courte est "Vous n'êtes pas obligé ".

Selon le type de noyau / système, il peut être judicieux de dimensionner l'espace de swap comme ça, par exemple, dans la page de manuel tuning (7) de FreeBSD, nous trouvons la justification suivante derrière une taille de swap d'au moins 2x la taille de la mémoire physique:

Vous devez généralement dimensionner votre espace de swap à environ 2x mémoire principale pour les systèmes avec moins de 2 Go de RAM, ou environ 1x mémoire principale si vous en avez plus. Si vous n'avez pas beaucoup de RAM, cependant, vous voudrez généralement beaucoup plus de swap. Il n'est pas recommandé de configurer moins de 256 Mo de swap sur un système et vous devez garder à l'esprit l'expansion future de la mémoire lors du dimensionnement de la partition de swap. Les algorithmes de pagination VM du noyau sont optimisés pour fonctionner au mieux lorsqu'il y a au moins 2x swap par rapport à la mémoire principale. Configurer trop peu de swap peut entraîner des inefficacités dans le code de numérisation de page de la machine virtuelle ainsi que créer des problèmes plus tard si vous ajoutez plus de mémoire à votre machine. Enfin, sur les systèmes plus grands avec plusieurs disques SCSI (ou plusieurs disques IDE fonctionnant sur différents contrôleurs), nous vous recommandons fortement de configurer l'échange sur chaque lecteur. Les partitions de swap sur les disques doivent avoir approximativement la même taille. Le noyau peut gérer des tailles arbitraires mais les structures de données internes évoluent jusqu'à 4 fois la plus grande partition de swap. Garder les partitions de swap près de la même taille permettra au noyau de répartir de manière optimale l'espace de swap sur les N disques. Ne vous inquiétez pas d'en faire un peu trop, l'espace de swap est la grâce d'économie d'UNIX et même si vous n'utilisez normalement pas beaucoup de swap, cela peut vous donner plus de temps pour récupérer d'un programme galopant avant d'être forcé de redémarrer. Garder les partitions de swap près de la même taille permettra au noyau de répartir de manière optimale l'espace de swap sur les N disques. Ne vous inquiétez pas d'en faire un peu trop, l'espace de swap est la grâce d'économie d'UNIX et même si vous n'utilisez normalement pas beaucoup de swap, cela peut vous donner plus de temps pour récupérer d'un programme galopant avant d'être forcé de redémarrer. Garder les partitions de swap près de la même taille permettra au noyau de répartir de manière optimale l'espace de swap sur les N disques. Ne vous inquiétez pas d'en faire un peu trop, l'espace de swap est la grâce salvatrice d'UNIX et même si vous n'utilisez normalement pas beaucoup de swap, cela peut vous donner plus de temps pour récupérer d'un programme galopant avant d'être forcé de redémarrer.

D'autres facteurs peuvent être importants lorsque vous décidez de l'espace de swap à allouer, où l'allouer, etc. Par exemple, si vous installez un grand serveur avec 128 Go de mémoire physique, c'est probablement une bonne idée d'éviter de pré-allouer 256 Go d'espace disque pour le swap qui ne sera jamais utilisé.

D'un autre côté, avoir un espace de swap permet souvent de récupérer les vidages du noyau (par exemple dans Open-, Net- et FreeBSD). C'est donc une bonne idée d'avoir au moins suffisamment d'espace de swap pour récupérer un vidage complet du noyau en cas de panique.

Il n'y a pas de règle absolue qui convient à tous les cas. Vous devez lire sur le comportement de votre système spécifique, apprendre comment il fonctionne, réfléchir à l'utilisation prévue du système et décider de la meilleure taille d'espace de swap qui correspond à vos besoins.


5

Vous n'en avez pas du tout besoin. Les anciennes versions de Windows traitaient chaque page de mémoire allouée comme essentiellement un mmap sur le fichier d'échange, vous aviez donc besoin d'au moins la taille totale de votre RAM physique en échange pour qu'elle soit utile - ce n'est plus le cas aujourd'hui et n'a jamais été le cas sous Linux, mais la rumeur persiste.

Cependant, il y a un cas où il est souhaitable d'avoir au moins autant de swap que de RAM - l'hibernation. Étant donné que Linux utilise le fichier d'échange pour l'hibernation (aka, suspension sur disque), vous avez besoin de suffisamment d'échange pour conserver toutes les données dans la RAM, plus toutes les données qui ont déjà été échangées (moins la mémoire cache du cache). Ce n'est le cas que pour les machines qui ont besoin d'hiberner, comme les ordinateurs portables, bien sûr.

Enfin, avoir trop d'échanges peut être une mauvaise chose, malgré ce que les autres peuvent dire. Pensez - si vous avez 4 Go de RAM et que vous avez besoin de 8 Go supplémentaires de swap, pensez-vous que votre système sera toujours utilisable, qu'en est-il de tout le swapping vers / depuis le disque? Il est souvent préférable de supprimer immédiatement le processus de stockage de mémoire lorsque vous manquez de mémoire, plutôt que de ralentir le système entier à un niveau inutilisable lorsqu'il commence à passer tout son temps à rassembler et à échanger des données.


1

Il y a longtemps, il y avait une variante Unix commune (je pense que c'était un BSD, mais je ne trouve pas la référence pour le moment) qui allouerait chaque page de mémoire virtuelle dans l'espace de swap. Donc, si vous aviez autant de swap que de RAM, la taille de votre mémoire virtuelle serait toujours la même que votre RAM. La recommandation habituelle était alors d'avoir deux fois plus de swap que de RAM, ce qui rendait la mémoire virtuelle deux fois plus grande que la RAM.

Les unités modernes ne se comportent pas de cette façon, donc la raison de la règle est obsolète (je pense qu'elle était déjà obsolète en 1992, donc elle n'a jamais été pertinente pour Linux). Mais curieusement, la règle a survécu. Si vous le suivez maintenant, vous obtenez une mémoire virtuelle qui représente trois fois votre quantité de RAM, alors que l'intention initiale était d'en obtenir deux fois plus.

Ce n'est pas parce que la raison historique derrière la règle est erronée que c'est stupide. L'espace disque est devenu moins cher, il peut donc être judicieux d'allouer plus de swap. La quantité de swap que vous devriez avoir dépend beaucoup de la quantité de RAM dont vous disposez et de la façon dont vous l'utilisez. Vous pouvez exécuter un système sans échange, mais vous n'avez pas la possibilité de choisir les programmes à tuer si votre RAM se remplit et le système peut être plus lent (il est parfois préférable d'utiliser la RAM pour le cache et d'échanger de la mémoire de programme en dehors). Allouer trop de swap coûte une petite quantité de RAM (pour les structures de données du noyau) et bien sûr de l'espace disque (mais de nos jours c'est généralement très bon marché sauf sur SSD). Avoir suffisamment de swap pour s'adapter à toute votre mémoire virtuelle est nécessaire si vous souhaitez hiberner.


Windows le fait aussi: si le gestionnaire de mémoire a suffisamment d'espace de swap, il y conserve également une copie des pages qui sont en mémoire (à partir des pages les moins récemment modifiées, je suppose), donc s'il a besoin de les échanger, il peut le faire juste en jetant les pages loin de la mémoire.
pqnet

0

Une ancienne recommandation basée sur des hypothèses sur la capacité de mémoire système typique, la vitesse du bus mémoire par rapport à la vitesse du disque et le pourcentage de temps que les processus passent dans différents états d'attente. Je suis sceptique que ces jours-ci, vous souhaitiez plus de peut-être la moitié de la mémoire physique dans l'espace de swap - juste assez pour empêcher la destruction aléatoire du MOO lorsque vous utilisez presque la pleine mémoire. Mais cela dépend entièrement de votre charge de travail typique, YMMV, etc.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.