Pourquoi utiliser swap quand il y a plus que suffisamment d'espace libre dans la RAM?

Il est normal que les systèmes Linux utilisent un échange même s'il n'y a toujours pas de RAM. Le kernel Linux se déplacera pour échanger des pages de memory très rarement utilisées (par exemple, les instances getty lorsque vous utilisez uniquement X11 et un autre démon inactif).

L'utilisation de l'espace de swap devient un problème seulement quand il n'y a pas assez de RAM disponible, et le kernel est obligé de déplacer continuellement les pages de memory pour les échanger et revenir à la RAM, juste pour garder les applications en cours d'exécution. Dans ce cas, les applications de surveillance du système afficheraient beaucoup d'activité d'E / S de disque.

A titre de comparaison, mon système Ubuntu 10.04, avec deux users connectés avec des sessions X11 fonctionnant sur le bureau GNOME, utilise ~ 600 Mo de swap et environ 1 Go de RAM (sans countr les tampons et le cache fs). l'utilisation semble normale.

Ce comportement peut être configuré en définissant la valeur de:

 /proc/sys/vm/swappiness 

La valeur par défaut est 60. Si vous le définissez sur 0, vous n'utiliserez jamais le swap quand il y a encore de la RAM et que 100 est en train d'échanger la memory le plus vite possible.

Pour modifier temporairement la valeur (perdue lors du redémarrage):

 sudo sysctl vm.swappiness=10 

Pour modifier définitivement la valeur, éditez le file:

 /etc/sysctl.conf 

en tant que root (par exemple sudo nano /etc/sysctl.conf ) et changez ou ajoutez (sinon la ligne)

 vm.swappiness 

à la valeur désirée. Si ce file n'existe pas (par exemple dans Arch Linux), essayez plutôt /etc/sysctl.d/99-sysctl.conf .

Il y a eu un débat sur la question de savoir si l'échange avec la memory disponible est bon ou mauvais, mais l' aide d'Ubuntu recommand en effet une valeur de 10 pour les systèmes Desktop . Voir aussi ce tutoriel sur Digital Ocean pour CentOS .

Linux commence à permuter avant que la RAM ne soit remplie. Ceci est fait pour améliorer la performance et la réactivité:

• Les performances sont augmentées car parfois la memory vive est mieux utilisée pour le cache disque que pour stocker la memory du programme. Il est donc préférable d'échanger un programme inactif pendant un certain time et de conserver les files souvent utilisés dans le cache.

• La réactivité est améliorée en échangeant des pages lorsque le système est inactif, plutôt que lorsque la memory est pleine et qu'un programme est en cours d'exécution et demandant plus de RAM pour terminer une tâche.

L'échange ralentit le système, bien sûr, mais l'alternative à l'échange n'est pas d'échanger, d'avoir plus de RAM ou d'utiliser less de RAM.

Avoir plus de memory disponible

Comme tout le monde l'a dit, oui, swap vous aidera à vous débarrasser de la memory inutilisée, ce qui vous aidera à avoir plus de memory disponible.

Hibernation

Mais swap peut également être utilisé pour l' hibernation, ce qui peut être très utile lorsque vous avez un ordinateur portable ou que vous voulez économiser de l'énergie et mettre votre ordinateur en veille prolongée avant de quitter le travail. Vous pouvez donc commencer plus rapidement le lendemain matin.

Avoir une fonction d'hibernation est l'une des principales raisons pour lesquelles nous voyons encore aujourd'hui avoir au less la taille de RAM pour le swap. De cette façon, le système peut mettre toutes les RAM utilisées dans le swap et passe en hibernation.

Short-venues

Veillez à ce que datatables de process puissent être lues dans le swap même après l'arrêt, sauf si le swap a été crypté (bien sûr).

L'utilisation de l'échange crypté avec la mise en veille prolongée ne fonctionne pas immédiatement avec toutes les dissortingbutions. Vous devez utiliser une key de chiffrement constante (certains parameters génèrent randomment la key de chiffrement d'espace de swap à chaque démarrage) et initrd / initramfs pour activer le volume chiffré avant de reprendre.

C'est un vieux post, cependant, je prendrais toujours la liberté de mettre en place mes pensées ici.

En commençant par le bas, Linux splitait d'abord la memory en pages (généralement 4K par page sur le système x86_64). Par la suite, la memory virtuelle est créée, dont le mappage est effectué avec la memory physique en utilisant MMU (Memory Management Unit).

Les process sont alloués de la memory de la zone de memory virtuelle, donc s'il vous plaît noter, quand vous voyez / proc / meminfo, vous verrez VMalloc * comme les détails de la memory virtuelle.

Disons que vous avez un process qui request de la memory (disons 300 Mo – un browser Web). Le process serait alloué 300 Mo à partir de la memory virtuelle, mais il n'est pas nécessaire que ce soit mappé memory (qui est mappé à la memory physique). Il y a un concept de «Copy on Write» pour la memory management, c'est-à-dire que si vos process utilisent réellement la memory allouée depuis la memory virtuelle (c'est-à-dire que certains écrivent sur la memory), ils sont mappés à la memory physique. Cela aide le kernel à fonctionner correctement dans un environnement multi-process efficace.

Qu'est-ce que le cache?

Une grande partie de la memory utilisée par les process est partagée. Disons que la bibliothèque glibc est utilisée par presque tous les process. Quel est l'intérêt de conserver plusieurs copys de la glibc dans la memory, lorsque chaque process peut accéder à la même memory et faire le travail. Ces ressources fréquemment utilisées sont conservées dans le cache de sorte que lorsque les process sont à la request, ils peuvent être référencés dans le même location memory. Cela aide à accélérer les process, car la lecture de la glibc (etc.) À partir du disque prendrait beaucoup de time.

Ce qui précède était pour les bibliothèques partagées par dire, similaire est également vrai pour la lecture de files ainsi. Si vous lisez un gros file (disons 100-200 Mo) pour la première fois, cela prendrait beaucoup de time. Cependant, lorsque vous essayez de refaire la même lecture, ce serait plus rapide. Les données ont été mises en memory cache, et la relecture n'a pas été effectuée pour tous les blocs.

Qu'est-ce que le tampon?

En ce qui concerne le tampon, lorsqu'un process effectue des E / S de files, il s'appuie sur le tampon du kernel pour écrire des données sur le disque. Les process, request au kernel de faire le travail. Ainsi, au nom du process, le kernel écrit datatables dans son "buffer", et indique au process que l'écriture est faite. De manière asynchronous, le kernel continuera à synchroniser ces données dans le tampon sur le disque. De cette façon, les process s'appuient sur le kernel pour choisir le bon moment pour synchroniser datatables sur le disque, et les process pourraient continuer à avancer. Rappelez-vous, ce sont les E / S générales que les process normaux font. Cependant, les process spécialisés, qui doivent confirmer que les E / S sont effectivement effectuées sur le disque, peuvent utiliser d'autres mécanismes pour faire des E / S sur le disque. Certains utilitaires opensource sont libaio. Il existe également des moyens d'appeler la synchronisation explicite des FD ouvertes dans le context de vos process, de sorte que vous forcez le kernel à synchroniser datatables sur le disque pour l'écriture que vous avez fait.

Quels sont les défauts de page alors?

Prenons un exemple, lorsque vous démarrez un process (par exemple un browser Web), dont le binary est d'environ 300 Mo. Cependant, la totalité du 300 Mo du browser Web ne fonctionne pas instantanément. Le process continue de passer des fonctions aux fonctions dans son code. Comme dit précédemment, la memory virtuelle serait consommée 300 Mo mais pas tous la memory est mappée à la memory physique (la memory résidente RSS serait less, voir la sortie supérieure). Lorsque l'exécution du code atteint un point pour lequel la memory n'est pas réellement mappée physiquement, une erreur de page serait un problème. Le kernel mettrait cette memory en memory physique, associez la page memory à votre process. Un tel défaut de page est appelé "Défauts mineurs de page". De la même manière, lorsqu'un process est en cours, les erreurs d'une page principale d'E / S sont augmentées.

Quand et pourquoi Swap Out se produit?

Situation 1:

En ligne avec les détails ci-dessus, considérons un scénario où la bonne quantité de memory devient memory mappée. Et maintenant, un process démarre, ce qui nécessite de la memory. Comme discuté ci-dessus, le kernel aura fait un mappage de memory. Cependant, il n'y a pas assez de RAM physique disponible pour mapper la memory. Maintenant, le kernel se penchera d'abord sur le cache, il aura quelques vieilles pages de memory qui ne sont pas utilisées. Il va vider ces pages sur une partition séparée (appelée SWAP), libérer des pages et mapper les pages libérées à la nouvelle requête à venir. Comme l'écriture du disque est beaucoup plus lente que la RAM à semi-conducteurs, ce process prend beaucoup de time, et donc un ralentissement est vu.

Situation 2:

Disons que vous voyez beaucoup de memory disponible dans le système. Même alors, vous voyez qu'il y a beaucoup de swap-out qui se passe. Il pourrait y avoir un problème probable de fragmentation de la memory. Considérons un process, qui exige 50 Mo de memory contiguë du kernel. (garder à l'esprit contigu). De toute évidence, le kernel aurait alloué des pages de manière random à différents process, et en a libéré certains. Cependant, lorsque nous exigeons de la memory contiguë, il faudra searchr un fragment qui satisfait les process demandés. S'il n'est pas en mesure d'get une telle memory, il devra faire un échange de certaines pages de la memory et ensuite allouer des pages contiguës. Même dans de tels cas SWAP out arriverait. A partir de Kernel ver 2.6 et plus, de tels problèmes de fragmentation ont considérablement diminué. Cependant, si le système fonctionne pendant longtime, de tels problèmes pourraient encore survenir.

Voir cet exemple ( sortie vmstat )

 2016-10-29 03:55:32 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ 2016-10-29 03:55:32 rb swpd free buff cache si so bi bo in cs us sy id wa st 2016-10-30 03:56:04 19 23 2914752 4692144 3344908 12162628 1660 1 8803 12701 4336 37487 14 7 40 38 0 2016-10-30 03:56:34 3 20 2889296 4977580 3345316 12026752 2109 2 8445 14665 4656 36294 12 7 46 34 0 2016-10-30 03:57:04 1 11 3418868 4939716 3347804 11536356 586 4744 2547 9535 3086 24450 6 3 59 33 0 <<<----- 2016-10-30 03:57:34 3 19 3456252 5449884 3348400 11489728 3291 13371 6407 17957 2997 22556 6 4 66 24 0 2016-10-30 03:58:04 7 6 4194500 5663580 3349552 10857424 2407 12240 3824 14560 2295 18237 4 2 65 29 0 2016-10-30 03:58:34 2 16 4203036 5986864 3348908 10838492 4601 16639 7219 18808 2575 21563 6 4 60 31 0 2016-10-30 03:59:04 3 14 4205652 6059196 3348760 10821448 6624 1597 9431 4357 1750 20471 6 2 60 31 0 2016-10-30 03:59:34 2 24 4206968 6053160 3348876 10777216 5221 2067 10106 7377 1731 19161 3 3 62 32 0 2016-10-30 04:00:04 0 13 4205172 6005084 3348932 10785896 6236 1609 10330 6264 1739 20348 4 2 67 26 0 2016-10-30 04:00:34 4 11 4206420 5996396 3348976 10770220 6554 1253 10382 4896 1964 42981 10 5 58 27 0 2016-10-30 04:01:04 6 4 4177176 5878852 3348988 10825840 8682 765 10126 2716 1731 32949 8 4 69 19 0 

@ 2016-10-30 03:57:04, nous voyons qu'il y a encore une bonne quantité de RAM disponible. Cependant, même alors, le swap est arrivé. Nous avons vérifié l'arborescence des process à ce stade et nous n'avons vu aucun process qui exigerait une telle quantité de memory (plus que de la memory libre). La suspicion évidente était la situation 2 décrite ci-dessus. Nous avons vérifié les journaux buddyinfo et zoneinfo ci-dessus (Utilisez echo m> / proc / sysrq-sortinggger pour les vérifier, la sortie va dans syslogs).

Pour un système normal de nôtre, la comparaison des infos de zone va ceci. Et les graphes pour le cache / free / low mem sont également mentionnés ci-dessous

En regardant les informations, il est clair qu'il y a fragmentation de la memory dans le nœud 0 et le nœud 1 normal (Nœud c'est la machine NUMA, donc plusieurs nœuds) (voir numactl pour vérifier les informations de votre système).

La fragmentation de la memory est également une raison pour laquelle l'utilisation du swap peut augmenter même lorsque la memory libre est présente.

De la FAQ Swap d'Ubuntu que Marcel a liée à

Comme minimum de base, il est fortement recommandé que l'espace de swap soit égal à la quantité de memory physique (RAM). De plus, il est recommandé que l'espace de swap soit deux fois la quantité de memory physique (RAM) en fonction de la quantité de disque dur

Je pense que vous devriez augmenter votre espace de swap dans votre système. Le swap accélère l'allocation de la memory RAM en permettant de rejeter datatables déjà paginées.

Beaucoup de programmes modernes sont construits sur des frameworks gonflés qui traînent dans beaucoup d'ordure dont vous n'avez pas réellement besoin pour exécuter le programme. L'échange de ces pages inutilisées libère de la RAM pour le cache et les programmes qui peuvent réellement utiliser la RAM.

Je parle d'expérience personnelle douloureuse ici.

L'année dernière, je suis passé d'un de mes sites web à un nouveau framework de server web prometteur, construit sur Firefox. Cela peut sembler étrange de build un système côté server sur un programme centré sur le client comme Firefox, mais il a eu d'énormes avantages. Firefox est très puissant, offre des services internes vraiment printingnants et réduit l'inadéquation d'impédance entre le server et le client pour que les deux utilisent des plates-forms similaires.

Mais il y a un inconvénient: Firefox est grand. Vraiment gros. Il s'agissait d'une sorte de projet de la version 1.x, donc ils n'avaient pas eu l'idée de supprimer le support de l'interface graphique. [*] Mon site n'en avait pas besoin, mais parce que la technologie VPS, t permettre l'espace d'échange, ce code GUI et toutes les autres parties de Firefox, je n'ai pas utilisé la RAM réelle. J'ai fini par avoir besoin de 512 Mo de RAM minimum juste pour exécuter le site sans qu'il se plante à cause de l'épuisement de la memory. Si mon VPS avait un peu d'espace de swap, j'aurais probablement pu m'en sortir avec un plan de 256 Mo.

[*] Le retrait du code GUI du framework n'a peut-être même pas été souhaitable car l'un des avantages de cette plateforme était le grattage web haute fidélité car le framework côté server pouvait download des pages web depuis un autre site et les manipuler tout comme vous le feriez du côté client. Pensez mashups. Une grande partie de ce genre de choses se briserait si vous ne pouvez pas «rendre» la page Web dans un context graphique.

En passant, ce framework web est essentiellement mort maintenant, donc il n'y a pas de nom de nom-et-honte. Le mieux est de prendre la leçon plus large à cœur: oui, l'échange est toujours utile même si vous avez des concerts de RAM libre.

Je pense que Gilles a déjà mentionné le fait que, même si vous disposez d'assez de memory RAM, le swap peut être utile pendant certaines «imperfections», tout en sauvegardant certaines données même après des fermetures. puisque la memory vive est épuisée après les redémarrages), j'ai 12 Go de RAM disponibles sur mon système, et moi aussi, j'ai réfléchi à cette question auparavant. À un moment donné, lorsque j'avais désactivé tous les swap et que je ne comptais que sur ma RAM, j'ai eu des expériences douloureusement difficiles à essayer de déboguer une erreur système, un plantage, etc. après l'arrêt du système. Depuis, j'ai réactivé la partition swap.