Ausführliche Erläuterung der Optimierung der Garbage Collection für geschäftskritische Java-Anwendungen (Teil 1)

Kürzlich hatte ich die Gelegenheit, mehrere Java-basierte Einkaufs- und Portalanwendungen zu testen und zu optimieren, die auf Sun/Oracle JVM laufen. Die meistbesuchten Apps gibt es in Deutschland. In vielen Fällen ist die Garbage Collection ein entscheidender Faktor für die Leistung von Java-Servern. In diesem Artikel werden wir einige fortgeschrittene Ideen für Garbage-Collection-Algorithmen und einige wichtige Anpassungsparameter untersuchen. Wir vergleichen diese Parameter in verschiedenen realen Szenarien.

Aus Sicht der Garbage Collection können Java-Serverprogramme eine Vielzahl von Anforderungen haben:

1. Einige Anwendungen mit hohem Datenverkehr müssen auf eine große Anzahl reagieren von Anfragen und erstellen Sie sehr viele Objekte. Manchmal tritt bei einigen Anwendungen mit mittlerem Datenverkehr, die Frameworks mit hohem Ressourcenverbrauch verwenden, das gleiche Problem auf. Kurz gesagt, die effektive Bereinigung dieser generierten Objekte stellt eine große Herausforderung für die Speicherbereinigung dar.

2. Darüber hinaus müssen einige Anwendungen über einen langen Zeitraum laufen und während des Betriebs stabile Dienste bereitstellen, sodass die Leistung nicht im Laufe der Zeit langsam oder plötzlich nachlässt.

3. Einige Szenarien erfordern strenge Beschränkungen der Benutzerreaktionszeit (z. B. Online-Spiele oder Wettanwendungen) und es sind fast keine zusätzlichen GC-Pausen zulässig.

In vielen Szenarien können Sie mehrere Anforderungen mit unterschiedlichen Prioritäten kombinieren. Mehrere meiner Beispielprogramme stellen für den ersten Punkt deutlich höhere Anforderungen als für den zweiten Punkt, die meisten Programme stellen jedoch nicht für alle drei Aspekte gleichzeitig hohe Anforderungen. Dadurch bleibt Ihnen viel Spielraum für Kompromisse.

Leistung von JVM GC unter Standardkonfiguration

JVM hat viele Verbesserungen, aber es kann immer noch keine Aufgaben optimieren, während das Programm ausgeführt wird. Zusätzlich zu den drei oben genannten Punkten haben die Standard-JVM-Einstellungen noch eine weitere Priorität: die Reduzierung der Speichernutzung. Bedenken Sie, dass Tausende von Benutzern nicht auf Servern mit ausreichend Speicher arbeiten. Dies ist auch für viele E-Commerce-Produkte wichtig, da diese Anwendungen so konfiguriert sind, dass sie die meiste Zeit auf Entwicklungslaptops und nicht auf Standardservern ausgeführt werden. Wenn Ihr Server daher mit den minimalen Heap-Speicherplatz- und GC-Parametern konfiguriert ist, wie z. B. der folgenden Konfiguration,

java -Xmx1024m -XX:MaxPermSize=256m -cp Portal.jar my.portal.Portal

führt dies definitiv dazu, dass das System ineffizient läuft. Erstens empfiehlt es sich, nicht nur das maximale Speicherlimit, sondern auch die anfängliche Speichergröße zu konfigurieren, um zu vermeiden, dass der Server während des Startvorgangs den Speicher schrittweise erhöht. Sonst wird es sehr kostspielig. Wenn Sie wissen, wie viel Speicher Ihr Server benötigt (und das sollten Sie rechtzeitig herausfinden), ist es am besten, die anfängliche Speichergröße gleich der maximalen Speichereinstellung festzulegen. Es kann über die folgenden JVM-Parameter eingestellt werden:

-Xms1024m -XX:PermSize=256m

Die letzte grundlegende Option, die häufig in der JVM konfiguriert wird, ist die Konfiguration der Heap-Speichergröße der neuen Generation, ähnlich wie oben festgelegt:

-XX:NewSize=200m -XX:MaxNewSize=200m

In den folgenden Abschnitten werden die obige Konfiguration sowie komplexere Konfigurationen erläutert. Schauen wir uns zunächst eine Portalanwendung an, die auf einem recht langsamen Testhost läuft. Wie funktioniert die Speicherbereinigung bei Lasttests:

Abbildung 1 GC-Verhalten von JVM mit leicht optimierter Heap-Größe in etwa 25 Stunden (-Xms1024m - Xmx1024m -XX: NewSize=200m -XX:MaxNewSize=200m)

Darunter stellt die blaue Kurve die Änderung der gesamten Heap-Speichernutzung im Laufe der Zeit dar, und die vertikale graue Linie stellt das GC-Pausenintervall dar.

Zusätzlich zur Grafik werden ganz rechts Schlüsselindikatoren und die Leistung der GC-Operationen angezeigt. Schauen wir uns zunächst die durchschnittliche Menge an Müll an, die während dieses Tests erzeugt (und gesammelt) wird. Der Wert von 30,5 MB/s ist gelb markiert, da es sich hierbei um eine beträchtliche, aber akzeptable Müllerzeugungsrate handelt, die für ein einführendes GC-Tuning-Beispiel in Ordnung ist. Andere Werte geben die Leistung der JVM bei der Bereinigung dieses Mülls an: 99,55 % des Mülls werden in der neuen Generation gereinigt, in der alten Generation sind es nur 0,45 %. Dieses Ergebnis ist ziemlich gut, daher ist es grün markiert.

Der Grund für ein solches Ergebnis ist aus dem von GC eingeführten Pausenintervall (und dem Arbeitsthread, der Benutzeranfragen verarbeitet) ersichtlich: Es gibt viele, aber sehr kurze GC-Intervalle der neuen Generation, im Durchschnitt alle 6 Sekunden. und die Dauer wird nicht länger als 50 ms dauern. Diese Pausen stoppten die JVM für 0,77 % der Gesamtzeit, aber jede Pause war für den Benutzer, der auf eine Antwort des Servers wartete, völlig unmerklich.

Andererseits machen GC-Pausen der alten Generation nur 0,19 % der Gesamtzeit aus. Allerdings hat der GC der alten Generation in diesem Zeitraum nur 0,45 % des Mülls gereinigt, während der GC der neuen Generation 0,77 % der Zeit benötigte, um 99,55 % des Mülls zu reinigen. Es ist ersichtlich, wie ineffizient der GC der alten Generation im Vergleich zum GC der neuen Generation ist. Darüber hinaus beträgt die durchschnittliche Auslöserate von GC-Pausen der alten Generation weniger als einmal pro Stunde, die durchschnittliche Dauer kann jedoch 8 Sekunden erreichen, und der maximale Ausreißer erreicht sogar 19 Sekunden. Da diese Pausen die Verarbeitung von Benutzeranfragen durch die Threads der JVM tatsächlich stoppen, sollten Pausen so selten wie möglich und von kurzer Dauer sein.

Anhand der obigen Beobachtungen können wir die grundlegenden Optimierungsziele der Generationen-Garbage Collection ableiten:

• Der GC der neuen Generation sollte so viel Müll wie möglich sammeln, um häufige und zu vermeiden häufiger GC in der alten Generation. Kürzere Dauer.

分代垃圾回收的基本思想与堆内存大小调整

先从下图开始。这个图可以通过JDK工具得到，比如jstat或者jvisualvm以及它的visualgc插件：

图2 JVM的堆内存结构，包括新生代的子分区（最左列）

Java的堆内存由永久代（Perm），老年代（Old）和新生代（New or Young）组成。新生代进一步划分为一个Eden空间和两个Survivor空间S0、S1。Eden空间是对象被创建时的地方，经过几轮新生代GC后，他们有可能被存放在Survivor空间。如果想了解更多，可以读一下Sun/Oracle的白皮书Memory Management in the Java HotSpot Virtual Machine

默认情况下，作为整体的新生代特别是Survivor空间太小，导致在GC清理大部分内存之前就无法保存更多对象。因此，这些对象被过早地保存在老年代中，这会导致老年代被迅速填满，必须频繁地清理垃圾。这也是图1中产生较多的Full GC暂停的原因。

（译者注：一般新生代的垃圾回收也称为Minor GC，老年代的垃圾回收称为Major GC或Full GC）

优化新生代内存大小

优化分代垃圾回收意味着让新生代，特别是Survivor空间，比默认情形大。但是同时也要考虑虚拟机使用的具体GC算法。

当前硬件上运行的Sun/Oracle虚拟机使用了ParallelGC作为默认GC算法。如果使用的不是默认算法，可以通过显式配置JVM参数来实现：

-XX:+UseParallelGC

默认情况下，这个算法并不在固定大小的Eden和Survivor空间中运行。它使用了一种自适应调整大小的策略，称为“AdaptiveSizePolicy”策略。正如描述的那样，它可以适应很多场景，包括服务器以外的机器的使用。但在服务器上运行时，这并不是最优策略。为了可以显式地设置固定的Survivor空间大小，可以通过以下JVM参数关闭它：

-XX:-UseAdaptiveSizePolicy

一旦这么设置后，就不能进一步增加新生代空间的大小，但我们可以有效地为Survivor空间设置合适的大小：

-XX:NewSize=400m -XX:MaxNewSize=400m -XX:SurvivorRatio=6

“SurvivorRatio=6”表示Survivor空间是Eden空间的1/6或者是整个新生代空间的1/8，在这个例子中就是50MB，而自适应大小策略经常运行在非常小的空间上，大约只有几MB。使用现在的配置，重复上面的负载测试，我们得到了下面的结果：

图3 堆内存优化后的JVM在50小时内的GC行为（-Xms1024m -Xmx1024m -XX:NewSize=400m -XX:MaxNewSize=400m -XX:-UseAdapativeSizePolicy -XX:SurvivorRatio=6）

这次的测试时间是上次的两倍，而垃圾的平均创建速率和之前基本一致（30.2MB/s，之前是30.5MB/s）。然而，整个过程只有两次老年代（Full）GC暂停，25小时左右才发生一次。这是因为老年代垃圾死亡速率（所谓的promation rate）从137kB/s减小到了6kB/s，老年代的垃圾回收只占整体的0.02%。同时新生代GC的暂停持续时间仅仅从平均48ms增加到57ms，两次暂停的间隔从6s增长到10s。总之，关闭了自适应大小调整，合理地优化堆内存大小，使GC暂停占总时间的比例从0.95%减小到0.59%，这是一个非常棒的结果。

优化后，使用ParNew算法作为默认ParallelGC的替代，也能得到相似的结果。这个算法是为了与CMS算法兼容而开发的，可以通过JVM参数来配置-XX:+UseParNewGC。关于CMS下面会提到。这个算法不使用自适应大小策略，可以运行在固定Survivor大小的空间上。因此，即使使用默认的配置SurvivorRatio=8，也比ParallelGC拥有更高的服务器利用率。

避免老年代GC的长时间暂停

上述结果的最后一个问题就是，老年代GC的长时间暂停平均为8s左右。通过适当的优化，老年代GC暂停已经很少了，但是一旦触发，对用户来说还是很烦人的。因为在暂停期间，JVM不能执行工作线程。在我们的例子中，8s的长度是由低速老旧的测试机导致的，在现代硬件上速度能快3倍左右。另一方面，现在的应用一般使用1G以上的堆内存，可以容纳更多的对象。当前的网络应用使用的堆内存能达到64GB，（至少）需要一半的内存来保存存活的对象。在这种情况下，8s对老年代暂停来说是很短的。这些应用中的老年代GC可以很随意地就接近1分钟，对于交互式网络应用来说是绝对不能接受的。

缓解这个问题的一个选择就是采用并行的方式处理老年代GC。默认情况下，在Java 6中，ParallelGC和ParNew GC算法使用多个GC线程来处理新生代GC，而老年代GC是单线程的。以ParallelGC回收器为例，可以在使用时添加以下参数：

-XX:+UseParallelOldGC

从Java 7开始，这个选项和-XX:+UseParallelGC默认被激活。但是，即使你的系统是4核或8核，也不要期望性能可以提高2倍以上。通常的结果会比2被小一些。在某些例子中，比如上述例子中的8s，这种提高还是比较有效的。但在很多极端的例子中，这还远远不够。解决方法是使用低延迟GC算法。

下篇中会讨论CMS（The Concurrent Mark and Sweep Collector）、幽灵般的碎片、G1（Garbage First）垃圾收集器和垃圾收集器的量化比较，最后给出总结。

Das obige ist der detaillierte Inhalt vonAusführliche Erläuterung der Optimierung der Garbage Collection für geschäftskritische Java-Anwendungen (Teil 1). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!