Kswapd0 utilise beaucoup de CPU

Kswapd0 fonctionne à 99,9% d'un CPU mais en réalité n'échange pas du tout de mémoire

Pour moi, cela arrive parfois sur Ubuntu 14.04 avec le noyau 3.19.0-50-generic (et précédent) fonctionnant dans une machine virtuelle VMware. Je n'ai aucune idée de ce qui l'a fait apparaître, mais cela se produit pendant les périodes d'inactivité.

top montre :

# top
top - 09:49:35 up 5 jours, 18:35,  1 utilisateur,  charge moyenne: 1,00, 1,00, 0,99
Tâches: 219 au total,   2 en cours d'exécution, 217 en attente,   0 arrêtées,   0 zombies
%Cpu(s) :  0,0 en, 25,0 sy,  0,0 ni, 74,7 id,  0,2 wa,  0,0 hi,  0,1 si,  0,0 st
KiB Mem:   3028784 total,  1874468 utilisé,  1154316 libre,  1010276 tampons
KiB Swap: 15624188 total,     3032 utilisé, 15621156 libre.   234928 Mémoire cache

   PID UTILISATEUR   PR  NI   VIRT    RES    SHR S  %CPU %MEM     TEMPS+ COMMANDE
    52 root      20   0       0      0      0 R  99,7  0,0 122:15.21 kswapd0
     3 root      20   0       0      0      0 S   0,3  0,0   0:29.86 ksoftirqd/0
     7 root      20   0       0      0      0 S   0,3  0,0   9:49.47 rcu_sched

Solution temporaire

un redémarrage a résolu le problème - temporairement.

suivant la réponse sur serverfault (kswapd utilise souvent 100% du CPU lorsque l'échange est en cours d'utilisation) où les mêmes réglages étaient présents sur mon système :

# cat /proc/sys/vm/swappiness
60
# cat /proc/sys/vm/vfs_cache_pressure
100
# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

la solution était en fait d'exécuter echo 1 > /proc/sys/vm/drop_caches en tant qu'utilisateur root :

# cat /proc/sys/vm/drop_caches
0
# echo 1 > /proc/sys/vm/drop_caches
# cat /proc/sys/vm/drop_caches
1

Ou, comme indiqué par theTuxRacer (merci !), utilisez la commande suivante si vous n'êtes pas connecté en tant qu'utilisateur root :

echo 1 | sudo tee /proc/sys/vm/drop_caches

maintenant tout va bien :

# top
top - 10:08:58 up 5 jours, 18:55,  1 utilisateur,  charge moyenne: 0,72, 0,95, 0,98
Tâches: 220 au total,   1 en cours d'exécution, 219 en attente,   0 arrêtées,   0 zombies
%Cpu(s) :  0,0 en,  0,2 sy,  0,0 ni, 99,8 id,  0,0 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem:   3028784 total,   681704 utilisé,  2347080 libre,     2916 tampons
KiB Swap: 15624188 total,     3032 utilisé, 15621156 libre.    81924 Mémoire cache

   PID UTILISATEUR   PR  NI   VIRT    RES    SHR S  %CPU %MEM     TEMPS+ COMMANDE
     9 root      20   0       0      0      0 S   0,3  0,0  14:10.40 rcuos/0
     1 root      20   0   45652   8124   2888 S   0,0  0,3   1:54.98 init

Solution permanente (à trouver) ?

mais puisque la raison exacte n'est pas encore connue, et que je n'ai trouvé aucune explication satisfaisante sur le net, cela ne constitue pas une solution permanente. En fait, la réponse sélectionnée pourrait être la solution permanente. Je voulais juste ajouter ceci pour référence future, car un redémarrage (pour que sysctl prenne effet) n'est pas toujours possible.

Une autre solution pourrait être de définir THP sur madvise ou never (voir le commentaire de poige sur sa réponse, Comment modifier "/sys/kernel/mm/transparent_hugepage/enabled" et le manuel MongoDB sur Désactiver les pages énormes transparentes (THP))

tâche cron

j'ai mis en place le lot suivant en tant que tâche cron comme solution "permanente" :

#!/bin/bash
# Rev 2: Utiliser ps à la place de top

## exécuté en tant que cron, donc pas de $PATH, donc besoin de définir tous les chemins absolus
cpu=$(/usr/bin/printf %.0f $(/bin/ps -o pcpu= -C kswapd0))

[[ -n $cpu ]] \
&& (( $cpu >= 90 )) \
&& echo 1 > /proc/sys/vm/drop_caches \
&& echo "$$ $0: cache dropped (kswapd0 %CPU=$cpu)" >&2 \
&& exit 1

exit 0

appelé à partir de root@localhost:~# crontab -e avec

# m h  dom mon dow   commande
  * *  *   *   *     /bin/bash /path/to/batch/drop_caches.sh >> /var/log/syslog 2>&1

Remarque : Le script de tâche cron ci-dessus a été adapté pour inclure la suggestion de Fredrik Erlandsson : une manière beaucoup plus simple et efficace de déterminer l'utilisation du CPU par kswapd0. Merci !

16.0414.04swap

Une solution plus permanente consiste à augmenter la taille de votre fichier d'échange.

kswapd prendra 100% du CPU lorsqu'il recherche un espace d'échange qui n'existe pas (si votre partition d'échange est pleine). htop affichera en haut de l'écran si votre espace d'échange est plein, ou vous pouvez utiliser la commande free -h pour vérifier l'espace d'échange utilisé.

Après avoir utilisé les commandes suivantes pour augmenter la taille de mon fichier d'échange de 4 Go à 8 Go, kswapd fonctionne désormais à 0% du CPU avec la swappiness réglée à 60*.

sudo swapoff /swapfile
sudo rm  /swapfile
sudo fallocate -l 8G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Cliquez ici pour une description plus détaillée de ces commandes

Cela suppose que vous utilisez déjà un fichier d'échange (configuration Ubuntu par défaut) et que le /swapfile est référencé dans /etc/fstab. De plus, la taille de votre fichier d'échange peut être plus grande ou plus petite en fonction de la quantité de RAM que vous avez, alors ajustez en conséquence.

_{* Il convient de noter que j'utilise un SSD donc les performances du disque ne posent pas de problème. Cependant, l'échange est presque toujours une bonne chose si vous manquez de RAM.}

Malware s'exécutant en tant qu'invité

Si vous avez déjà activé le compte invité d'Ubuntu et ensuite activé SSH, il se peut que des logiciels malveillants s'exécutent en utilisant votre compte invité.

sudo find /home -f kswapd0

Nous l'avons trouvé sous /home/guest/.configrc/

De nombreuses personnes constatent aujourd'hui cette question sur des machines qui n'ont pas besoin de swap, et voient que leur mémoire disponible est normale, pour ensuite découvrir qu'un logiciel de minage a été installé et s'exécute sous le compte invité, même automatiquement au démarrage.

Se connecter à n'importe quel réseau (conférence, café, ville) qui possède une machine compromise, ou utiliser un service comme ngrok, tout en ayant SSH ouvert sur votre système expose votre ordinateur à cette simple vulnérabilité d'invité.

Une entrée dédiée à ce problème se trouve ici : CPU 100% avec le processus kswapd0, même si aucun swap n'est nécessaire