Vous pouvez faire ce que nik a suggéré et utiliser swapoff . Cependant, il existe une autre façon, plus élégante, de modifier le "swappiness", ou avec quelle agressivité le noyau échange les programmes sur le disque dans les systèmes exécutant les noyaux 2.6.
Il y a eu des débats houleux sur les listes de diffusion du noyau Linux sur la politique que le noyau devrait suivre concernant le comportement d'échange . Le résultat est que nous avons maintenant un patch en 2.6 noyaux qui nous permet de modifier ce comportement dans une large mesure.
Notez que vous avez besoin des privilèges root pour ce faire, comme vous le feriez pour exécuter les commandes swapoff / swapon.
La valeur actuelle de "swappiness" peut être inspectée dans le fichier / proc / sys / vm / swappiness , ou en exécutant cette commande sysctl :
sudo sysctl vm.swappiness
Les valeurs de "permutation" peuvent aller de 0 (pas de permutation) à 100 (permutation sur disque autant que possible). Ubuntu est livré avec la permutation par défaut définie sur 60.
Pour changer cela pour une session, appelez à nouveau sysctl et passez-lui une valeur de swappiness à utiliser:
sudo sysctl vm.swappiness=30
Outre la gratuité , vous pouvez bien sûr surveiller les effets de cette opération via les excellents utilitaires htop ou iotop .
Si vous aimez ce que vous voyez et souhaitez conserver cette valeur lors des redémarrages, placez simplement "vm.swappiness = 30" dans le fichier /etc/sysctl.conf .
$ sudo sysctl vm.swappiness
vm.swappiness = 30
$ sudo sysctl vm.swappiness=40
vm.swappiness = 40
$ sudo sysctl vm.swappiness
vm.swappiness = 40
$ sudo tail /etc/sysctl.conf
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#
# The contents of /proc/<pid>/maps and smaps files are only visible to
# readers that are allowed to ptrace() the process
# kernel.maps_protect = 1
vm.swappiness=30
Vous pouvez jouer avec différentes valeurs jusqu'à ce que vous en trouviez une qui implique un niveau acceptable de permutation sur votre machine.
Rappelez-vous que les trucs en swap ont été placés à un moment plus occupé que maintenant.
Vous pourriez bien trouver que les données sont également dans la RAM - ayant été chargées pour être utilisées mais pas effacées du swap. Le noyau fait cela pour gagner du temps dans la prochaine période occupée - si les données y sont déjà copiées, il peut simplement libérer la RAM qu'il utilise au lieu d'avoir à faire des écritures sur disque en premier. Donc, à moins que vous ne sachiez que la machine n'aura pas besoin de changer à nouveau dans un avenir proche, forcer la libération de l'espace de swap peut ne rien faire sauf ralentir les choses un peu plus la prochaine fois qu'un swap est nécessaire.
Ceci est géré sur une base de suppression sur écriture, donc si la copie dans la RAM est mise à jour, les blocs de swap seront libérés.
Si l'espace de swap est nécessaire pour autre chose, ce qu'il ne sera pas pour le moment car vous en avez beaucoup, il sera bien sûr libéré pour cette utilisation.
Vous ne pouvez pas voir la quantité de données dans cet état (d'être à la fois dans des pages sur disque dans des zones d'échange et en RAM) dans la sortie de
free. Vous pouvez le voir via le/procsystème de fichiers spécial. Regardez la sortie decat /proc/meminfopour leSwapCachedcompte.Deux autres raisons pour lesquelles il y a permutation en cas de mémoire apparemment disponible sont
freesortie ce n'est probablement pas le cas ici comme vous avoir un morceau de RAM vraiment non allouée ainsi que celle utilisée par le cache / tampons d'E / S.la source
N'oubliez pas que ce
freen'est qu'un instantané de l'utilisation de la mémoire. Le résultat que vous voyez peut impliquer que, à un moment donné dans le passé, le système manquait de RAM, donc du matériel résidant sur la RAM. Depuis lors, la RAM est devenue libre, mais le matériel sur le swap n'a pas été nécessaire, donc est toujours conservé sur le swap plutôt que d'encombrer la RAM. Si tel est le cas, désactiver le swap serait une mauvaise idée. Existe-t-il des processus qui pourraient exiger une telle quantité de RAM depuis le dernier rechargement?De plus, vous voudrez peut-être vérifier que vous n'avez pas de restriction sur la taille maximale des résidents définie via ulimit (généralement dans / etc / profile mais cela peut varier selon les distributions et elle peut être définie par processus (par exemple dans un script de lancement) ).
Enfin, sur Microsoft Windows, il y a des rapports de problèmes spécifiques avec Firefox étant échangé sur le disque, par exemple lorsqu'il est minimisé (par exemple http://joeabiraad.com/mozilla-firefox/control-your-firefox-ram-usage/113 ). Je n'en ai pas entendu parler sur les systèmes GNU / Linux mais cela vaut peut-être la peine d'être exploré.
la source