J'ai un hôte de production, ci-dessous:

Le système utilise 1 Go d’échange, tout en conservant près de 40 Go d’espace mémoire libre et inutilisé. Devrais-je m'inquiéter à ce sujet ou est-ce surtout normal?

Ce n'est pas un problème et c'est probablement normal. Beaucoup de code (et éventuellement de données) est utilisé très rarement, de sorte que le système l'échangera pour libérer de la mémoire.

L’échange n’est généralement un problème que si la mémoire est constamment échangée. C'est ce type d'activité qui tue les performances et suggère un problème ailleurs sur le système.

Si vous souhaitez surveiller votre activité de swap, vous pouvez utiliser plusieurs utilitaires, mais cela vmstatest généralement très utile, par exemple:

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 348256  73540 274600    0    0     1     9    9    6  2  0 98  0  0
 0  0      0 348240  73544 274620    0    0     0    16   28   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   29   33  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   21   23  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   24   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   23   23  0  0 100  0  0

Ignorez la première ligne car il s'agit d'une activité depuis le démarrage du système. Notez les colonnes siet sosous ---swap--; ils devraient généralement être assez petits sinon 0 pour la plupart du temps.

Il convient également de mentionner que cette permutation préventive peut être contrôlée avec un paramètre de noyau. Le fichier at /proc/sys/vm/swappinesscontient un nombre compris entre 0 et 100 qui indique au noyau comment échanger de manière agressive la mémoire. Cat le fichier pour voir ce que cela est défini. Par défaut, la plupart des distributions Linux fixent ce nombre à 60, mais si vous ne voulez voir aucune permutation avant que la mémoire ne soit épuisée, écrivez un 0 dans le fichier comme ceci:

echo 0 >/proc/sys/vm/swappiness

Cela peut être rendu permanent en ajoutant

vm.swappiness = 0

à /etc/sysctl.conf.

Linux écrira de manière préventive les pages sur le disque s’il n’a rien de mieux à faire. Cela ne signifie toutefois pas qu'il expulsera ces pages de la mémoire. C'est juste que dans le cas où il devrait expulser ces pages un jour ou l'autre, il n'a pas besoin d'attendre qu'elles soient écrites sur disque, car elles sont déjà là.

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

Pour une raison similaire, votre mémoire devrait toujours être pleine. Pages de mémoire, cache de système de fichiers tmpfs, il y a tellement de choses qui pourraient être gardées en mémoire. Vraiment, vous devriez être inquiet si votre mémoire est vide; après tout, vous en avez payé beaucoup (au moins par rapport à la même quantité d’espace disque), il vaut donc mieux l’utiliser!

L’échange utilisé n’est pas mauvais, mais beaucoup d’activités d’échange 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 swapd n'est pas un problème du tout. Des valeurs non nulles sur les colonnes si et ainsi sont mortelles pour les performances du serveur. Spécialement ceux avec beaucoup de RAM.

Il est préférable de désactiver swapinness sur les machines disposant de plusieurs Go de RAM:

sysctl -w vm.swappiness=0

Cela ne désactivera pas l'échange. Il ne demandera à Linux d’utiliser le swap qu’en dernier recours. Cela va gaspiller quelques Mo de programmes qui n'ont pas besoin d'être dans la RAM ... Mais il est préférable d'échanger vos files d'attente d'accès au disque.

Edition 1: pourquoi la valeur par défaut de swappiness n'est pas optimale

Il y a deux décennies, nous nous souvenions qu'un grand 486 ne disposait que de 32 Mo de RAM. Les algorithmes de swap ont été développés lorsque la totalité de la RAM pouvait être déplacée sur le disque en une fraction de seconde. Même avec les disques les plus lents de cette époque. C'est pourquoi les stratégies de swap par défaut sont si agressives. La RAM était le goulot d'étranglement de ces jours. Depuis lors, la taille de la RAM a augmenté de plus de 10 000 fois et la vitesse du disque de moins de 10 fois. Cela a déplacé le goulot d'étranglement vers la bande passante du disque.

Edit 2: pourquoi cette activité est mortelle pour les serveurs?

Si et si l' activité sur des machines avec des tonnes de RAM est mortelle, cela signifie que le système se bat contre lui-même pour obtenir de la RAM. Qu'est-ce qui se passe, c'est que les disques, même les grands stockages, sont trop lents par rapport aux RAM. Un échange agressif favorise le cache disque du noyau par rapport aux données d'application et constitue la source la plus courante de lutte pour la RAM. Etant donné que le système d'exploitation devra libérer le cache disque à chaque emplacement , la durée de vie du cache supplémentaire fourni par le swap est trop courte pour être utile de toute façon. Le résultat est que vous utilisez la bande passante du disque pour stocker le cache qui ne sera probablement pas utilisé et que vos programmes attendent les pages si . Cela signifie que cela consomme beaucoup de ressources critiques avec peu ou pas d'avantages pour les applications.

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

Edit 3: pages "froides"

Les gens romancent l'algorithme d'échange. Certains disent "cela prend des pages moins utilisées de la RAM", mais ce n'est pas du tout ce que fait le noyau. La chose est difficile à comprendre à propos de swap est le noyau ne sait pas ce qu'est une "page froide". Le noyau ne dispose pas d'une métrique permettant de déterminer si la page est utilisée ou susceptible de l'être dans un avenir proche. Pour éviter que 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 y restent. Le problème de cet algorithme est que les pages doivent aller au swap pour savoir si les applications en ont besoin. Et cela signifie que beaucoup de pages "chaudes" iront à l'échange. Le problème, c'est que les disques sont trop lents par rapport à la RAM.

J'ai construit mon propre benchmark, un scénario réaliste très commun à de nombreuses applications avec un volume décent. D'après mes tests, je n'ai constaté aucun avantage en termes de débit ou de latence lors de l'utilisation des swaps. Loin de là. Lorsque la permutation commence, le débit et la latence sont ralentis d'au moins un ordre de grandeur.

Je vais un peu plus loin à ce sujet: je comprends que l’échange n’est pas destiné au traitement. Les échanges sont uniquement pour les urgences. Ces moments où trop d'applications sont en cours d'exécution en même temps et que vous obtenez un pic de mémoire. Sans échange, cela entraînerait des erreurs de mémoire insuffisante. Je considère l’utilisation de swap comme un échec des équipes de développement et de production. C’est une opinion qui va bien au-delà de ce dont nous avons discuté ici, mais c’est ce que je pense. Bien entendu, mes applications disposent d’une excellente gestion de la mémoire.

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 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 les fichiers tmpfs seront également échangés. Ceci est plus courant sur les systèmes linux modernes utilisant systemd qui créent des superpositions utilisateur / tmp en utilisant tmpfs.

J'ai remarqué que la réplication de MySQL Cluster ralentissait ou échouait lorsque les agents échangeaient beaucoup. Certaines applications ne sont peut-être pas gênées par le swap ou bénéficient peut-être de certains échanges, mais les bases de données semblent en souffrir. Cependant, de nombreuses discussions que j'ai vues sur des forums ont trait à des échanges de fichiers décontextualisés à partir de la discussion sur la charge de travail spécifique.

Dans le monde des administrateurs de bases de données, le consensus semble être le suivant: "Il est de bon sens que, lorsque vous utilisez MySQL (ou tout autre système de gestion de base de données), vous ne souhaitez voir aucune entrée / sortie dans votre espace de swap. Dans le cas de MySQL, innodb_buffer_pool_size est une pratique courante pour s’assurer qu’il ya suffisamment de mémoire disponible, ainsi aucun échange n’est nécessaire.

Mais que se passe-t-il si vous faites une erreur ou une erreur de calcul et que l’échange a lieu? Dans quelle mesure cela influe-t-il vraiment sur les performances? C’est exactement ce que j’ai voulu enquêter. "

J'espère que les lecteurs trouveront les liens suivants à propos.

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/