Como cualquier proveedor adecuado de servicios de información, entendemos que el tiempo de respuesta del sistema es un factor muy importante para crear una experiencia de usuario positiva. Además, la alta velocidad de operación permite utilizar las capacidades del servidor de manera más densa y, por lo tanto, reduce el costo de un centro de datos.
Pero, hay un "pero": nuestro
CRM - SalesMax - está escrito en Java, y, por lo tanto, las pausas asociadas con el trabajo del recolector de basura ocurren periódicamente. Hasta hace poco, este era el mal inevitable que solo tenías que soportar.
Y así, Oracle anunció un nuevo recolector de basura: ZGC. Según los anuncios preliminares, se suponía que debía resolver el problema de la congelación de las aplicaciones de Java: las pausas declaradas no deberían superar los 100 ms, incluso en montones de varios gigabytes. Con nuestro uso máximo de memoria de 6GB, todo debería estar bien.
Entonces comencemos.
Agregue la línea al standalone.conf del servidor de aplicaciones wildfly
JAVA_OPTS="$JAVA_OPTS -XX:+UnlockExperimentalVMOptions -XX:+UseZGC"
Iniciamos el sistema, ejecutamos pruebas de carga.
A primera vista, todo funciona como se indica, las pausas para la recolección de basura realmente disminuyeron.
Sin dudarlo, se decidió probar un nuevo recolector de basura en uno de los servidores del producto. Elegimos el menos cargado, configurado, lanzado, comenzó a observar.
Al principio, todo funcionó bien, en general, decidieron que el experimento fue exitoso.
Y así, el sábado por la noche. Jugamos tranquilamente al billar, después de la medianoche. Llamada del gerente: CRM no funciona para el cliente.
Comprobar: el cliente del mismo servidor. Puse el teléfono en mis manos, abrí Termius, traté de conectarme al servidor a través de ssh - silencio ... Un poco apenas, después de unos 20 segundos, que en ese momento parecía una eternidad, pero aún así logré entrar. Y que vemos A pesar de las restricciones -Xmx6144M establecidas en los parámetros de inicio, el proceso de Java utilizó toda la memoria disponible. Después de un tiempo, el sistema eliminó por completo este proceso.
Entonces, el uso de ZGC tuvo que ser deshabilitado. El trabajo del sistema CRM volvió inmediatamente a la normalidad. Parece que no hay nada que hacer, esperaremos hasta que todo esté terminado en Oracle.
Pero, después de un tiempo, me
llamó la atención
un artículo en el que el autor compartió la experiencia positiva de usar otro recolector de basura: Shenandoah, cuyo desarrollador tenía exactamente los mismos objetivos, a saber: reducir el tiempo que la etapa de detener la fase mundial lleva en el recolector de basura.
Decidimos: ¿por qué no?
Después de encontrar la página desde la que puede descargar el JDK precompilado -
https://builds.shipilev.net/ , comenzamos a probar: agregamos nuevas claves a standalone.conf:
JAVA_OPTS="$JAVA_OPTS -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC"
Esta vez, las pruebas mostraron que todo, en general, está bien. Y se redujeron las pausas para la recolección de basura y, lo mejor de todo, se detuvo el aumento impredecible del consumo de memoria. Todo funciona perfectamente en la producción.
¿Qué conclusiones se pueden sacar? Entiendo que Oracle también se está desarrollando, y las dificultades que encontramos en octubre de 2019 pueden haber sido solucionadas, y ZGC pronto tendrá una segunda oportunidad. Pero en este momento, personalmente, elegimos Shenandoah GC, y no nos arrepentimos.