web-dev-qa-db-fra.com

kswapd0 prend beaucoup de cpu

kswapd0 prend 99,9% de mon processeur comme le montre le mieux, le problème est apparu aujourd'hui lorsque je jouais et que c'était la première fois qu'il disparaissait après 6 minutes et que cela dure depuis environ 20 minutes. Comment cela est-il réparable et quelle en est la cause?

kernelswap
40
Kaspar

Le processus kswapd0 est le processus qui gère la mémoire virtuelle. Votre machine devrait disposer de la RAM, du SWAP et de l’extension EXT4 de votre disque dur/SSD. L'ext4 est l'endroit où tout est stocké, et l'accès est toujours plus lent que la RAM. RAM est comme un espace intermédiaire permettant aux programmes d'accéder rapidement aux informations. La plupart des ordinateurs ont au moins 4 Go de RAM, ce qui est suffisant dans des conditions normales. Cependant, lorsque vous jouez à un jeu, vous pouvez manquer d’espace RAM, où SWAP entre en jeu.

SWAP est un faux RAM situé sur votre disque dur/SSD à côté de votre EXT4. Il est plus rapide d’accéder que le EXT4, mais il est beaucoup plus lent que la RAM réelle. Lorsque vous manquez de mémoire, kswapd0 déplace les programmes que vous n'utilisez pas/n'utilisez pas autant que les autres programmes dans le SWAP, ce qui entraîne un retard extrême sur ces processus. Si votre jeu avait besoin de 5 Go de RAM, 1 Go au moins serait en SWAP. Cela signifie que lorsqu'il tente d'accéder à cette information, il doit attendre plus longtemps avant de l'obtenir.

Tout ce processus entraîne une utilisation extrême du processeur, le déplacement des informations de et vers SWAP et RAM et le traitement de la demande d'informations en même temps. Comment résoudre ce problème?

  1. Dites à kswapd0 de ne déplacer des éléments dans SWAP que lorsque vous êtes complètement à court de RAM. C’est la méthode la plus efficace pour résoudre les problèmes SWAP. Courir

    echo vm.swappiness=0 | Sudo tee -a /etc/sysctl.conf

    où 0 est le pourcentage restant de 100 auquel SWAP doit être utilisé (lorsque vous avez 0% RAM, il commence à collecter des données). Vous pouvez aussi simplement éditer /etc/sysctl.conf à votre convenance au lieu d’ajouter cette commande à la fin de celle-ci à chaque fois en utilisant gedit ou nano ou autre, assurez-vous de choisir Sudo, ce fichier est la propriété de la racine. Redémarrez et vous êtes prêt!

  2. Réduisez la consommation de RAM par d'autres processus ou fermez d'autres programmes lors de l'exécution de programmes à mémoire vive. C'est pourquoi la plupart des jeux vous demandent de fermer toutes les autres fenêtres avant de jouer, ou les installations font de même. Les services de synchronisation de fichiers, par exemple, nécessitent généralement beaucoup de mémoire.
  3. Achetez plus de RAM. L'installation de RAM n'est pas aussi difficile que ça en a l'air. Une ou deux vis sur un petit compartiment (si vous êtes sur un ordinateur portable) et un simple clic. Assurez-vous simplement que vous achetez le bon type!
  4. Abaissez les processus du processeur comme vous le faisiez avec la RAM. Cela aidera ces RAM à permuter les rafales à se rendre beaucoup plus fluide.

C'est le mieux que vous puissiez faire. D'autres peuvent dire de désactiver complètement l'échange, mais c'est dangereux et je ne le recommanderais PAS. Cela peut provoquer le gel de systèmes entiers en cas de fuite de mémoire ou de trop d'applications en cours d'exécution. Il suffit de se rendre compte que le SWAP est un fail-safe pour la RAM. Ce n'est certainement pas aussi rapide et efficace que la RAM, mais c'est mieux que le fichier Page de Windows! (qui accomplit le même but)

EDIT: Si vous souhaitez en savoir plus sur SWAP, voir ici .

37
Zzzach...

kswapd0 fonctionne à 99,9% d'un processeur, mais n'échange pas du tout

Pour moi, cela arrive parfois sur Ubuntu 14.04 avec le noyau 3.19.0-50-generic (et antérieur) s'exécutant dans une machine virtuelle VMware. Je n'ai aucune idée de ce qui l'a fait apparaître, mais cela vient pendant les temps morts.

top indique:

# top
top - 09:49:35 up 5 days, 18:35,  1 user,  load average: 1.00, 1.00, 0.99
Tasks: 219 total,   2 running, 217 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us, 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 used,  1154316 free,  1010276 buffers
KiB Swap: 15624188 total,     3032 used, 15621156 free.   234928 cached Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    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.

en suivant la réponse sur serverfault (kswapd utilise souvent 100% de la CPU lorsque swap est utilisé) où se trouvaient les mêmes paramètres 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 réalité # echo 1 > /proc/sys/vm/drop_caches :

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

maintenant c'est bon:

# top
top - 10:08:58 up 5 days, 18:55,  1 user,  load average: 0.72, 0.95, 0.98
Tasks: 220 total,   1 running, 219 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  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 used,  2347080 free,     2916 buffers
KiB Swap: 15624188 total,     3032 used, 15621156 free.    81924 cached Mem

   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
     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 comme la raison réelle n’est pas encore connue et que je n’ai pas trouvé d’explications appropriées sur le net, ce n’est pas une solution permanente. En fait, le réponse sélectionné pourrait être la solution permanente. Je voulais juste ajouter ceci pour référence future, car un redémarrage (pour que sysctl prenne effet) ne soit pas toujours possible.

Une autre solution pourrait être de définir THP sur madvice ou never (voir poige's comment to his answer , Comment modifier "/ sys/kernel/mm/transparent_hugepage/enabled ” et le manuel MongoDB référencé sur désactiver les pages transparentes énormes (THP) )

cron

j'ai configuré le lot suivant en tant que tâche cron en tant que solution "permanente":

#!/bin/bash


## run as cron, thus no $PATH, thus need to define all absolute paths
top=/usr/bin/top
grep=/bin/grep


top=$($top -bn1 -o \%CPU -u0 | $grep -m2 -E "%CPU|kswapd0")

IFS='
'
set -f

i=0

for line in $top
do
        #echo $i $line

        if ! (( i++ ))
        then
                pos=${line%%%CPU*}
                pos=${#pos}
                #echo $pos
        else
                cpu=${line:(($pos-1)):3}
                cpu=${cpu// /}
                #echo $cpu
        fi

done

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

exit 0

invoqué avec

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

16.0414.04échange

26
Martin Rüegg