Technologieaustausch

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Verweise:

①Verwenden Sie mtrace, um JVM-Off-Heap-Speicherlecks zu verfolgen

②Ein Fall zur Fehlerbehebung bei hoher Java-Speichernutzung

1. Untersuchungsideen

Ermitteln Sie den Speicherort des Speicherlecks (ausführliche Befehle finden Sie in den Referenzmaterialien ①).

1. Verwenden Sie jna, um mtrace im Java-Code zu aktivieren und die Speicherzuweisung zu verfolgen

2. Verwenden Sie den Befehl mtrace, um Protokolldateien zu analysieren und Speicherleck-Aufrufpunkte zu erhalten.

3. arthas überprüft den Aufrufstapel des Speicherleck-Aufrufpunkts (Sie können die Aufrufpunktadresse direkt verwenden, es ist kein Funktionsname erforderlich)

Erhalten Sie Speicherleckinhalte (ausführliche Befehle finden Sie in den Referenzmaterialien ②).

1. Führen Sie den Befehl pmap zum ersten Mal aus, um die Speichernutzung des Java-Prozesses zu ermitteln
2. Nach einiger Zeit erhöht sich der Speicher. Führen Sie den Befehl pmap erneut aus, um die Speichernutzung des Java-Prozesses zu ermitteln.
3. Verwenden Sie das Textvergleichstool, um die Ausgabe der beiden pmap-Befehle vorher und nachher zu vergleichen
4. Transkodieren Sie, um den Dateninhalt des neu hinzugefügten Speichers anzuzeigen

2. Case-Sharing

Wenn Sie einen Dienst offline testen und die QPS hoch ist, nimmt der vom nio.directbuffer-Bereich der Maschine belegte Speicher plötzlich zu, was zu OOM im Container führt.

Mithilfe der oben genannten Ideen zur Fehlerbehebung haben wir schließlich festgestellt, dass unser RPC-Framework eine große Datenmenge im Directbuffer-Bereich generiert hat. Tatsächlich ist bei hohem QPS die Anzahl der Selektor-Threads gering und die Verbrauchskapazität unzureichend, was zu einem Rückstand an Anforderungs- und Antwortdaten im Direktpufferbereich führt.