Solution 1 :
kswapd gère l'espace d'échange en réponse aux demandes de mémoire supérieures à celles physiquement disponibles pour tous processus.
Il est indépendant du processus, il ne s'intéresse qu'aux pages auxquelles on accède et quand (c'est bien sûr plus complexe que cela, mais pour garder les choses simples, autant le voir de cette façon).
Alors le vrai la question est "quels processus ont la plus grande charge sur la mémoire qui obligent kswapd à paginer tout le temps".
Il est plus facile d'y répondre en utilisant 'top' et en passant en mode de tri d'utilisation de la mémoire.
Solution 2 :
Vous pouvez le scripter... mais vous pouvez aussi le faire via top
Courez en haut puis appuyez sur O suivi de p puis entrez
Maintenant, tous les processus sont triés par utilisation du swap et vous pouvez voir lesquels l'utilisent
Solution 3 :
Si vous utilisez Ubuntu 15.10 ou une version ultérieure, cela peut en fait être le résultat d'un bogue, en particulier si votre système est une machine virtuelle sans partition de swap (par exemple, AWS EC2). Le problème existe sur d'autres distributions, mais, au moment de l'écriture, il n'est pas clair si le même correctif fonctionne universellement.
Une solution de contournement temporaire :
sudo ln -s /dev/null /etc/udev/rules.d/40-vm-hotadd.rules
sudo reboot
Notez que cela désactivera l'ajout à chaud de RAM/CPU pour les machines virtuelles Xen et Hyper-V.
Solution 4 :
Il semble également y avoir un bogue dans kswapd quelque part, espérons-le uniquement sur des noyaux plus anciens.
Presque chaque jour maintenant, kswapd devient fou au hasard sur certaines machines dans un cluster plus grand (avec un noyau non actuel, cependant). 100% CPU sur les deux processus kswapd. Aucun autre processus en cours d'exécution (à l'exception du shell ssh), beaucoup de RAM libre (plus de 700 Mo) et aucun SWAP utilisé. Pas de swapin, pas de swapout non plus.
Rien n'explique encore pourquoi une machine particulière est touchée et une autre non. Il ne semble pas être complètement aléatoire, car il frappe généralement plus d'une machine dans un court laps de temps. Il semble que les machines, qui sont inactives, ainsi que les machines, qui sont sous haute pression, soient moins (!) susceptibles d'être touchées par l'effet. Il doit donc faire quelque chose avec la charge de travail et ne se déclenche que si la machine n'est ni inactive ni très occupée.
Si le problème survient, rien n'y fait plus. Tuer tous les processus (qui ne sont pas devenus impossibles à tuer), démonter tous les systèmes de fichiers, rien. kswapd reste toujours à 100% CPU. Je soupçonne une course au spinlock dans les noyaux SMP, mais il est également probable que je me trompe.
Voir peut-être ma réponse serverfault.com/questions/316995/#493257
Remarques :
- Le redémarrage des machines concernées échoue souvent car le processus d'arrêt commence à se bloquer quelque part.
- Il n'y a pas de connexion directe à Internet. Les causes étrangères sont peu probables.
- Cela semble dépendre du type de charge de travail que les machines traitent du point de vue de la charge, car nous avons des machines qui n'ont jamais été affectées (encore).
- Désolé, je ne peux pas être plus précis sur ce que nous faisons et pourquoi.
- Oui, je spécule. Parce que c'est un effet extrêmement déroutant, aujourd'hui.