Licence CC BY-NC

Linux : gardez votre swap !

Faut-il activer le swap malgré la RAM à foison ?

La nuit dernière, pendant une insomnie je suis tombé sur cet article intéressant. L’auteur, contributeur du noyau Linux, prend la défense de la mémoire swap qui est pourtant si décriée, d’après lui.

Cela me semblait curieux. Selon ma conception de l’espace swap, il s’agissait d’une RAM de secours à utiliser en cas de saturation imminente. Partant de là, je pensais de façon raisonnable que l’espace swap était donc en option pourvu que l’on ait bien assez de RAM pour ses besoins. Je me demandais d’ailleurs bien pourquoi certains de mes serveurs utilisaient de l’espace swap malgré toute la RAM disponible.

Ma conception était erronée. L’espace swap n’a pas ce rôle de roue de secours dans un système Linux. Du moins pas directement.
Il s’agit, comme son nom l’indique, d’un espace d’échange qui permet au noyau de mieux prioriser les ressources mémoire et ainsi maximiser les opportunités d’optimisation. Cela devant, en principe, améliorer la réactivité globale du système.

Au fur et à mesure que de la RAM est concédée, tantôt pour du cache de fichiers, tantôt pour de l’allocation applicative (via malloc ou mmap), le noyau Linux essaie de ranger les pages peu demandées dans l’espace swap. Cela laisse ainsi place aux pages qui sont les plus utiles sur le moment ou les pages d’un futur proche. Par exemple, il sera préférable que la RAM laisse place au cache de fichiers en cours d’utilisation plutôt qu’à la vieille heap d’un programme qui ne l’utilise plus (ou qu’il a oublié de libérer…).

Quand la mémoire commence à s’encombrer sans espace swap de disponible, il est possible de détruire les pages de cache fichier (sous certaines conditions) pour libérer de la RAM. Cela n’entraîne aucune perte de données. En revanche, nous comprendrons sans mal pourquoi la même stratégie ne pourrait s’appliquer aux pages mémoire des programmes en cours d’exécution. Ces pages-là devront ainsi perdurer en RAM, quand même elles ne serviraient pas à grand chose. Cela représente un potentiel manque à gagner : le noyau aurait pu faire meilleur usage de cette mémoire, en y cachant des fichiers en cours d’utilisation intensive, par exemple.



Sachant tout cela, je peux aisément percevoir comment le manque de swap peut s’avérer délétère pour le serveur qui tourne 7j/7 et 24h/24 sur le long terme. Je reste néanmoins plus nuancé en ce qui concerne les ordinateurs personnels ou stations de travail qu’on rallume tous les matins.

De mon expérience personnelle sur ma machine de bureau (32 GB de RAM + 4 GB de swap, vm.swappiness = 60), les nouvelles pages n’ont pas le temps de s’accumuler assez pendant les quelques heures d’utilisation. L’espace swap n’est donc presque jamais utilisé, sauf pour certaines occasions de lancer une VM : le noyau décide alors de mettre quelques gigas-octets entiers de cache fichiers, sûrement le disque virtuel de la VM.

Sur l’un de mes serveurs, en revanche, l’espace swap est bien utilisé constamment malgré l’abondance de RAM. L’espace swap est en ce moment utilisé à hauteur de 3 GB sur 12 GB, et ce conjointement avec les 40 GB d’utilisés sur 64 GB au total (en comptant le cache). Linux laisse ainsi ~20 GB de libre immédiatement pour accueillir des pages jugées plus importantes que celles qui, manifestement, ne méritent que de croupir en swap pour le moment.

En résumé : j’avais tort de considérer l’espace swap comme une bête extension de secours de la mémoire physique. ^^

18 commentaires

Le swap sert aussi pour l’hibernation, non ? Je crois. Si c’est le cas vaut mieux ne pas se débarrasser du swap alors…(sur un PC perso)

Tinei

En effet, il y a deux mode de mise en veille Suspend et Hibernate.

Le suspend stop le pc mais en laissant le contenu dans la RAM. De ce fait une petite partie d’électricité est consommé dans le but de maintenir les informations dans la RAM. Le redémarrage de l’ordinateur est néanmoins bien plus rapide car il récupère les données de la RAM.

Le hibernate prends toute les informations de la RAM et les met dans le partition swap du disque dur. Cela à pour avantage de ne pas consommer d’électricité mais cause un arrêt et un redémarrage plus lent (du aux accès disque).
Cependant, pour être en capacité de mettre le contenus de la RAM dans la partition swap il faut avoir au moins autant de swap de que RAM.

+0 -0

Intéressant, je n’avais jamais entendu parler de cette utilisation. Ça semble logique une fois abordé. Par contre, ta machine de bureau avec 32GB de RAM n’est peut être pas un bon exemple pour parler d’utilisation RAM ; la norme est partagée entre 8GB et 16GB je dirais.

Je n’ai pas fait de recherche mais je me permets de poser la question : Windows gère cela de la même manière ? Je ne vois pas d’information à propos d’une utilisation de swap dans l’onglet performance du gestionnaire de tâches.

Intéressant, je n’avais jamais entendu parler de cette utilisation. Ça semble logique une fois abordé. Par contre, ta machine de bureau avec 32GB de RAM n’est peut être pas un bon exemple pour parler d’utilisation RAM ; la norme est partagée entre 8GB et 16GB je dirais.

Je n’ai pas fait de recherche mais je me permets de poser la question : Windows gère cela de la même manière ? Je ne vois pas d’information à propos d’une utilisation de swap dans l’onglet performance du gestionnaire de tâches.

tleb

Clairement, 32 GB c’est pas la norme d’une machine de bureau, en effet. Je ne sais pas comment fonctionne Windows, mais je me demande si ce comportement n’est pas finalement assez standard parmi tous les OS. Ça ne m’étonnerait pas que Windows fonctionne sur le même principe, ainsi que macOS et même d’autres systèmes.

+0 -0

Pour moi la swap (pour ma machine perso) pose deux problèmes;

  1. C’est un truc de plus à gérer quand il faut partitionner son disque, que je ne sais jamais dimensionner.
  2. Quand mon PC se met à swapper, elle devient si peu réactive que ça peut être très gênant à l’usage (gros coup de freeze d’une minute). (En théorie les schedulers devraient éviter les pertes en réactivité, mais en pratique j’ai toujours observé ces freezes de temps en temps.) Finalement je préfère que le noyau lance un OOM-killer qui va me tuer un processus gourmand, et que la machine reste réactive.

Depuis un an environ j’ai arrếté d’avoir de l’espace swap, et à la place j’utilise zram, qui compresse à la volée une partie de ma RAM pour s’en servir comme swap au besoin. La quantité de RAM dédiée est décidée dynamiquement (donc pas de (1)), et le coût en performances de la compression au vol est nettement plus faible que d’aller taper dans le disque, même avec un SSD — surtout quand tous les coeurs de la machine ne sont pas utilisés.

+3 -0

Je ne l’ai pas précisé dans le billet, mais mes 4 GB de swap sont en zram. J’apprécie particulièrement cette méthode pour éviter les I/O et j’ai souvent un core disponible pour traiter la compression et la décompression à la volée.

Ça me paraissait curieux au premier abord d’avoir du swap dans la RAM. Mais en fait, quand on arrête de considérer le swap comme un espace en plus de la RAM mais pour ce qu’il est vraiment, il n’y a finalement rien de choquant à faire du swap dans la RAM physique.

Enfin je précise concernant ton premier point qu’il y a une méthode plus dynamique pour gérer du swap sur disque. Au lieu de créer une partition pour ça, tu peux utiliser un fichier qui pèse le poids de l’espace swap voulu. Si tu veux changer la taille un jour, tu fais un nouveau fichier de la taille voulue et swappes dessus. Si je ne dis pas de bêtise, Ubuntu est passé à ce mode par défaut sur les nouvelles installations.

+0 -0

Depuis un an environ j’ai arrếté d’avoir de l’espace swap, et à la place j’utilise zram, qui compresse à la volée une partie de ma RAM pour s’en servir comme swap au besoin. La quantité de RAM dédiée est décidée dynamiquement (donc pas de (1)), et le coût en performances de la compression au vol est nettement plus faible que d’aller taper dans le disque, même avec un SSD — surtout quand tous les coeurs de la machine ne sont pas utilisés.

Techniquement,la zram c’est de la swap mais exploitée autrement. D’ailleurs pour les commandes du système liées à la swap, la zram se comporte comme ta partition swap pour eux cela ne fait aucune différence.

Notons que Fedora propose par défaut de la zram en guise de swap. Et je pense que c’est une bonne idée. Entre autre à cause du problème que tu évoques : le système sera trop lent pendant trop longtemps donc inutilisable.

Sachant tout cela, je peux aisément percevoir comment le manque de swap peut s’avérer délétère pour le serveur qui tourne 7j/7 et 24h/24 sur le long terme. Je reste néanmoins plus nuancé en ce qui concerne les ordinateurs personnels ou stations de travail qu’on rallume tous les matins.

En l’occurrence cela m’est bien utile. J’ai un portable avec 8 Gio de RAM pour travailler. Mon usage classique de la machine varie entre 4 et 6 Gio, tendue mais ça passe.

Sauf que pour certaines compilations, je peux avoir besoin de quelques Giga supplémentaires pour l’édition de lien ou les gros fichiers. Ici la swap prend tout son sens, elle me permet de m’affranchir de ma limite des 8 Gio temporairement avant que le rythme de croisière prenne le relais. Avec la swap désactivée, les programmes étaient tuées aléatoirement par OOM Killer ce qui est plutôt chiant.

Après bien sûr cette situation n’est pas non plus la plus commune.

+1 -0

Pour ceux qui posent la question, quelques indices assez évidents laissent supposer que windows fonctionne sur les mêmes principes.

  • On a deux modes de mise en veille: la veille et la veille prolongée, à mettre en parralèle avec les modes suspend et hibernate déjà décrits dans les commentaires
  • La veille simple consomme bel et bien de l’électricité. IL m’est déjà arrivé d’oublier un PC portable en veille simple. Après 48 à 72h soit la batterie est totalement vidée, soit windows le détecte à temps et le PC se réveille brièvement pour passer en veille prolongée s’il est configuré pour le faire.
  • La veille prolongée ne consomme effectivement pas d’électricité. J’ai déjà laissé dormir un vieux PC portable plus d’un mois en veille prolongée, et il s’est réveillé correctement.
  • Le fichier C:\hiberfil.sys ne laisse pas beaucoup de doutes à ce sujet, à commencer par son nom. De ce que j’en ai déjà observé, sa taille est d’environ 75% de la RAM disponible, et il est rouvert au moins à chaque reboot, à en témoigner par sa date de modification.
  • IL est parfois suspecté depuis windows 10 que même démarrer>arrêter n’arrête en fait pas réellement le PC totalement mais passe sous une forme de veille prolongée, pour permettre un rallumage plus rapide. C’est difficile à vérifier…

Sinon par rapport au swap sur un serveur linux, il y a un peu moins d’une dizaine d’années, un administrateur système m’avait conseillé de choisir la taille du swap à au moins 1,5 fois la RAM. Je ne sais pas si c’est un bon conseil et si c’est toujours d’actualité.

+1 -0

Sinon par rapport au swap sur un serveur linux, il y a un peu moins d’une dizaine d’années, un administrateur système m’avait conseillé de choisir la taille du swap à au moins 1,5 fois la RAM. Je ne sais pas si c’est un bon conseil et si c’est toujours d’actualité.

Aujourd’hui les serveurs ont parfois tellement de RAM qu’appliquer ce conseil reviendrait à utiliser potentiellement un disque entier !

Sinon, je ne pense pas qu’il existe une règle universelle. C’est comme le nombre de workers égal à deux fois le nombre de cœurs : ça marche peut-être, mais il faut tester et regarder avec son workload attendu.

Les serveurs sont souvent prévus pour ne faire qu’une seule chose et ça peut nous aider pas mal à estimer correctement les besoins.

Au pire, si l’on est pas sûr, on peut utiliser du swap sur un fichier plutôt que sur une partition pour pouvoir changer facilement la taille par la suite. C’est ce que je fais sur certains de mes serveurs.

Il faut aussi potentiellement re-régler le paramètre Linux qui détermine à quel point le système sera prompt à envoyer des pages en swap. Par défaut c’est à 60, mais je doute que cela convienne à certains workload.

+0 -0
  • la règle du 1.5 fois la RAM a plus de 15 ans et n’a plus lieu d’être, sous Linux comme sous Windows.
  • Windows a un fichier différent pour le swap (pagefile.sys qui peut être défini sur n’importe quel lecteur) et pour l’hibernation (hiberfile.sys obligatoirementm sur C:)
  • l’arrêt de Windows 10 est en fait un redémarrage-hibernation. D’ailleurs en cas de dual Boot, se on arrete Windows puis démarre Linux (pas de redémarrage avec la commande dédiée) les disques NTFS sont en lecture seule sous Linux à cause de ça, ils sont considérés comme en cours d’utilisation par Windows
  • Sur une VM il vaut mieux généralement bidouiller la sawpinmess pour utiliser le swap le plus rarement possible
  • Les SSD sont assez endurants pour qu’on laisse la Swap dessus

Le guide d’installation de Archlinux est pas hyper compliqué sur la gestion de la RAM. Personnellement, j’ai une partition SWAP mais je ne sais même plus combien elle fait :| Et j’ai réglé la swapinness pour diminuer l’usage du swap, pour moins user le SSD et avoir un système un peu plus réactif.

+0 -0

Sinon par rapport au swap sur un serveur linux, il y a un peu moins d’une dizaine d’années, un administrateur système m’avait conseillé de choisir la taille du swap à au moins 1,5 fois la RAM. Je ne sais pas si c’est un bon conseil et si c’est toujours d’actualité.

Aujourd’hui les serveurs ont parfois tellement de RAM qu’appliquer ce conseil reviendrait à utiliser potentiellement un disque entier !

Sinon, je ne pense pas qu’il existe une règle universelle. C’est comme le nombre de workers égal à deux fois le nombre de cœurs : ça marche peut-être, mais il faut tester et regarder avec son workload attendu.

Les serveurs sont souvent prévus pour ne faire qu’une seule chose et ça peut nous aider pas mal à estimer correctement les besoins.

Au pire, si l’on est pas sûr, on peut utiliser du swap sur un fichier plutôt que sur une partition pour pouvoir changer facilement la taille par la suite. C’est ce que je fais sur certains de mes serveurs.

sgble

Pour la taille du swap il n’y a pas de règle universelle.

La seule qui fait sens c’est que si tu veux hiberner, avoir un swap qui fait la taille de la RAM peut être nécessaire bien que avec moins cela reste possible, tant que la machine en consomme moins avant d’aller en hibernation.

Après c’est à estimer en fonction du besoin : est-ce qu’on consomme souvent beaucoup de mémoire par rapport à celle disponible ? Cette consommation de RAM est-elle stable dans le temps ou soumise à de gros pics temporaires ? Si oui, évaluer ces pics de consommation mémoire.

Et la question est si on manque de RAM, la machine sera plus lente voire certains programmes seront fermés : est-ce que cela pose un soucis de part la fréquence et l’usage de la machine ou pas ? Il faut dans ce cas ajuster en connaissance de cause.

+0 -0

C’est marrant, à vous lire tous j’ai l’impression que l’heuristique de Linux par défaut n’est pas si efficace… Le mieux, je pense, reste de régler à tâtons vm.swappiness et vfs_cache_pressure sur la durée jusqu’à avoir un tuning adapté. Plus facile à dire qu’à faire, évidemment…

Sur un laptop qui n’a que 4 GB de RAM, j’ai aussi des soucis avec la politique de Linux qui a trop tendance à aller swapper. J’ai donc bidouillé ces paramètres et c’était un peu mieux, mais honnêtement rien de probant, je pense que j’ai pas très bien dû régler les valeurs et j’ai pas cherché plus loin. À noter que pour l’usage de ce laptop, 4 GB devrait suffire la plupart du temps (je n’ai jamais vu l’OOM Killer pointer le bout de son nez). De plus, nous ne sommes peut-être plus trop dans les standards actuels avec une telle quantité, il faudrait peut-être songer à ajouter une barrette en plus de tuner correctement les valeurs de sysctl.

+0 -0

C’est marrant, à vous lire tous j’ai l’impression que l’heuristique de Linux par défaut n’est pas si efficace… Le mieux, je pense, reste de régler à tâtons vm.swappiness et vfs_cache_pressure sur la durée jusqu’à avoir un tuning adapté. Plus facile à dire qu’à faire, évidemment…

sgble

Je ne vois pas comment il peut être possible de régler à tâtons ces paramètres. Se baser sur son ressenti de la fluidité et rapidité du système ? C’est dur de trouver des mesures plus subjectives et difficiles à estimer.

C’est marrant, à vous lire tous j’ai l’impression que l’heuristique de Linux par défaut n’est pas si efficace… Le mieux, je pense, reste de régler à tâtons vm.swappiness et vfs_cache_pressure sur la durée jusqu’à avoir un tuning adapté. Plus facile à dire qu’à faire, évidemment…

sgble

Je ne vois pas comment il peut être possible de régler à tâtons ces paramètres. Se baser sur son ressenti de la fluidité et rapidité du système ? C’est dur de trouver des mesures plus subjectives et difficiles à estimer.

tleb

En supposant que chaque jour la machine ait le même workload, je pense à de la collecte de metrics (qui correspondent in fine à ta conception de la réactivité du système). Chaque semaine tu regardes tes données et tu règles pour la semaine d’après. Tu ré-itères jusqu’à ce que tu tombes sur un résultat convenable.

Je ne dis pas que c’est facile, justement. Moi personnellement, je ne le ferais pas (je n’ai franchement pas que ça à faire, je préfère aller acheter des barrettes supplémentaires).

+0 -0

Maintenant, quand j’achète une nouvelle machine, je prends le maximum de RAM possible. Ça ne coûte plus très cher et c’est souvent inutile au début, et ensuite bien utile pour garder la machine quelques années de plus (minimum 5 ans pour moi). En ce moment j’ai une machine à 40Gio de RAM. Je pense que c’est un meilleur investissement que pousser le processeur, qui coûte vite cher pour des différences pas si énormes, surtout sur un ordinateur portable, en présence de contrôle thermique.

À mon avis c’est un choix plus efficace que d’essayer de tuner les paramètres de la swap sur sa machine.

Avoir beaucoup de RAM peut être une stratégie, mais attention toutefois : il faut un CPU/CM d’une certaine gamme (donc d’un certain prix) pour qu’il puisse supporter beaucoup de mémoire.

Mais j’ai le sentiment que de nos jours, ce n’est plus un grand problème. Beaucoup de CPU/CM grand public acceptent beaucoup de RAM désormais. À l’époque, il fallait taper du CPU et CM d’entreprise (ou grand public haut de gamme) pour utiliser énormément de RAM (et il fallait être en 64 bits de préférence).

À titre d’exemple, mon CPU est plutôt milieu de gamme et supporte quand même jusqu’à 64 GB de RAM, ce qui est très confortable pour quiconque en voulant autant.

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte