Comme tout fournisseur de services d'information adéquat, nous comprenons que le temps de réponse du système est un facteur très important pour créer une expérience utilisateur positive. De plus, la grande vitesse de fonctionnement permet d'utiliser plus densément les capacités des serveurs et donc de réduire le coût d'un data center.
Mais, il y a un «mais»: notre
CRM - SalesMax - est écrit en java, et, par conséquent, des pauses associées au travail du garbage collector se produisent périodiquement. Jusqu'à récemment, c'était le mal inévitable que vous aviez à supporter.
Et donc, Oracle a annoncé un nouveau garbage collector - ZGC. Selon des annonces préliminaires, il était censé résoudre le problème des blocages d'application Java - les pauses déclarées ne devraient pas dépasser 100 ms même sur des tas de plusieurs gigaoctets. Avec notre utilisation maximale de 6 Go de mémoire, tout devrait bien se passer.
Commençons donc.
Ajoutez la ligne au standalone.conf du serveur d'applications wildfly
JAVA_OPTS="$JAVA_OPTS -XX:+UnlockExperimentalVMOptions -XX:+UseZGC"
Nous démarrons le système, exécutons des tests de charge.
À première vue, tout fonctionne comme indiqué, les pauses pour la collecte des ordures ont vraiment diminué.
Sans hésitation, il a été décidé d'essayer un nouveau garbage collector sur l'un des serveurs de produits. Nous avons choisi le moins chargé, configuré, lancé, a commencé à observer.
Au début, tout fonctionnait bien, en général, ils ont décidé que l'expérience était réussie.
Et donc, samedi soir. Nous jouons calmement au billard, après minuit. Appel du gestionnaire: CRM ne fonctionne pas pour le client.
Vérifier - le client du même serveur. J'ai mis le téléphone entre mes mains, ouvert Termius, essayé de me connecter au serveur via ssh - silence ... Un peu à peine, après environ 20 secondes, ce qui à ce moment semblait être une éternité, mais j'ai quand même réussi à entrer. Et que voyons-nous? Malgré les restrictions -Xmx6144M définies dans les paramètres de démarrage, le processus java a utilisé toute la mémoire disponible. Après un certain temps, le système a complètement interrompu ce processus.
Donc, l'utilisation de ZGC a dû être désactivée. Le travail du système CRM est immédiatement revenu à la normale. Il semblerait qu'il n'y ait rien à faire, nous attendrons que tout soit terminé dans Oracle.
Mais, après un certain temps,
un article a attiré mon attention dans lequel l'auteur a partagé l'expérience positive de l'utilisation d'un autre garbage collector - Shenandoah, dont le développeur avait exactement les mêmes objectifs, à savoir: réduire le temps que prend la phase d'arrêt de la phase mondiale dans le garbage collector.
Nous avons décidé: pourquoi pas?
Après avoir trouvé la page à partir de laquelle vous pouvez télécharger le JDK précompilé -
https://builds.shipilev.net/ , nous avons commencé les tests: nous ajoutons de nouvelles clés à standalone.conf:
JAVA_OPTS="$JAVA_OPTS -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC"
Cette fois, les tests ont montré que tout, en général, est OK. Et les pauses pour la collecte des ordures ont été réduites et, surtout, l'augmentation imprévisible de la consommation de mémoire s'est arrêtée. Tout fonctionne parfaitement en production.
Quelles conclusions peut-on en tirer? Je comprends qu'Oracle se développe également, et les difficultés que nous avons rencontrées en octobre 2019 ont peut-être déjà été corrigées, et ZGC aura bientôt une deuxième chance. Mais pour le moment, personnellement, nous avons choisi Shenandoah GC, et nous ne l'avons pas regretté.