1. Use o plano de fundo Druida
Depois que a transformação do produto de microsserviço da empresa foi online, o pool de conexão padrão HikariCP do springboot foi usado no ambiente de desenvolvimento. Por que o HikariCP foi escolhido após o springboot 2.0?
Na verdade, em uma palavra, HikariCP tem o mais alto desempenho e pode pk todos os outros pools de conexão;
depois de realizarmos testes de estresse no produto, descobrimos que o programa frequentemente travava na obtenção de conexões de banco de dados. Depois de verificar a base de produtos da empresa, o tamanho do pool de conexões não foi ajustado. O padrão é um máximo de 8 conexões. O pool de conexões de banco de dados Druid de Ali e ativou o monitoramento, descobriu que é realmente perfumado; em termos de comparação de desempenho, o Druid ainda é
possível
.
O principal é que o monitoramento é realmente bom. Com base na poderosa função de monitoramento do Druid, é benéfico para o trabalho diário de desenvolvimento e monitoramento online de operação e manutenção. Ao mesmo tempo, o monitoramento pode ser personalizado e estendido com base na interface;
2. Surgimento e análise de problemas
1. Quando ocorrer um problema, confirme rapidamente o tipo de problema
Alguns dias após o lançamento de um determinado serviço na nuvem, foi relatado que o cartão estava lento e fora do ar, e vários nós do cluster tiveram problemas um após o outro pela manhã;
Comunique-se imediatamente com os colegas de operação e manutenção para confirmar se a memória jvm do aplicativo está normal e a carga da instância do banco de dados correspondente ao serviço está normal. O fenômeno do problema é que alguns nós estão normais e alguns não nós não estão normais. Confirma-se imediatamente que há um nó com problema naquele momento. O lado do aplicativo está bloqueado;
O tipo de problema, a lentidão do cartão nada mais é do que o estouro de memória JVM do aplicativo, a carga do banco de dados é alta, o thread do aplicativo está bloqueado e vários vazamentos de recursos (como vazamentos de conexão redis, vazamentos de pool de conexão de banco de dados), etc.
2. Pegue o log para analisar o problema
Analisando o log no momento do problema, você descobrirá que muitas solicitações ficarão travadas na obtenção da conexão do pool de conexões do Druid. Isso precisa ser refletido, ou as conexões no pool são usadas para executar o SQL ou as conexões no pool vazam;
Como julgar a conexão para executar o sql?
Encontre o relacionado ao mysql no instantâneo do thread, obtenha a conexão do pool de conexão, é claro, execute o sql.
Conforme mostrado na figura abaixo, existem pouquíssimos SQLs sendo executados, então não é um vazamento?
Como julgar o vazamento de conexão?
Combinando com a arquitetura técnica, exceto que o Druid irá para a conexão no pool, a possibilidade de tomar o local de negócios deve ser extremamente pequena; pelo contrário, se for um vazamento de conexão, por que ainda existem 8 conexões que não vazaram de acordo com a figura acima (em um caso, apenas 8 conexões vazaram e o sql executado por essas 8 conexões é mais lento ou as solicitações simultâneas são maiores, o que pode ser confirmado); naquele momento, foi determinado diretamente que não havia vazamento de conexão e, em seguida, uma etapa análise de instantâneo de encadeamento passo a
passo
;
Uma análise mais aprofundada descobriu que há solicitações que serão bloqueadas no seguinte bloqueio esperando para bloquear <0x00000006c69c35f8> (um java.lang.Object) ao obter a conexão do pool de conexão Druid Base.loadClass() está preso na classe de carregamento do carregador de classes
? Por que está preso? Eu não consigo entender. . . Fiquei atordoado por alguns minutos;
Então alterei um instantâneo da thread para visualizar, conforme a imagem abaixo, basicamente o cartão está lento. Carregue a classe no mesmo local. Verifique se a classe carregada aqui é com.mysql.jdbc.MysqlIO e depois confirme se o cartão está lento. Procure por com.mysql.jdbc.MysqlIO no serviço de downtime. Não existe essa classe
.
;
3. Verificação
O problema é confirmado que o Druid carrega a classe inexistente com.mysql.jdbc.MysqlIO, o que faz com que o classload verifique todo o disco e carregue o diretório da classe, resultando em espera de bloqueio e bloqueio de thread; como verificar o problema de loadclass lento
?
Escreva uma demonstração, carregue reflexivamente uma classe inexistente e carregue reflexivamente uma classe existente;
pode-se comparar claramente que o carregamento de uma classe inexistente pode levar dezenas de ms (relacionado ao número de pacotes jar);
por que com.mysql.jdbc.MysqlIO não existe neste serviço?
Este nome de pacote pertence ao pacote do driver mysql. Verifique se a versão 8.0 superior do driver é usada no projeto e não existe; em seguida, vá para maven para
consultar as diferentes versões do pacote do driver mysql e confirme se o pacote do driver mysql não existe após a versão inferior 6;
Quatro, resolva
Puxe a versão correspondente do código-fonte do Druid, simplesmente observe o código-fonte do druid e comente o loadclass de acordo com o seguinte processamento. Se não estiver carregado, tudo bem; então um pacote jar, druid-weaver
.
solução fundamental
上述直接 调整源码注释掉loadclass的逻辑，可以解决性能问题，但是某种情况下会导致获取链接不稳定。
根本解决方案是 升级版本到 druid-1.1.23
我们对比下源码：
1.1.22
1.1.23
Cinco, acompanhamento
Depois disso, o serviço não caiu devido ao druid e funcionou de forma estável. Como temos mais de 200 nós de serviço online, alguns serviços de negócios de alta simultaneidade também apresentam problemas. Foi confirmado que o mesmo problema tem um impacto maior;
6. Sugestões para usar parâmetros individuais do Druida
test-on-borrow = true, é recomendável desativá-lo online, o que realmente consome desempenho. Em nosso ambiente de produção online, temos estatísticas de monitoramento para obter o druid para obter a detecção de conexão. Basicamente, cada verificação leva alguns milissegundos e uma solicitação executa centenas de SQL, que são centenas de milissegundos. É recomendável desativá-lo para false; em seguida, ative test-while-idle = true para evitar falhas de conexão e cenários problemáticos
;