Docker View JVM-Speichernutzung

1. Rufen Sie den Hostcomputer des Docker-Containers auf und zeigen Sie die Container-ID an, auf der das angegebene Image ausgeführt wird (erste Spalte des Ergebnisses):

docker ps | grep meinBildname (oder docker ps | grep java)

2. Geben Sie den Container ein:

docker exec -it Container-ID sh

3. Geben Sie den obersten Befehl direkt ein:

Spitze

Sie können die grundlegenden Informationen zur Containernutzung sehen: PID, VSZ, CPU, Befehl usw. (Strg+C oder Q, oben beenden)

4. Zeigen Sie die spezifischere JVM-Speichernutzung an:

oben -m

Darunter gibt vsz: Virtual Memory Size, die Größe des virtuellen Speichers, den gesamten Speicher an, auf den der Prozess zugreifen kann, einschließlich ausgelagertem Speicher und gemeinsam genutztem Bibliotheksspeicher.

rss: Resident Set Size, Größe des residenten Speichersatzes, gibt an, wie viel Speicher der Prozess im RAM belegt, und schließt den im SWAP belegten virtuellen Speicher nicht ein. Sogar die Speichergröße der gemeinsam genutzten Bibliotheken im Arbeitsspeicher wird berücksichtigt, einschließlich des gesamten Speichers im Stack und Heap.

SHR: gemeinsam genutzter Speicher, gemeinsam genutzter Speicher.

Auffüllen:

ps -ef | grep java oder docker top container id, um einige Informationen zur PID anzuzeigen.

ps aux | grep java.

oben -p pid.

RSS ist die Resident Set Size, die die dem Prozess zugewiesene Speichergröße angibt.

RSS umfasst keinen Speicher, der in Swap-Partitionen geht.

RSS berücksichtigt den von gemeinsam genutzten Bibliotheken belegten Speicher (sofern sich die gemeinsam genutzten Bibliotheken im Speicher befinden)

RSS umfasst den gesamten zugewiesenen Stapelspeicher und Heap-Speicher.

VSZ stellt den vom Prozess zugewiesenen virtuellen Speicher dar.

VSZ umfasst den gesamten für den Prozess zugänglichen Speicher, einschließlich des Swap-Speichers und des von gemeinsam genutzten Bibliotheken belegten Speichers.

VSZRW: Ich habe die genaue Bedeutung bei Baidu nicht gefunden, aber ich vermute, es ist die Größe des ursprünglich angeforderten virtuellen Speichers.

Docker-Statistik-Containername oder Docker-Statistik-Container-ID, die Ergebnisse sind wie folgt:

CONTAINER CPU % SPEICHERNUTZUNG / LIMIT SPEICHER % NET I/O BLOCK I/O PIDS
 

Ergänzung: JVM-Parameter-Tuning unter Docker-Containerisierung

1. JVM-Heapspeichereinstellungen

Der im Docker-Container ausgeführte Java-Dienst hat mehrere Speicherüberlauf-Ausnahmen erlebt. Tatsächlich hat dies viel mit der Docker-Containerisierung des Java-Programms zu tun. Java und Docker sind keine natürlichen Freunde. Docker kann Speicher- und CPU-Grenzen festlegen, die durch die Linux-Cgroup-Technologie auf der untersten Ebene implementiert werden, aber Java JVM kann sie nicht automatisch erkennen.

Wir können dieses Problem lösen, indem wir das Xmx-Flag von Java verwenden, um die Größe des Heap-Speichers manuell anzugeben, oder indem wir das JVM-Flag verwenden, das von einer höheren Version des JDK bereitgestellt wird.

Frage:

Bei älteren Versionen von Java 8 (Versionen vor Update 131) entsprechen der verfügbare Speicher und die CPU-Anzahl der JVM nicht dem verfügbaren Speicher und der CPU-Anzahl, die Docker Ihnen zur Nutzung zulässt.

Beispielsweise ist der Docker-Container auf 1 GB begrenzt, aber die alte Version von Java kann diese Begrenzung nicht erkennen. Wenn das Geschäft wächst, beantragt die JVM mehr Speicher, der diese Begrenzung möglicherweise weit überschreitet. Wenn jedoch zu viel Speicher verwendet wird, greift Docker ein und beendet den Java-Prozess im Container, was wir natürlich nicht wollen!

Derzeit verwendet unsere Produktionsumgebung Java 8. Dieses Problem kann gelöst werden, indem die Heap-Speichergröße über -Xmx begrenzt wird. Allerdings gibt es hier tatsächlich zwei Grenzen, eine ist die Speichergrenze des Docker-Containers und die andere ist die Grenze des JVM-Heap-Speichers.

Lösung:

Diese Prämisse erfordert die Dockerfile-Unterstützung des Java-Programms:

# Ursprüngliches Image VON adoptopenjdk/openjdk8
# Der Name des JAR-Pakets muss in Projektname-Versionsnummer geändert werden, wobei app.jar unverändert bleibt. ADD example-sun-1.0.jar app.jar
# JVM-Startparameter konfigurieren ENV JVM_ARGS=${JVM_ARGS}
EXPOSE 8080
# Optimieren Sie die JVM-Parameterkonfiguration, um ENTRYPOINT java zu starten ${JVM_ARGS} -Djava.security.egd=file:/dev/./urandom -jar app.jar

Fügen Sie insbesondere der Umgebungsvariablen env in der Bereitstellungsdatei k8s deployment.yaml die folgenden Parameter hinzu. Diese werden dann beim Start der JVM geladen.

- Name: JVM_ARGS
 Wert: -Xmx1024m -Xms512m

Xmx1024m #Legen Sie den Maximalwert des JVM-Heapspeichers fest

-Xms512m #Legen Sie den Mindestwert des JVM-Heapspeichers fest

Hier ist der minimale Heap-Speicher auf 512 m und der maximale Speicher auf 1024 m eingestellt. Wenn Sie den Heap-Speicher anpassen, erhöhen Sie ihn nicht einfach. Analysieren Sie sorgfältig die Gründe für die übermäßige Speichernutzung und ob Codeprobleme vorliegen.

JVMs mit höheren Versionen von Java 9 (8u131+) bieten eine bessere Lösung

JVM-Flags verwenden: -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap

Erzwingen Sie, dass JVM die Cgroup-Konfiguration von Linux überprüft. Tatsächlich verwendet Docker die Cgroup-Technologie von Linux, um Containerressourcen wie Speicher zu begrenzen. Wenn die Anwendung nun das von Docker festgelegte Limit (z. B. 1 G) erreicht, kann die JVM dieses Limit erkennen und versucht, GC-Vorgänge durchzuführen.

Wenn das Speicherlimit nach GC immer noch überschritten wird, führt die JVM das aus, was sie tun soll, z. B. eine OutOfMemoryException. Mit anderen Worten, die JVM kann diese Einstellungen von Docker erkennen.

2. GC-Protokolldruck und automatischer OOM-Dump

Während das Programm läuft, können Sie zur Erleichterung der Fehlerbehebung auch GC-Protokolle drucken. Gleichzeitig können Sie bei einer Java OutOfMemory-Ausnahme den Heap-Speicher sichern, um die Fehlerbehebung zu erleichtern. Legen Sie die folgenden Parameter fest:

- Name: JVM_ARGS
 Wert: -Xmx1536m -Xms512m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/logs/my-heap-dump.hprof -Xloggc:/logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps

Bedeutung der Parameter:

# Speicherdatei automatisch sichern, wenn ein Speicherüberlauf auftritt -XX:+HeapDumpOnOutOfMemoryError
############### Geben Sie die Dump-Dateiadresse als Dienst-Druckprotokollordner/-protokolle an (gemountet).
-XX:HeapDumpPath=/logs/mein-heap-dump.hprof
############### Dienst-GC-Protokoll drucken - Xloggc:/logs/gc.log
# Detailliertes GC-Protokoll ausgeben -XX:+PrintGCDetails
# Formatieren Sie den Ausgabezeitstempel 2020-09-17T19:45:05.680+0800
-XX:+DruckeGCDatumsstempel

Das Obige ist meine persönliche Erfahrung. Ich hoffe, es kann Ihnen als Referenz dienen. Ich hoffe auch, dass Sie 123WORDPRESS.COM unterstützen werden. Sollten dennoch Fehler oder unvollständige Überlegungen vorliegen, freue ich mich über eine Korrektur.