Comment savoir quel processus est à l'origine de l'utilisation de kswapd?

23

Je vois que kswapd utilise 100% de CPU ... comment puis-je savoir pour quel processus kswapd est tellement utilisé?

— Deshawn
source

1

Uhm. kswapd est le processus. Il s'exécute au nom du noyau.

— mailq

Voir serverfault.com/questions/24124/…

— PT

2

@mailq ... oui, mais cela n'échange-t-il pas la mémoire d'un espace utilisateur? et si oui, comment puis-je savoir quelle mémoire de processus il échange à ce moment-là?

— Deshawn

18

kswapd gère l'espace de swap en réponse à des demandes de mémoire supérieures à celles physiquement disponibles pour tous les processus.

Il est indépendant du processus, il ne s'intéresse qu'à quelles pages sont accessibles et quand (c'est plus complexe que cela bien sûr, mais pour garder les choses simples, nous pouvons aussi bien les voir de cette façon).

La vraie question est donc "quels processus ont le plus de fardeau sur la mémoire, ce qui fait que kswapd doit constamment paginer".

Il est plus facile de répondre à cette question en utilisant «top» et en passant en mode de tri d'utilisation de la mémoire.

— Paul
source

Merci!. Doe skswapd se déclenche-t-il UNIQUEMENT lorsque les pages réelles touchées dépassent le physique ou démarre-t-elle même si un processus a alloué la mémoire ou mappé la région SHM mais ne l'a pas utilisée? Autrement dit, est-ce uniquement lorsque le problème se produit ou fait-il de la tenue de livres et échange-t-il des choses même s'il y a de la mémoire physique disponible, mais simplement parce qu'un processus a été inactif, etc.?

— Deshawn

Si je comprends bien, kswapd supprimera dans des circonstances normales toutes les pages de la mémoire principale qui n'ont pas besoin d'être là, car toute page qui est libérée est une page qui peut être utilisée pour la mise en cache ou d'autres processus. C'est-à-dire qu'il vaut mieux avoir une vieille page inutilisée déjà sur le disque plutôt que d'engager le coût de la lenteur de la déplacer en réponse à une demande de mémoire d'un autre processus.

— Paul

Même si une machine a besoin d'utiliser beaucoup d'espace de swap, cela ne devrait pas prendre 100% de CPU pour le faire. Quelque chose est étrange.

— Zaz

@Zaz Ce n'est pas tant qu'il utilise la puissance de traitement du processeur pour effectuer des échanges, c'est que le processeur est utilisé à 100% en raison de l'IOWAIT. Chaque fois que la mémoire doit être permutée depuis le disque, le CPU doit rester là et l'attendre - IOWAIT, et ne fait rien d'autre (en moyenne).

— Paul

@Paul: Êtes-vous sûr? topme dit qu’aucun temps n’est consacré à l’attente des E / S et que près de 100% du temps est consacré au système. Plus d'informations: kswapd utilise souvent 100% CPU lorsque le swap est en cours d'utilisation

— Zaz

9

Vous pouvez l'écrire .. mais vous pouvez aussi le faire via le haut

Run top puis appuyez sur O puis sur p puis entrez

Maintenant, tous les processus sont triés par utilisation de swap et vous pouvez voir ceux qui l'utilisent

— Mike
source

2

O fait apparaître les options de filtrage pour moi, en appuyant sur p puis sur enter, il me manque «le délimiteur de filtre« inclut »est manquant»

— Shadow

@Shadow Même problème, voici une commande alternative unix.stackexchange.com/questions/128953/…

— Björn

8

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 temporaire:

sudo ln -s /dev/null /etc/udev/rules.d/40-vm-hotadd.rules
sudo reboot

Notez que cela désactivera l'ajout de RAM / CPU pour les machines virtuelles Xen et Hyper-V.

— Zenexer
source

Si cela venait de nulle part sur mon système sur Kubuntu 16.10 avec la solution de contournement déjà activée il y a quelque temps.

— Jeteon

@jeteon Plusieurs problèmes peuvent provoquer ce problème; cela se trouve être particulièrement courant.

— Zenexer

Ouais. J'ai trouvé que echo 3 > /proc/sys/vm/drop_cachescela l'atténue une fois qu'il commence à se produire. J'ai maintenant de manière préventive la commande sur un travail cron et cela semble aider, ou du moins limiter la durée du massacre OOM lorsque je suis loin de l'ordinateur.

— jeteon

6

Il semble également y avoir un bug kswapdquelque part, espérons-le uniquement sur les noyaux plus anciens.

Presque chaque jour maintenant, kswapd va sursauter au hasard sur certaines machines d'un plus gros cluster (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 swap aussi.

Rien n'explique encore pourquoi une machine particulière est touchée et une autre ne l'est pas. 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 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 frappe que si la machine n'est ni inactive ni très occupée.

Si le problème survient, rien ne sert plus. Tuer tous les processus (qui ne sont pas devenus impossibles à tuer), démonter tous les systèmes de fichiers, rien.kswapdreste toujours à 100% CPU. Je soupçonne une course de 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 affecté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 (encore) été affectées.
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.

— Tino
source

C'est historique. RedHat a confirmé: C'était un problème du noyau 2.6.18-194.el5 en combinaison avec le client NFS. Il a déjà été corrigé en 2012. Voir la réponse liée dans mon texte pour un peu plus d'informations. Si vous frappez cela aujourd'hui, c'est probablement une autre cause.

— Tino

1

C'est toujours un problème à certains endroits. J'en ai vu des tonnes surgir. ici , et voici quelques exemples.

— trueCamelType