Linux écrira préventivement les pages sur le disque si elle n'a rien de mieux à faire. Cela ne signifie pas pour autant qu'elle éjectera ces pages de la mémoire. C'est juste que dans le cas où elle devrait éjecter ces pages à un moment donné à l'avenir, elle n'a pas besoin d'attendre qu'elles soient écrites sur le disque, car elles y sont déjà.

Après tout, la raison pour laquelle vous manquez de mémoire est probablement parce que votre machine travaille déjà dur, vous ne voulez donc pas la surcharger en plus avec le swapping. Mieux vaut faire le swapping quand la machine ne fait rien.

Pour une raison similaire, votre mémoire devrait toujours être pleine. Pages de mémoire, cache du système de fichiers, tmpfs, il y a tellement de choses qui pourraient être conservées en mémoire. En réalité, vous devriez vous inquiéter si votre mémoire est vide; après tout, vous avez payé beaucoup d'argent pour cela (du moins comparé à la même quantité d'espace disque), alors autant qu'elle soit utilisée!

L'utilisation du swap n'est pas mauvaise, mais une activité de swap excessive l'est

  vmstat 1
  procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
  6  0 521040 114564   6688 377308    8   13   639   173    0 1100  5  4 90  0
  1  0 521040 114964   6688 377448    0    0   256     0    0 1826  3  4 94  0
  0  0 521040 115956   6688 377448    0    0     0     0    0 1182  7  3 90  0
  0  0 521036 115992   6688 377448    4    0    16     0    0 1154 10  2 88  0
  3  0 521036 114628   6696 377640    0    0   928   224    0 1503 15 17 67  1

La colonne swpd n'est pas du tout un problème. Les valeurs non nulles des colonnes si et so sont néfastes pour les performances du serveur, en particulier pour ceux avec beaucoup de RAM.

Il est préférable de désactiver la swapiness sur les machines avec plusieurs Go de RAM :

sysctl -w vm.swappiness=0

Cela ne désactive pas le swap. Cela indique simplement à Linux d'utiliser le swap en dernier recours. Cela gaspillera quelques Mo de programmes qui n'ont pas besoin d'être en RAM... Mais c'est préférable à ce que la swap ne sature vos files d'attente d'accès disque.

Édit 1: pourquoi la valeur par défaut de la swapiness n'est pas optimale

Il faut se rappeler que il y a deux décennies, un grand 486 avait seulement 32 Mo de RAM. Les algorithmes de swap ont été développés à une époque où toute la RAM pouvait être déplacée sur le disque en une fraction de seconde. Même avec les disques plus lents de l'époque. C'est pourquoi les politiques de swap par défaut sont si agressives. La RAM était le goulot d'étranglement à l'époque. Depuis lors, la taille de la RAM a augmenté de plus de 10 000 fois et les vitesses de disque moins de 10 fois. Cela a déplacé le goulot d'étranglement vers la bande passante du disque.

Édit 2: pourquoi l'activité si so est néfaste pour les serveurs?

L'activité si et so sur des machines avec beaucoup de RAM est néfaste car cela signifie que le système se bat avec lui-même pour la RAM. Ce qui se passe, c'est que les disques, même les grands stockages, sont trop lents par rapport à la RAM. Un swap agressif favorise le cache disque du noyau par rapport aux données d'application et est la source la plus courante de lutte pour la RAM. Puisque le système d'exploitation devra libérer le cache disque à chaque si, la durée de vie du cache supplémentaire que le swap fournit est trop courte pour être utile de toute façon. Le résultat est que vous utilisez la bande passante du disque pour stocker un cache qui ne sera probablement pas utilisé et vous mettez en pause vos programmes en attendant les pages si. Cela signifie que vous consommez beaucoup de ressources cruciales avec peu ou pas de bénéfice pour les applications.

Notez le titre de la réponse "une activité de swap excessive sur des serveurs avec beaucoup de RAM". Cela ne s'applique pas aux machines avec une activité occasionnelle de si et so. Cela pourrait ne pas s'appliquer à l'avenir si des algorithmes de swap plus intelligents sont développés dans les systèmes d'exploitation.

Édit 3: Pages "froides"

Les gens idéalisent l'algorithme de swap. Certains disent "il prend les pages RAM moins utilisées", mais ce n'est pas du tout ce que fait le noyau. La chose difficile à comprendre à propos du swap est que le noyau ne sait pas ce qu'est une "page froide". Le noyau n'a pas de bonne métrique pour déterminer si la page est utilisée ou susceptible d'être utilisée dans un avenir proche. Pour contourner cela, le noyau place les pages dans le swap de manière plus ou moins aléatoire et les pages qui ne sont pas nécessaires restent là. Le problème de cet algorithme est que les pages doivent aller dans le swap pour savoir si elles sont nécessaires par les applications. Et cela signifie qu'un grand nombre de pages "chaudes" finiront par aller dans le swap. Le problème est que les disques sont beaucoup trop lents par rapport à la RAM. La conséquence en est que lorsque le swapping commence, toutes les applications subissent des pauses aléatoires en attendant les disques, ce qui nuit à la latence et au débit.

J'ai créé mon propre benchmark qui représente un scénario réaliste très courant pour de nombreuses applications avec un volume important. D'après mes tests, je n'ai constaté aucun bénéfice en termes de débit ou de latence lorsque le swap est utilisé. Bien au contraire. Lorsque le swapping commence, il ralentit à la fois le débit et la latence d'au moins un ordre de grandeur.

Je vais un peu plus loin à ce sujet : Je comprends que le swap n'est pas destiné au traitement. Les swaps sont uniquement pour les urgences. Ces moments où trop d'applications tournent en même temps et où vous avez un pic de mémoire. Sans swap, cela provoquerait des erreurs de mémoire insuffisante. Je considère l'utilisation du swap comme un échec des équipes de développement et de production. Ceci n'est qu'une opinion qui va bien au-delà de ce que nous avons discuté ici, mais c'est ce que je pense. Bien sûr, mes applications ont une excellente gestion de la mémoire par elles-mêmes.

Ce n'est pas une réponse à votre question; mais plutôt, juste des informations supplémentaires pour vous aider à prendre une décision éclairée.

Si vous souhaitez savoir quels processus utilisent spécifiquement combien de mémoire swap, voici un petit script shell:

#!/bin/bash

set -o posix
set -u

OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"` ; do
  PID=`echo $DIR | cut -d / -f 3`
  PROGNAME=`ps -p $PID -o comm --no-headers`

  SUM=0
  for SWAP in `grep Swap $DIR/smaps 2>/dev/null| awk '{ print $2 }'` ; do
    let SUM=$SUM+$SWAP
  done
  echo "PID=$PID - Swap used: $SUM - ($PROGNAME )"

  let OVERALL=$OVERALL+$SUM
done
echo "Overall swap used: $OVERALL"

Je devrais également ajouter que tmpfs peut également être mis en swap. C'est plus courant sur les systèmes Linux modernes qui utilisent systemd et créent des superpositions /tmp en espace utilisateur utilisant tmpfs.

J'ai remarqué que la réplication de MySQL Cluster ralentit ou échoue lorsque les agents échangent massivement. Peut-être que certaines applications ne sont pas dérangées voire bénéficient de certains échanges, mais les bases de données semblent vraiment en souffrir. Cependant, de nombreuses discussions que j'ai vues sur les forums parlent d'échanges de manière décontextualisée par rapport à la discussion sur la charge de travail spécifique.

Dans le monde des DBA, le consensus semble être que "il va de soi que lorsque vous exécutez MySQL (ou vraiment tout autre SGBD), vous ne voulez voir aucun E/S dans votre espace d'échange. Mettre à l'échelle la taille du cache (en utilisant innodb_buffer_pool_size dans le cas de MySQL) est une pratique courante pour s'assurer qu'il y a suffisamment de mémoire libre pour ne pas avoir besoin d'échanger.

Mais que se passe-t-il si vous commettez une erreur ou une mauvaise estimation, et que des échanges se produisent ? Dans quelle mesure cela impacte-t-il réellement les performances ? C'est exactement ce que j'ai entrepris d'étudier. "

J'espère que les lecteurs trouveront les liens suivants appropriés.

https://www.percona.com/blog/2017/01/13/impact-of-swapping-on-mysql-performance/

https://www.percona.com/blog/2010/01/18/why-swapping-is-bad-for-mysql-performance/