Wie bei jedem geeigneten Anbieter von Informationsdiensten verstehen wir, dass die Reaktionszeit des Systems ein sehr wichtiger Faktor für eine positive Benutzererfahrung ist. Darüber hinaus können durch die hohe Betriebsgeschwindigkeit die Serverkapazitäten verdichtet und damit die Kosten für ein Rechenzentrum gesenkt werden.
Aber es gibt ein „Aber“: Unser
CRM - SalesMax - ist in Java geschrieben, und daher treten regelmäßig Pausen auf, die mit der Arbeit des Müllsammlers verbunden sind. Bis vor kurzem war dies das unvermeidliche Übel, mit dem Sie sich abfinden mussten.
Und so kündigte Oracle einen neuen Garbage Collector an - ZGC. Nach vorläufigen Ankündigungen sollte er das Problem des Einfrierens von Java-Anwendungen lösen - deklarierte Pausen sollten 100 ms nicht überschreiten, selbst auf Multi-Gigabyte-Haufen. Mit unserer maximalen Speicherauslastung von 6 GB sollte alles in Ordnung sein.
Also fangen wir an.
Fügen Sie die Zeile zur standalone.conf des Wildfly-Anwendungsservers hinzu
JAVA_OPTS="$JAVA_OPTS -XX:+UnlockExperimentalVMOptions -XX:+UseZGC"
Wir starten das System und führen Belastungstests durch.
Auf den ersten Blick funktioniert alles wie angegeben, die Pausen für die Müllabfuhr haben sich wirklich verringert.
Ohne zu zögern wurde beschlossen, einen neuen Garbage Collector auf einem der Produktserver zu testen. Wir wählten die am wenigsten belasteten, konfigurierten, gestarteten, zu beobachtenden.
Zuerst hat alles gut geklappt, im Allgemeinen haben sie entschieden, dass das Experiment erfolgreich war.
Und so, Samstag Nacht. Wir spielen ruhig Billard, Zeit nach Mitternacht. Anruf vom Manager: CRM funktioniert für den Kunden nicht.
Überprüfen Sie - der Client vom gleichen Server. Ich lege das Telefon in meine Hände, öffne Termius, versuche, eine Verbindung zum Server über SSH-Stille herzustellen ... Etwas knapp, nach ungefähr 20 Sekunden, was in diesem Moment wie eine Ewigkeit schien, aber ich konnte trotzdem eintreten. Und was sehen wir? Trotz der Einschränkungen von -Xmx6144M, die in den Startparametern festgelegt wurden, hat der Java-Prozess den gesamten verfügbaren Speicher belegt. Nach einiger Zeit hat das System diesen Vorgang vollständig abgebrochen.
Daher musste die Verwendung von ZGC deaktiviert werden. Die Arbeit des CRM-Systems hat sich sofort normalisiert. Anscheinend gibt es nichts zu tun, wir werden warten, bis in Oracle alles fertig ist.
Aber nach einiger Zeit
fiel mir
ein Artikel auf, in dem der Autor die positiven Erfahrungen mit einem anderen Müllsammler teilte - Shenandoah, dessen Entwickler genau die gleichen Ziele verfolgte, nämlich die Zeit zu verkürzen, die die Weltphase für den Müllsammler benötigt.
Wir haben uns entschieden: warum nicht?
Nachdem wir die Seite gefunden haben, von der Sie das vorkompilierte JDK herunterladen können -
https://builds.shipilev.net/ , haben wir mit dem Testen begonnen: Wir fügen der standalone.conf neue Schlüssel hinzu:
JAVA_OPTS="$JAVA_OPTS -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC"
Diesmal haben Tests gezeigt, dass im Allgemeinen alles in Ordnung ist. Und die Pausen für die Speicherbereinigung wurden verkürzt, und vor allem der unvorhersehbare Anstieg des Speicherverbrauchs wurde gestoppt. In der Produktion funktioniert einfach alles perfekt.
Welche Schlussfolgerungen können gezogen werden? Ich verstehe, dass sich auch Oracle weiterentwickelt und die Schwierigkeiten, auf die wir im Oktober 2019 gestoßen sind, möglicherweise bereits behoben wurden. ZGC wird demnächst eine zweite Chance eingeräumt. Aber im Moment haben wir uns persönlich für Shenandoah GC entschieden und es nicht bereut.