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

J'ai un très bon serveur web (dédié) avec de bonnes ressources de 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 l’échange lorsqu'il ya beaucoup de mémoire disponible.

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

NB:
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 ...

C'est parfaitement normal.

Au démarrage du système, un certain nombre de services démarrent. Ces services s'initialisent, lisent dans les fichiers de configuration, créent des structures de données, etc. Ils utilisent de la mémoire. Bon nombre de ces services ne fonctionneront plus jamais pendant toute la durée du système, car vous ne les utilisez pas. Certains d'entre eux peuvent durer des heures, des jours ou des semaines. Pourtant, toutes ces données sont dans la mémoire physique.

Bien entendu, le système ne peut pas jeter ces données. Il ne peut pas prouver qu'il ne sera littéralement jamais utilisé. L'un de ces services, par exemple, pourrait être celui qui vous fournit un accès à distance à la boîte. Vous ne l’avez peut-être pas utilisé en une semaine, mais si vous l’utilisez, il est préférable de travailler.

Mais le système sait qu'il peut utiliser cette mémoire physique pour des tâches telles que le cache de disque ou pour améliorer les performances. Donc, il fait un échange opportuniste. Lorsqu'il n'a rien de mieux à faire, il écrit sur le disque des données qui n'ont pas été utilisées depuis très longtemps, en utilisant l'espace de permutation. Cependant, il conserve toujours les pages dans la mémoire physique. Ils peuvent donc toujours être consultés sans avoir à les échanger.

Maintenant, si le système a besoin ultérieurement de cette mémoire physique pour autre chose, il peut simplement jeter ces pages, car il les a déjà écrites pour les permuter. Cela donne au système le meilleur des deux mondes. Les données sont toujours conservées en mémoire, vous pouvez donc y accéder sans avoir à les lire à partir du disque. Mais si le système a besoin de cette mémoire dans un autre but, il n'aura pas à l'écrire en premier. Grande victoire tout autour.

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

Lorsque la mémoire est libérée ultérieurement, les données de swap ne sont pas automatiquement lues dans la RAM: cela ne se produit que lorsque les données de swap sont réellement nécessaires à un processus. C'est parfaitement normal.

En ce qui concerne votre processus mysql: tout dépend du type de requête que vous exécutez. En théorie, deux requêtes très complexes pourraient probablement suffire pour obtenir une telle charge, quel que soit votre nombre d'utilisateurs. Vous pouvez activer le journal de requête lent pour obtenir plus d'informations sur les requêtes qui nécessitent beaucoup de charge.

Vous pouvez également modifier ce comportement en sysctl -w vm.swappiness=10, ce qui réduira considérablement l'utilisation de l'échange 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 en utilisant le script tuning-primer.sh ?

Comme David l'a expliqué, il s'agit probablement d'un comportement normal du noyau Linux, mais il peut également s'agir d'un problème du problème «swap insanity» de MySQL . Dans votre cas (8 processeurs, 16 Go de RAM au total, 5 Go utilisés), votre ordinateur doit être un système NUMA avec 4 nœuds (sockets) et 4 Go de RAM par nœud et un pool de mémoire tampon MySQL InnoDB de 4 GB.

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

1. Lorsque votre système démarre, les processus sont répartis sur tous les nœuds NUMA en utilisant une partie de leur mémoire.
2. Au démarrage, MySQL alloue 4 Go au pool de mémoire tampon InnoDB, remplit la RAM d’un nœud NUMA et utilise de la RAM sur d’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 qu’il est judicieux d’échanger les pages du nœud affamé (ou de devoir échanger des pages car celles-ci devaient être permutées).

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