40 votes

Pourquoi Swap est utilisé quand il reste beaucoup de mémoire libre ?

J'ai un assez bon serveur web (dédié) avec de bonnes ressources mémoire :

System information
Server load     2.19 (8 CPUs)   
Memory Used     29.53% (4,804,144 of 16,267,652)    
Swap Used   10.52% (220,612 of 2,097,136)   

Comme vous pouvez le constater, mon serveur utilise le swap alors qu'il y a beaucoup de mémoire libre disponible.

Est-ce normal ou y a-t-il un problème dans la configuration ou le codage ?

N.B.
Mon processus MySQL utilise plus de 160 % de la puissance du processeur pour une raison quelconque ; je ne sais pas pourquoi, mais je n'ai pas plus de 70 utilisateurs simultanés ...

65voto

David Schwartz Points 31009

C'est tout à fait normal.

Au démarrage du système, un certain nombre de services démarrent. Ces services s'initialisent, lisent les fichiers de configuration, créent des structures de données, etc. Ils utilisent un peu de mémoire. Beaucoup de ces services ne seront jamais exécutés pendant toute la durée de fonctionnement du système, car vous ne les utilisez pas. Certains d'entre eux peuvent s'exécuter en quelques heures, jours ou semaines. Pourtant, toutes ces données se trouvent dans la mémoire physique.

Bien sûr, le système ne peut pas rejeter ces données. Il ne peut pas prouver qu'elles ne seront jamais consultées. L'un de ces services, par exemple, pourrait être celui qui vous permet d'accéder à distance à la boîte. Vous ne l'avez peut-être pas utilisé depuis une semaine, mais si vous l'utilisez, il a intérêt à fonctionner.

Mais le système sait qu'il pourrait utiliser cette mémoire physique pour des choses comme un cache de disque ou d'autres moyens d'améliorer les performances. Il pratique donc le swapping opportuniste. Lorsqu'il n'a rien de mieux à faire, il écrit sur le disque les données qui n'ont pas été utilisées depuis très longtemps, en utilisant l'espace d'échange. Cependant, il conserve toujours les pages en mémoire physique. Il est donc toujours possible d'y accéder sans avoir à les échanger.

Maintenant, si le système a besoin de cette mémoire physique pour quelque chose d'autre, il peut simplement jeter ces pages parce qu'il les a déjà écrites dans le swap. Le système bénéficie ainsi du meilleur des deux mondes. Les données sont toujours conservées en mémoire, ce qui permet d'y accéder sans avoir à les lire sur le disque. Mais si le système a besoin de cette mémoire dans un autre but, il n'aura pas à l'écrire d'abord. Tout le monde y gagne.

6voto

brain99 Points 1762

Cela peut se produire si, à un moment donné, vous avez eu besoin de plus de mémoire que la RAM physique de la machine. À ce moment-là, certaines données auront été écrites dans l'espace d'échange.

Lorsque la mémoire ultérieure est libérée, les données de l'espace de pagination ne sont pas automatiquement relues en RAM : cela ne se produit que lorsque les données de l'espace de pagination sont réellement requises par un processus. C'est parfaitement normal.

Quant à votre processus mysql : tout dépend du type de requêtes que vous exécutez. En théorie, 2 requêtes très complexes pourraient probablement suffire à obtenir une telle charge, quel que soit votre nombre d'utilisateurs. Vous pourriez activer le journal des requêtes lentes pour avoir une meilleure idée des requêtes qui sont les plus chargées.

4voto

daemonofchaos Points 1181

Vous pouvez également modifier ce comportement en sysctl -w vm.swappiness=10 ce qui réduira considérablement l'utilisation du swap jusqu'à ce qu'il soit réellement nécessaire.

Pour ce qui est de MySQL, avez-vous au moins effectué un test de configuration de base à l'aide de la commande tuning-primer.sh script ?

1voto

jfg956 Points 1106

Comme David l'a expliqué, il s'agit probablement d'un comportement normal du noyau Linux, mais il peut également s'agir d'une occurrence de la fonction Problème de "swap insanity" MySQL . Dans votre cas (8 CPU, 16 Go de RAM au total, 5 Go utilisés), pour que cela se produise, votre ordinateur devrait être un système NUMA avec 4 nœuds (sockets) et 4 Go de RAM par nœud et un pool de tampons MySQL InnoDB de 4 Go.

En bref (vous devriez lire le lien ci-dessus pour obtenir tous les détails), voici ce qui se passe :

  1. Au démarrage de votre système, les processus sont répartis sur tous les nœuds NUMA en utilisant une partie de leur mémoire.
  2. Lorsque MySQL démarre, il alloue 4 Go pour le pool de tampons InnoDB, remplissant la RAM d'un nœud NUMA et utilisant une partie de la RAM des autres nœuds.
  3. Ensuite, le noyau Linux, qui ne peut pas déplacer la RAM allouée d'un nœud NUMA à un autre, pense que c'est une bonne idée d'échanger des pages du nœud affamé (ou de devoir échanger des pages parce que des pages devaient être échangées).

Pour éviter cela, modifiez l'allocation de mémoire pour MySQL afin d'allouer de la RAM sur tous les cœurs (voir le lien ci-dessus pour plus de détails).

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X