J'ai un serveur cloud avec environ 14 Go de RAM et aucun échange. Cependant, je vois parfois kswapd0 prendre un peu de CPU lorsque je cours top. Pourquoi kswapd0 fonctionnerait-il s'il n'y a pas d'espace de swap à gérer?
J'ai un serveur cloud avec environ 14 Go de RAM et aucun échange. Cependant, je vois parfois kswapd0 prendre un peu de CPU lorsque je cours top. Pourquoi kswapd0 fonctionnerait-il s'il n'y a pas d'espace de swap à gérer?
Réponses:
Il a toujours un processus pour vérifier s'il y a un échange. Pour le réduire, vous devrez définir votre swappiness -
éditez "/etc/sysctl.conf" en tant que root, puis changez (ou ajoutez)
vm.swappiness = 0
kswapd0prend n'importe quel CPU et que vous n'avez pas de swap, le système est presque hors de RAM et essaie de faire face à la situation en (en pratique) en échangeant les pages des exécutables. La solution correcte consiste à réduire la charge de travail, à ajouter un échange ou (de préférence) à installer plus de RAM. L'ajout de swap améliorera les performances car le noyau aura plus d' options sur ce qu'il faut swap sur le disque. Sans échange, le noyau est pratiquement obligé d'échanger le code d'application.
kswapd0utilisez un processeur et que vous ne le souhaitez pas, diminuez le swappinessparamètre. Cependant, à moins que votre swap ne soit soutenu par un SSD qui souffre d'écriture (par exemple, mauvais algorithme de nivellement d'usure), la réduction de la swappinessréduit les performances globales du système. L'idée est de conserver une copie de la RAM dans le swap au cas où plus de RAM serait nécessaire - dans ce cas, la copie dans la RAM est jetée immédiatement au lieu de commencer à l'échanger avant que la RAM puisse être utilisée. Cet échange optimiste n'est effectué que lorsque le système est suffisamment inactif pour ne jamais ralentir votre système.
L'espace d'échange n'est utilisé que pour les données qui ne sont sauvegardées par aucun autre fichier. Les données mappées à partir d'autres fichiers sur le disque (tels que les programmes exécutables) sont toujours échangées vers leurs fichiers respectifs même si vous ne disposez pas d'un périphérique de swap.
C'est un problème bien connu que lorsque Linux manque de mémoire, il peut entrer des boucles d'échange au lieu de faire ce qu'il devrait faire, tuant les processus pour libérer de la mémoire RAM. Il existe un tueur OOM (Out of Memory) qui fait cela, mais uniquement si Swap et RAM sont pleins.
Cependant, cela ne devrait pas vraiment être un problème. S'il y a un tas de processus incriminés, par exemple Firefox et Chrome, chacun avec des onglets qui utilisent et récupèrent de la mémoire, alors ces processus provoqueront une lecture de permutation. Linux entre alors dans une boucle où la même mémoire est déplacée d'avant en arrière entre la mémoire et le disque dur. Cela entraîne à son tour une inversion de priorité où l'échange de quelques processus d'avant en arrière rend le système insensible.
Si vous désactivez l'échange, vous aggravez ce problème car kswapd0 n'a plus d'autre option que d'échanger de la mémoire mappée, comme des exécutables. Si vous échangez des exécutables, il est encore plus probable qu'ils seront à nouveau échangés assez rapidement.
J'ai essayé de déclencher ce comportement dans NetBSD pour les tests et ce qui s'est passé, c'est que le processus incriminé est devenu incroyablement lent alors que le système d'exploitation lui-même était très réactif. Cela signifie que le problème de permutation se produit mais qu'il n'y a pas d'inversion de priorité. Cependant, NetBSD n'a pas de pilotes AMDGPU, donc je m'en tiens à Linux pour le moment. Peut-être que NetBSD ne mappe pas les exécutables de la mémoire et c'est pourquoi il n'entre pas dans les boucles de swap, mais je ne connais pas vraiment assez son implémentation pour dire pourquoi il ne répond pas.
Facebook a également rencontré ce problème et a créé le OOMD qui est le démon Out Of Memory. Il s'agit d'un démon qui détecte l'activité kswapd0 et commence à tuer les processus. Et selon Facebook, cela a presque entièrement éliminé le problème des serveurs Linux ne répondant plus. Cependant, je ne l'ai pas testé et je ne sais pas comment cela fonctionnera sur d'autres serveurs ou ordinateurs de bureau / portables. De manière attrayante, OOMD a une certaine logique pour décider des processus à tuer en premier afin de préserver les processus système et la partie de leur système serveur qui est responsable de la relance de tout ce qui a été tué.
Cependant, ce n'est pas ainsi que cela devrait être résolu. OOMD est un UGLY HACK. La vraie solution est de corriger l'inversion de priorité causée par une boucle de swap et de rendre le noyau OOM Killer plus agressif pour tuer les processus afin de libérer de la mémoire. Le correctif appartient au noyau car c'est le seul endroit où nous pouvons être sûrs que le problème est détecté à temps et que les processus sont correctement éliminés.
Définir swappiness = 0 n'est pas une solution car lorsque le système est à court de RAM libre, il commence à échanger quoi qu'il arrive. Il n'y a aucune option pour garantir que le système ne démarre pas l'échange.
Et aussi la correction des applications incriminées n'est pas une solution. Surtout pas si un utilisateur souhaite exploiter ce bogue afin de rendre intentionnellement le système d'exploitation insensible. Être réactif est la responsabilité du noyau. Si Firefox ne répond plus, le correctif concerne l'application. Cependant, il ne se rend pas seulement insensible, mais rend l'ensemble du système d'exploitation très lent et ne répond pas. Au niveau où cela peut prendre une demi-heure pour se connecter à SSH. Le SSH n'a rien à voir et s'il ne fonctionne pas, c'est un bogue dans le noyau, pas dans aucune autre partie du système. Et ce n'est pas un bug c'est deux bugs. Un bug est l'inversion de priorité où un cycle de permutation hors des rails est autorisé à interférer avec d'autres processus que le ou les processus incriminés et cela en soi est mauvais. L'autre bug est qu'il ne fonctionne pas t détecter qu'il est dans une boucle de swap et que cela provoque une usure insensée sur le disque dur / SSD ou tout autre stockage qui soutient le swap. Lorsque vous échangez un exécutable, cela pose moins de problème car ce sont des cartes mémoire en lecture seule qui ne sont pas écrites sur les disques, mais kswapd0 est toujours verrouillé en lisant ce qu'il supprime en même temps de la mémoire.
Oh et il y a un troisième bug. Le fait qu’il n’existe aucun moyen de protéger le disque CACHE contre la consommation lorsque les applications gourmandes en mémoire avalent toute la mémoire disponible. C'est l'une des raisons pour lesquelles kswapd0 rend le système insensible. Les données mappées en mémoire les plus chaudes sont généralement stockées dans le cache disque, mais lorsque firefox a consommé ce cache, cela signifie évidemment que des lectures sur disque devront avoir lieu.
Ce n'est pas nécessairement Firefox qui cause votre problème mais c'est le navigateur par défaut, pas Chrome. Et les deux sont largement connus pour déclencher ce problème car ils traitent la mémoire disponible comme quelque chose de gaspillé, y compris le cache et la mémoire d'échange qui, sous Linux, comptent comme «mémoire disponible». Donc, afin de ne pas perdre de «mémoire disponible», utilisez-le pour la mise en cache et d'autres choses. De toute évidence, l'utilisation de SWAP pour DISK CACHE est une IDÉE TRÈS MAUVAISE, mais les boursiers de Firefox et de Chrome répondent à cela par "la mémoire libre est une mémoire gaspillée".
Donc, ce que nous avons ici, c'est trois bogues du noyau que l'équipe du noyau ne semble pas considérer comme des bogues. Et un bug dans Firefox, Chrome et tous les dérivés qu'ils ne considèrent pas comme un bug. J'ai essayé de construire Firefox sur mon ordinateur portable Fedora afin d'examiner ce problème et peut-être de le corriger. Devine quoi. Construire Firefox avec GCC sur un processeur à 4 cœurs avec 4 Go de RAM déclenche une boucle SWAP avec une inversion de priorité. Donc, l'une des applications qui doit être réécrite est GCC. Sur NetBSD, ce qui se passe, c'est que les 4 instances de GCC en cours d'exécution sont plus lentes que l'exécution d'une instance, mais cela ne gèle pas le système.
Oui, c'est un peu une diatribe, mais j'espère que cela clarifie le problème actuel avec les sous-systèmes de mémoire Linux ainsi que les applications qui en sont la cause.
Si vous n'avez pas de swap et qu'il kswapd0est en cours d'exécution, votre système utilise en fait presque toute la RAM à ce moment. Il est temps d'obtenir de meilleurs outils pour surveiller l'utilisation de la mémoire (ou la mémoire libre / disponible dans le système).
La vraie solution consiste à réduire l'utilisation de la mémoire (exécuter des processus avec moins de fuites de mémoire, exécuter moins de processus, ignorer certains processus, limiter le nombre de processus enfants / travailleurs de certains logiciels de serveur) ou obtenir plus de RAM. Si le besoin de RAM est causé par des fuites de mémoire, vous pouvez choisir d'utiliser à la place le swap. Linux devrait être assez intelligent pour échanger les pièces perdues avec suffisamment de temps. Avoir un échange est mieux que rien mais ce n'est pas un vrai substitut pour avoir une quantité adéquate de RAM.