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

35

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

linux mysql php

— utilisateur1179459
source

Les applications peuvent utiliser plus de 100% du processeur sous Linux?

— Euh

5

@BlueRaja: Oui, car sous Linux, l'utilisation du processeur est mesurée par rapport à un processeur unique, et non à tous les processeurs de votre système. Ainsi, dans une machine à 8 processeurs, vous avez un maximum de 800% de processeurs disponibles.

— Daniel Pryden

Quelle version de MySQL utilisez-vous ???

— RolandoMySQLDBA

@RolandoMySQLDBA version 5.5

— utilisateur1179459

61

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.

— David Schwartz
source

Dans ce cas, pouvez-vous expliquer pourquoi parfois, l'espace d'échange n'est pas utilisé du tout. Mem: 49554484k total, 4087592k utilisé, 45466892k gratuit, 349244k tampons Échange: 94204k total, 0k utilisé, 94204k gratuit, 1113644k caché

— ananthan

4

@ananthan: Il pourrait y avoir plusieurs raisons. Le plus probable est que le système n'a jamais été soumis à aucune pression de mémoire, même en raison d'écritures en mémoire tampon, de sorte que le code d'échange opportuniste n'a peut-être jamais été déclenché. Il se peut également que quelqu'un ait pensé que toute utilisation de swap était mauvaise et a donc mal ajusté le système pour ne pas échanger de manière opportuniste (en réduisant les swappiness ).

— David Schwartz

6

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.

— cerveau99
source

Non - l'utilisation de swap n'est pas une marque de succès. Lorsque les pages remplacées sont remappées, les pages du disque sont marquées comme non utilisées (mais peuvent toujours contenir des données).

— symcbean

J'ai seulement mentionné un scénario dans lequel vous pouvez avoir une utilisation d'échange, mais cela n'est en effet pas toujours symptomatique de ne pas avoir assez de mémoire physique - comme l'explique également David Schwartz ci

— brain99

3

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 ?

— Daemon of Chaos
source

1

Cela augmentera la tendance à la récupération des mémoires cache / tampons. Malheureusement, il n’est pas clair dans la question initiale si le chiffre de 29,53% inclut les tampons / le cache. Si ce n’est pas le cas, apporter les modifications suggérées aura un impact négatif sur les performances. Si ce dbms utilise abondamment innodb, il est probablement mal configuré (bien qu'un seul boîtier à 8 cœurs de 16 Go destiné à être utilisé comme serveur Web soit un mauvais choix pour commencer)

— symcbean

pourquoi dites-vous que c'est un mauvais choix pour le serveur Web? Je n'utilise pas beaucoup innodb, mais je préfère encore myisam car mes lectures sont de 70% et n'écrit que 30% ....

— user1179459

1

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:

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.
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.
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).

— jfg956
source