Der Java-Haufen schrumpft weiter! Was passiert in diesem Diagramm der Heap-Größe?

Question

Dies ist ein Screenshot einer JVM (win64, 6u17), auf der ActiveMQ läuft. Nach jeder Garbage Collection verringert sich die Heapgröße. Je kleiner der Heap ist, desto häufiger wird die Garbage Collection durchgeführt und desto schneller wird der Heap verkleinert. Schließlich kommt die VM zum Stillstand, da sie ihre gesamte Zeit mit GC verbringt.

-Xms ist der Standard und -Xmx beträgt 2048mb.

Was passiert da? Wie kann ich das vermeiden?

http://imagebin.org/92614

Schrumpfende Halde http://imagebin.org/index.php?mode=image&id=92614

n.b ursprünglich auf serverfault.com gepostet, auf Wunsch nach stackoverflow.com verschoben

Answer 1

Es gibt ein JVM-Argument, das steuert, wann die Größe des Heaps geändert wird.

-XX:MaxHeapFreeRatio

Der Standardwert hierfür ist 70. Der freie Anteil ist die Menge des nicht zugewiesenen Platzes auf dem Heap im Verhältnis zur Gesamtgröße des Heaps. Steigt der Prozentsatz des freien Platzes über den Standardwert von 70 %, wird der JVM die Größe des Heaps reduzieren, damit das Betriebssystem den Speicher nutzen kann.

Wenn der Heap zu oft schrumpft, können Sie den Wert von -XX:MaxHeapFreeRatio erhöhen. Wenn dieser Wert auf 100 gesetzt wird, wird er vermutlich nie schrumpfen.

Answer 2

Bei Google fand ich folgendes, aus der IBM JVM FAQ (wie wäre es mit einem NLA):

Wann schrumpft der Java-Heap?

Heap-Shrinkage tritt auf, wenn GC feststellt, dass viel freier Heap-Speicher vorhanden ist und die Freigabe von Heap-Speicher der Systemleistung zugute kommt. Heap-Shrinkage findet nach der GC statt, aber wenn alle Threads noch in der Schwebe sind.

Die Sun JVM funktioniert ähnlich. Im Folgenden finden Sie einen Auszug aus einem Artikel des Oracle Technology Network mit dem Titel Ergonomie in der virtuellen Java-Maschine 5.0 .

Der Heap wächst oder schrumpft auf eine Größe, die dem gewählten Durchsatzziel entspricht. Einige Schwankungen in der Größe des Heaps während der Initialisierung und während einer Änderung im Verhalten der Anwendung können erwartet werden.

...

Es ist typisch, dass die Größe des Heaps schwankt, wenn der Garbage Collector versucht, konkurrierende Ziele zu erfüllen. Dies gilt selbst dann, wenn die Anwendung einen stabilen Zustand erreicht hat. Der Druck, ein Durchsatzziel zu erreichen (was einen größeren Heap erfordern kann), konkurriert mit den Zielen einer maximalen Pausenzeit und eines minimalen Platzbedarfs (die beide einen kleinen Heap erfordern können).

Ich schlage vor, dass Sie sich den Rest des Dokuments ansehen; vielleicht finden Sie dort weitere Informationen, die für Ihr Problem relevant sind.

Answer 3

Nur eine Vermutung: Es sieht so aus, als ob das System so gut wie im Leerlauf ist. Es könnte eine Zwischenspeicherung stattfinden, und Dinge fallen aus dem Cache und werden gc'd. Oder, da es sich um ein Warteschlangensystem handelt, hat es vielleicht einige Nachrichten in der Warteschlange, die langsam zugestellt werden und danach gc'd werden.

Die zunehmende Häufigkeit der gc-Läufe könnte auf eine immer geringere Belastung des Systems zurückzuführen sein.

Wie man sie vermeiden kann. Warum wollen Sie es vermeiden? Es scheint, dass Ihre CPU-Last gleich Null ist. Es steht Ihnen also frei, die CPU tun zu lassen, was sie will.