Lösung 1:
kswapd verwaltet Auslagerungsspeicher als Reaktion auf Speicheranforderungen, die größer sind, als physisch für alle verfügbar sind Prozesse.
Es ist prozessunabhängig, es interessiert sich nur dafür, auf welche Seiten zugegriffen wird und wann (es ist natürlich komplexer, aber um die Dinge einfach zu halten, können wir es genauso gut so sehen).
Also die echte Die Frage lautet:"Welche Prozesse belasten den Speicher am meisten, was dazu führt, dass kswapd die ganze Zeit blättern muss".
Das lässt sich am einfachsten mit 'top' beantworten und in den Sortiermodus für die Speichernutzung wechseln.
Lösung 2:
Sie können es skripten, aber Sie können es auch über top
tunStarte oben und drücke dann O gefolgt von p dann eingeben
Jetzt sind alle Prozesse nach Swap-Verwendung sortiert und Sie können sehen, welche ihn verwenden
Lösung 3:
Wenn Sie Ubuntu 15.10 oder höher verwenden, kann dies tatsächlich das Ergebnis eines Fehlers sein, insbesondere wenn Ihr System eine virtuelle Maschine ohne Swap-Partition ist (z. B. AWS EC2). Das Problem tritt auch bei anderen Distributionen auf, aber zum jetzigen Zeitpunkt ist unklar, ob derselbe Fix universell funktioniert.
Eine vorübergehende Problemumgehung:
sudo ln -s /dev/null /etc/udev/rules.d/40-vm-hotadd.rules
sudo reboot
Beachten Sie, dass dadurch das Hotadding von RAM/CPUs für virtuelle Xen- und Hyper-V-Maschinen deaktiviert wird.
Lösung 4:
Es scheint auch einen Fehler in kswapd
zu geben irgendwo, hoffentlich nur auf älteren Kerneln.
Fast jeden Tag geht kswapd zufällig auf einigen Maschinen in einem größeren Cluster (allerdings mit einem nicht aktuellen Kernel) durch. 100 % CPU auf beiden kswapd-Prozessen. Keine anderen laufenden Prozesse (außer ssh-Shell), viel freier RAM (mehr als 700 MB) und überhaupt kein SWAP verwendet. Kein Tauschen, auch kein Tauschen.
Nichts erklärt noch, warum eine bestimmte Maschine getroffen wird und eine andere nicht. Es scheint nicht völlig zufällig zu sein, da es normalerweise innerhalb kurzer Zeit mehr als eine Maschine trifft. Es sieht so aus, als ob Maschinen, die im Leerlauf sind, sowie Maschinen, die unter Hochdruck stehen, weniger (!) von dem Effekt betroffen sind. Es hat also etwas mit der Auslastung zu tun und schlägt nur zu, wenn die Maschine weder im Leerlauf noch sehr beschäftigt ist.
Wenn das Problem auftritt, hilft nichts mehr. Alle Prozesse beenden (die nicht unkillbar wurden), alle Dateisysteme aushängen, nichts. kswapd
bleibt immer noch bei 100% CPU. Ich vermute ein Spinlock-Rennen in SMP-Kerneln, aber es ist auch wahrscheinlich, dass ich falsch liege.
Siehe vielleicht meine Antwort serverfault.com/questions/316995/#493257
Hinweise:
- Das Neustarten betroffener Rechner schlägt oft fehl, weil der Herunterfahrvorgang irgendwo hängen bleibt.
- Es besteht keine direkte Verbindung zum Internet. Fremde Ursachen sind unwahrscheinlich.
- Es scheint von der Art der Arbeitslast abzuhängen, die die Maschinen aus Sicht einer Last verarbeiten, da wir Maschinen haben, die (noch) nie betroffen waren.
- Tut mir leid, ich kann nicht genauer sagen, was wir tun und warum.
- Ja, ich spekuliere. Weil es heute ein äußerst rätselhafter Effekt ist.