Java verwendet viel mehr Speicher als Heap-Größe (oder Größe korrekt Docker-Speicherlimit)

Virtueller Speicher, der von einem Java Prozess verwendet wird, geht weit über nur Java Heap hinaus. Sie wissen, JVM enthält viele Untersysteme: Garbage Collector, Class Loading, JIT-Compiler usw. , und all diese Subsysteme benötigen eine bestimmte Menge von RAM, um zu funktionieren.

JVM ist nicht der einzige RAM-Konsument. Native Bibliotheken (einschließlich der Standard-Klassenbibliothek Java)) können auch nativen Speicher zuweisen. Dies ist für die native Speicherüberwachung nicht sichtbar. Java) kann von der Anwendung selbst ausgeführt werden Verwenden Sie auch Off-Heap-Speicher mithilfe von direkten ByteBuffers.

Also, was braucht Speicher in einem Java Prozess?

JVM-Teile (meistens von Native Memory Tracking gezeigt)

1. Java Heap

   Der offensichtlichste Teil. Hier leben Java Objekte. Heap belegt bis zu -Xmx Speicher.

2. Müllsammler

   GC-Strukturen und -Algorithmen erfordern zusätzlichen Speicher für das Heap-Management. Diese Strukturen sind Mark Bitmap, Mark Stack (zum Durchlaufen von Objektgraphen), Remembered Sets (zum Aufzeichnen von Interregion-Referenzen) und andere. Einige von ihnen sind direkt einstellbar, z. -XX:MarkStackSizeMax, Andere hängen vom Heap-Layout ab, z. Je größer die G1-Regionen (-XX:G1HeapRegionSize) sind, desto kleiner sind die gespeicherten Mengen.

   Der Overhead des GC-Speichers variiert zwischen den GC-Algorithmen. -XX:+UseSerialGC Und -XX:+UseShenandoahGC Haben den geringsten Overhead. G1 oder CMS können leicht etwa 10% der gesamten Heap-Größe verwenden.

3. Code-Cache

   Enthält dynamisch generierten Code: JIT-kompilierte Methoden, Interpreter und Laufzeitstubs. Seine Größe ist begrenzt durch -XX:ReservedCodeCacheSize (Standardmäßig 240M). Deaktivieren Sie -XX:-TieredCompilation, Um die Menge des kompilierten Codes und damit die Nutzung des Code-Cache zu reduzieren.

4. Compiler

   Der JIT-Compiler selbst benötigt auch Speicher, um seine Arbeit zu erledigen. Dies kann durch Ausschalten von Tiered Compilation oder durch Reduzieren der Anzahl der Compiler-Threads wieder reduziert werden: -XX:CICompilerCount.

5. Laden der Klasse

   Klassenmetadaten (Methodenbytecodes, Symbole, Konstantenpools, Anmerkungen usw.) werden im Off-Heap-Bereich namens Metaspace gespeichert. Je mehr Klassen geladen sind, desto mehr Metaspace wird verwendet. Die Gesamtnutzung kann durch -XX:MaxMetaspaceSize (Standardmäßig unbegrenzt) und -XX:CompressedClassSpaceSize (Standardmäßig 1 GB) begrenzt werden.

6. Symboltabellen

   Zwei Haupt-Hashtabellen der JVM: Die Symbol-Tabelle enthält Namen, Signaturen, Bezeichner usw. und die String-Tabelle enthält Verweise auf internierte Strings. Wenn Native Memory Tracking eine signifikante Speichernutzung durch eine String-Tabelle anzeigt, bedeutet dies wahrscheinlich, dass die Anwendung übermäßig String.intern Aufruft.

7. Themen

   Thread-Stapel sind auch für die Entnahme des Arbeitsspeichers verantwortlich. Die Stapelgröße wird durch -Xss Gesteuert. Der Standard ist 1M pro Thread, aber zum Glück sind die Dinge nicht so schlimm. Das Betriebssystem weist Speicherseiten träge zu, d. H. Bei der ersten Verwendung, sodass die tatsächliche Speichernutzung viel geringer ist (normalerweise 80 bis 200 KB pro Threadstapel). Ich habe ein Skript geschrieben, um zu schätzen, wie viel RSS zu Java Thread-Stacks) gehört.

   Es gibt andere JVM-Teile, die nativen Speicher zuordnen, die jedoch normalerweise keine große Rolle für den Gesamtspeicherbedarf spielen.

Direkte Puffer

Eine Anwendung kann explizit Off-Heap-Speicher anfordern, indem sie ByteBuffer.allocateDirect Aufruft. Das Standard-Off-Heap-Limit ist gleich -Xmx, Kann aber mit -XX:MaxDirectMemorySize Überschrieben werden. Direkte ByteBuffer sind im Abschnitt Other der NMT-Ausgabe (oder Internal vor JDK 11) enthalten.

Die Menge des verwendeten Direktspeichers ist durch JMX sichtbar, z. in JConsole oder Java Mission Control:

Neben direkten Byte-Puffern kann es MappedByteBuffers geben - die Dateien, die dem virtuellen Speicher eines Prozesses zugeordnet sind. NMT verfolgt sie nicht, MappedByteBuffers können jedoch auch physischen Speicher belegen. Und es gibt keine einfache Möglichkeit, die Einnahme einzuschränken. Sie können die tatsächliche Verwendung einfach anhand der Prozessspeicherzuordnung sehen: pmap -x <pid>

Address           Kbytes    RSS    Dirty Mode  Mapping
...
00007f2b3e557000   39592   32956       0 r--s- some-file-17405-Index.db
00007f2b40c01000   39600   33092       0 r--s- some-file-17404-Index.db
                           ^^^^^               ^^^^^^^^^^^^^^^^^^^^^^^^

Native Bibliotheken

JNI-Code, der mit System.loadLibrary Geladen wurde, kann so viel Speicher außerhalb des Heapspeichers reservieren, wie er möchte, ohne dass die JVM-Seite dies steuert. Dies betrifft auch die Standardklassenbibliothek Java). Insbesondere nicht geschlossene Ressourcen Java) können zu einem systemeigenen Speicherverlust führen. Typische Beispiele sind ZipInputStream oder DirectoryStream.

JVMTI-Agenten, insbesondere der Debugging-Agent jdwp, können ebenfalls einen übermäßigen Speicherverbrauch verursachen.

Diese Antwort beschreibt, wie native Speicherzuordnungen mit async-profiler profiliert werden.

Allocator-Probleme

Ein Prozess fordert normalerweise systemeigenen Speicher entweder direkt vom Betriebssystem an (durch mmap Systemaufruf) oder mithilfe von malloc - Standard-libc-Zuweisung. Im Gegenzug fordert malloc mit mmap große Speicherblöcke vom Betriebssystem an und verwaltet diese Blöcke dann gemäß seinem eigenen Zuordnungsalgorithmus. Das Problem ist - dieser Algorithmus kann zu Fragmentierung führen und übermäßige Nutzung des virtuellen Speichers .

jemalloc , ein alternativer Allokator, erscheint häufig schlauer als die reguläre libc malloc, sodass ein Wechsel zu jemalloc zu einem geringeren Platzbedarf führen kann.

Fazit

Es gibt keine garantierte Möglichkeit, die vollständige Speichernutzung eines Java) - Prozesses abzuschätzen, da zu viele Faktoren zu berücksichtigen sind.

Total memory = Heap + Code Cache + Metaspace + Symbol tables +
               Other JVM structures + Thread stacks +
               Direct buffers + Mapped files +
               Native Libraries + Malloc overhead + ...

Es ist möglich, bestimmte Speicherbereiche (wie den Code-Cache) durch JVM-Flags zu verkleinern oder einzuschränken, aber viele andere befinden sich überhaupt außerhalb der JVM-Kontrolle.

Ein möglicher Ansatz zum Festlegen von Docker-Grenzwerten wäre, die tatsächliche Speichernutzung in einem "normalen" Zustand des Prozesses zu beobachten. Es gibt Tools und Techniken zur Untersuchung von Problemen mit Java Speicherverbrauch: Native Memory Tracking , pmap , jemalloc , Async-Profiler .