Kubernetes und kswapd0 – ein böses Paar?

Question 1

Ein solches Verhalten von kswapd0 ist beabsichtigt und erklärbar.

Obwohl Sie die Auslagerungsdatei deaktiviert und entfernt und die Auslagerung auf Null gesetzt haben, behält kswapd den verfügbaren Speicher im Auge. Sie können damit fast den gesamten Speicher verbrauchen, ohne etwas unternehmen zu müssen. Sobald der verfügbare Speicher jedoch auf einen kritisch niedrigen Wert fällt (wenige Seiten für die Zone „Normal“ im /proc/zoneinfo, ~4000 4K-Seiten auf meinem Testserver), greift kswapd ein. Dies führt zu einer hohen CPU-Auslastung.

Sie können das Problem reproduzieren und es auf folgende Weise genauer untersuchen. Sie benötigen ein Tool, mit dem Sie Speicher auf kontrollierte Weise verbrauchen können, wie ein Skript, das von Roman Evstifeev angeboten wird:ramhog.py

Das Skript füllt den Speicher mit 100 MB großen Blöcken des ASCII-Codes von „Z“. Aus Gründen der Fairness des Experiments wird das Skript auf dem Kubernetes-Host und nicht im Pod gestartet, damit K8s nicht beteiligt sind. Dieses Skript sollte in Python3 ausgeführt werden. Es wird ein wenig geändert, um:

mit Python-Versionen vor 3.6 kompatibel sein;
Stellen Sie den Speicherzuweisungsblock kleiner als 4000 Speicherseiten ein (wenige Seiten für die Zone „Normal“ in /proc/zoneinfo; ich habe 10 MB eingestellt), damit die Verschlechterung der Systemleistung am Ende deutlicher sichtbar wird.

from time import sleep

print('Press ctrl-c to exit; Press Enter to hog 10MB more')

one = b'Z' * 1024 * 1024  # 1MB hog = []

while True:
    hog.append(one * 10)  # allocate 10MB
    free = ';\t'.join(open('/proc/meminfo').read().split('\n')[1:3])
    print("{}\tPress Enter to hog 10MB more".format(free), end='')
    input()
    sleep(0.1)

Sie können 3 Terminalverbindungen mit dem Testsystem herstellen, um zu beobachten, was passiert:

Führen Sie das Skript aus.
Führen Sie den Top-Befehl aus;
Holen Sie sich die /proc/zoneinfo

Führen Sie das Skript aus:

$ python3 ramhog.py

Nach einigen Eingaben der Eingabetaste (aufgrund der kleinen Speicherzuweisung, die wir festgelegt haben (10 MB)) werden Sie feststellen, dass

die MemAvailableLeistung wird niedrig und Ihr System reagiert immer weniger:ramhog.py-Ausgabe

Die kostenlosen Seiten fallen unter die Niedrigwassermarke:kostenlose Seiten

Folglich werden kswapd und die k8s-Prozesse aktiviert und die CPU-Auslastung steigt auf bis zu 100 %:Spitze

Beachten Sie, dass das Skript unabhängig von k8s ausgeführt wird und SWAP deaktiviert ist. Daher waren sowohl Kubernetes als auch kswapd0 zu Beginn des Tests im Leerlauf. Laufende Pods wurden nicht berührt. Trotzdem führt der durch die dritte Anwendung verursachte Mangel an verfügbarem Speicher mit der Zeit zu einer hohen CPU-Auslastung: nicht nur durch kswapd, sondern auch durch k8s. Das bedeutet, dass die Grundursache unzureichender Speicher ist, aber nicht k8s oder kswapd selbst.

/proc/meminfoWie Sie an den von Ihnen bereitgestellten Daten sehen können , MemAvailablewird der Wert ziemlich niedrig, was dazu führt, dass kswapd aktiviert wird. Bitte sehen Sie sich /proc/zoneinfoauch den Wert auf Ihrem Server an.

Tatsächlich liegt die Grundursache nicht im Konflikt oder in der Inkompatibilität zwischen k8s und kswap0, sondern im Widerspruch zwischen dem deaktivierten Swap und dem Speichermangel, der wiederum die Aktivierung von kswapd verursacht. Ein Systemneustart wird das Problem vorübergehend lösen, aber es wird dringend empfohlen, mehr RAM hinzuzufügen.

Eine gute Erklärung des kswapd-Verhaltens finden Sie hier: kswapd verwendet viele CPU-Zyklen

Answer

Ein solches Verhalten von kswapd0 ist beabsichtigt und erklärbar.

Obwohl Sie die Auslagerungsdatei deaktiviert und entfernt und die Auslagerung auf Null gesetzt haben, behält kswapd den verfügbaren Speicher im Auge. Sie können damit fast den gesamten Speicher verbrauchen, ohne etwas unternehmen zu müssen. Sobald der verfügbare Speicher jedoch auf einen kritisch niedrigen Wert fällt (wenige Seiten für die Zone „Normal“ im /proc/zoneinfo, ~4000 4K-Seiten auf meinem Testserver), greift kswapd ein. Dies führt zu einer hohen CPU-Auslastung.

Sie können das Problem reproduzieren und es auf folgende Weise genauer untersuchen. Sie benötigen ein Tool, mit dem Sie Speicher auf kontrollierte Weise verbrauchen können, wie ein Skript, das von Roman Evstifeev angeboten wird:ramhog.py

Das Skript füllt den Speicher mit 100 MB großen Blöcken des ASCII-Codes von „Z“. Aus Gründen der Fairness des Experiments wird das Skript auf dem Kubernetes-Host und nicht im Pod gestartet, damit K8s nicht beteiligt sind. Dieses Skript sollte in Python3 ausgeführt werden. Es wird ein wenig geändert, um:

mit Python-Versionen vor 3.6 kompatibel sein;
Stellen Sie den Speicherzuweisungsblock kleiner als 4000 Speicherseiten ein (wenige Seiten für die Zone „Normal“ in /proc/zoneinfo; ich habe 10 MB eingestellt), damit die Verschlechterung der Systemleistung am Ende deutlicher sichtbar wird.

from time import sleep

print('Press ctrl-c to exit; Press Enter to hog 10MB more')

one = b'Z' * 1024 * 1024  # 1MB hog = []

while True:
    hog.append(one * 10)  # allocate 10MB
    free = ';\t'.join(open('/proc/meminfo').read().split('\n')[1:3])
    print("{}\tPress Enter to hog 10MB more".format(free), end='')
    input()
    sleep(0.1)

Sie können 3 Terminalverbindungen mit dem Testsystem herstellen, um zu beobachten, was passiert:

Führen Sie das Skript aus.
Führen Sie den Top-Befehl aus;
Holen Sie sich die /proc/zoneinfo

Führen Sie das Skript aus:

$ python3 ramhog.py

Nach einigen Eingaben der Eingabetaste (aufgrund der kleinen Speicherzuweisung, die wir festgelegt haben (10 MB)) werden Sie feststellen, dass

die MemAvailableLeistung wird niedrig und Ihr System reagiert immer weniger:ramhog.py-Ausgabe

Die kostenlosen Seiten fallen unter die Niedrigwassermarke:kostenlose Seiten

Folglich werden kswapd und die k8s-Prozesse aktiviert und die CPU-Auslastung steigt auf bis zu 100 %:Spitze

Beachten Sie, dass das Skript unabhängig von k8s ausgeführt wird und SWAP deaktiviert ist. Daher waren sowohl Kubernetes als auch kswapd0 zu Beginn des Tests im Leerlauf. Laufende Pods wurden nicht berührt. Trotzdem führt der durch die dritte Anwendung verursachte Mangel an verfügbarem Speicher mit der Zeit zu einer hohen CPU-Auslastung: nicht nur durch kswapd, sondern auch durch k8s. Das bedeutet, dass die Grundursache unzureichender Speicher ist, aber nicht k8s oder kswapd selbst.

/proc/meminfoWie Sie an den von Ihnen bereitgestellten Daten sehen können , MemAvailablewird der Wert ziemlich niedrig, was dazu führt, dass kswapd aktiviert wird. Bitte sehen Sie sich /proc/zoneinfoauch den Wert auf Ihrem Server an.

Tatsächlich liegt die Grundursache nicht im Konflikt oder in der Inkompatibilität zwischen k8s und kswap0, sondern im Widerspruch zwischen dem deaktivierten Swap und dem Speichermangel, der wiederum die Aktivierung von kswapd verursacht. Ein Systemneustart wird das Problem vorübergehend lösen, aber es wird dringend empfohlen, mehr RAM hinzuzufügen.

Eine gute Erklärung des kswapd-Verhaltens finden Sie hier: kswapd verwendet viele CPU-Zyklen

Question 2

Kubernetes ermöglicht es uns, mit dem Parameter zu definieren, wie viel RAM wir für das Linux-System freihalten sollen evictionHard.memory.available. Dieser Parameter wird in einer ConfigMap namens festgelegt kubelet-config-1.XX. Wenn der RAM den von der Konfiguration zugelassenen Wert überschreitet, beginnt Kubernetes, Pods zu beenden, um deren Nutzung zu reduzieren.

In meinem Fall evictionHard.memory.availablewar der Parameter zu niedrig eingestellt (100Mi). Es ist also nicht genügend RAM-Speicherplatz für das Linux-System vorhanden, sodass kswapd0 Probleme macht, wenn der RAM-Speicher zu hoch ist.

Um den Anstieg von kswapd0 zu vermeiden, habe ich nach einigen Tests den evictionHard.memory.availableWert auf gesetzt 800Mi. Der kswapd0-Prozess hat keine Probleme mehr verursacht.

Answer

Kubernetes ermöglicht es uns, mit dem Parameter zu definieren, wie viel RAM wir für das Linux-System freihalten sollen evictionHard.memory.available. Dieser Parameter wird in einer ConfigMap namens festgelegt kubelet-config-1.XX. Wenn der RAM den von der Konfiguration zugelassenen Wert überschreitet, beginnt Kubernetes, Pods zu beenden, um deren Nutzung zu reduzieren.

In meinem Fall evictionHard.memory.availablewar der Parameter zu niedrig eingestellt (100Mi). Es ist also nicht genügend RAM-Speicherplatz für das Linux-System vorhanden, sodass kswapd0 Probleme macht, wenn der RAM-Speicher zu hoch ist.

Um den Anstieg von kswapd0 zu vermeiden, habe ich nach einigen Tests den evictionHard.memory.availableWert auf gesetzt 800Mi. Der kswapd0-Prozess hat keine Probleme mehr verursacht.

Kubernetes und kswapd0 – ein böses Paar?

Antwort1

Antwort2

verwandte Informationen