Como qualquer provedor adequado de serviços de informações, entendemos que o tempo de resposta do sistema é um fator muito importante para criar uma experiência positiva para o usuário. Além disso, a alta velocidade de operação possibilita o uso mais denso das capacidades do servidor e, portanto, reduz o custo de um data center.
Mas existe um "mas": nosso
CRM - SalesMax - é escrito em java e, portanto, ocorrem pausas associadas ao trabalho do coletor de lixo periodicamente. Até recentemente, esse era o mal inevitável que você tinha que suportar.
E assim, a Oracle anunciou um novo coletor de lixo - o ZGC. De acordo com anúncios preliminares, ele deveria resolver o problema de congelamentos de aplicativos java - as pausas declaradas não devem exceder 100 ms, mesmo em heap de vários gigabytes. Com nosso uso máximo de memória de 6 GB, tudo deve ficar bem.
Então, vamos começar.
Inclua a linha no standalone.conf do servidor de aplicativos wildfly
JAVA_OPTS="$JAVA_OPTS -XX:+UnlockExperimentalVMOptions -XX:+UseZGC"
Iniciamos o sistema, executamos testes de carga.
À primeira vista, tudo funciona como indicado, as pausas para a coleta de lixo realmente diminuíram.
Sem hesitar, foi decidido tentar um novo coletor de lixo em um dos servidores do produto. Escolhemos o menos carregado, configurado, lançado, começamos a observar.
No começo, tudo funcionou bem; em geral, eles decidiram que o experimento foi bem-sucedido.
E então, sábado à noite. Jogamos bilhar com calma, depois da meia-noite. Chamada do gerente: o CRM não funciona para o cliente.
Cheque - o cliente do mesmo servidor. Coloquei o telefone em minhas mãos, abro Termius, tento conectar-me ao servidor via ssh - silencio ... Pouco depois de cerca de 20 segundos, o que naquele momento parecia uma eternidade, mas ainda assim consegui entrar. E o que vemos? Apesar das restrições -Xmx6144M definidas nos parâmetros de inicialização, o processo java consumia toda a memória disponível. Depois de algum tempo, o sistema interrompeu completamente esse processo.
Portanto, o uso do ZGC teve que ser desativado. O trabalho do sistema de CRM imediatamente voltou ao normal. Parece que não há nada a fazer, vamos esperar até que tudo esteja concluído no Oracle.
Mas, depois de algum tempo,
um artigo chamou minha atenção em que o autor compartilhou a experiência positiva de usar outro coletor de lixo - Shenandoah, cujo desenvolvedor tinha exatamente os mesmos objetivos, a saber: reduzir o tempo que a fase de parada mundial leva no coletor de lixo.
Decidimos: por que não?
Tendo encontrado a página da qual você pode baixar o JDK pré-compilado -
https://builds.shipilev.net/ , começamos a testar: adicionamos novas chaves ao standalone.conf:
JAVA_OPTS="$JAVA_OPTS -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC"
Desta vez, os testes mostraram que tudo, em geral, está OK. E as pausas para coleta de lixo foram reduzidas e, o melhor de tudo, o aumento imprevisível no consumo de memória foi interrompido. Tudo funciona perfeitamente na produção.
Que conclusões podem ser tiradas? Entendo que a Oracle também está em desenvolvimento, e as dificuldades que encontramos em outubro de 2019 já podem ter sido corrigidas e o ZGC em breve terá uma segunda chance. Mas, no momento, pessoalmente, escolhemos o Shenandoah GC e não nos arrependemos.