O problema de hoje me incomodou e não sei quantas noites. Para resolver esse problema, minha equipe e eu passamos muito tempo, mas no final valeu a pena!
No início, o problema não era: A conexão não está disponível, a solicitação expirou após 5000 ms. Naquela época, nosso pool de conexão de banco de dados ainda era C3P0, descobri que algumas execuções de SQL de negócios também eram muito lentas, 90% do SQL estaria em 10 ms Interno (não SQL lento), mas de vez em quando sempre haverá alguma execução que leva milhares de milissegundos. Os fenômenos acima são todos observados com precisão.
Depois de pensar sobre isso, acho que pode ser porque o pool de conexão é muito antigo. Verifiquei o java. Ele usa pools de conexão cada vez mais populares, como c3p0, dbcp, druid e hikaricp. Também vi uma comparação deles na Internet. C3P0 é de fato De jeito nenhum, hikaricp é o melhor. Acontece que a unidade também está empurrando hikaric, então mudamos para hikaricp. Achei que o problema deveria ser resolvido, mas não ajudou. Depois de abrir pinpint, ainda é o mesmo
O execute () ainda é executado por um longo tempo, mas há uma diferença. O Pinpoint não rastreia o método getConnection () ao usar C3P0. Desta vez, há um método getConnection () adicional e às vezes o tempo de getConnection pode ser muito longo. No final das contas, é um método que tem um tempo de execução curto, um é que o tempo de execução é relativamente longo e o outro é que o tempo de getConnection é relativamente longo.
Como essa falta de caixa no início não teve nenhum impacto no negócio, nenhuma outra investigação foi feita posteriormente. Mas com o passar do tempo, novos problemas foram produzidos, e o log começou a relatar alguns erros de banco de dados, que eram os mesmos do título:
org.springframework.jdbc.CannotGetJdbcConnectionException: Não foi possível obter a conexão JDBC; a exceção aninhada é java.sql.SQLTransientConnectionException: XXPool - A conexão não está disponível, a solicitação expirou após 5000 ms.
a execução do sql relatou um erro, isso. . . Isso começou a afetar o negócio. Não aguento mais, continue a verificar. Jogue com precisão para ver:
Correspondendo ao log, mais tarde esse erro tornou-se cada vez mais. Demos uma olhada na configuração do pool de conexão
Chegue à conclusão: a conexão no pool de conexões não é suficiente, porque atingiu o tempo limite devido à espera pela conexão, e também está certo com o método getConnection () que eu disse acima (há também um consumo execute () insolúvel duração).
Começamos a pensar em maneiras de verificar nossas conclusões. Ao acessar o hikaricp, armazenamos alguns dos dados do pool de conexão do hikaricp na biblioteca através de Monitoramento MBean (JMX) , Conexão Inativa, Conexões Ativas, Conexão Total, Conexão em Espera. Através da observação de dados, não encontramos Também há muitos Waitting e Idle. Não parece que o pool de conexão está cheio. Será um vazamento de conexão? Adicionamos o parâmetro do pool de conexão vazDetectionThreshold para observar. Foi constatado que não houve vazamento de conexão, mas desta vez através do log, encontramos um novo erro:
O surgimento do problema de conexão está morto, vamos fazer uma série de reflexões! ! ! Por que está morto?
Como as conexões buscadas do pool de conexões estão inativas e todas as conexões () demoram muito, examinamos o código-fonte. Ao buscar a conexão, o hikaripc testará a conexão, portanto, adicionamos configuração ao pool de conexões.
Os parâmetros são muito grandes e o novo erro está aqui novamente: java.sql.SQLTimeoutException: ORA-01013: o usuário solicitou o cancelamento da operação atual
Eu verifiquei ORA-01013 online, e a explicação foi causada principalmente por bloqueios de tabela. Eu perguntei ao meu velho amigo Ping An oracle Daniel e me perguntei se há um problema de bloqueio de tabela, e a fixação de tabela causará esse problema, mas este problema é verdadeiro Não necessariamente causado por bloqueios de mesa, acontece que não são bloqueios de mesa, haha. Naquela época, procurei por dba e não encontrei a tabela de bloqueio.
Se eu não jogar, eu realmente não posso verificar mais. Já se passaram quase duas semanas desde que eu verifiquei. Eu tenho algumas versões e não posso mais jogar. Cresça! Desta vez, reunimos todos os figurões em 5 campos de dba, middleware, host, rede e operação e manutenção, e convocamos Shenlong. É realmente uma conclusão de que há muita gente e poder: há um grande atraso na inscrição no banco de dados!
O resto da história não será o caso, basta trocar a placa de rede, cabo de rede, etc. . . Resolvido o problema de atraso, desta vez o problema foi realmente resolvido!
Aqui está um resumo: software é uma coisa complexa e a tecnologia aplicada é ainda mais extensa. Como desenvolvedor, o pensamento e a habilidade técnica podem ficar apenas na camada de aplicativo.Nunca pensei que pensaria para baixo (fora) e haverá problemas na camada de rede ou hardware. Isso também apresenta altas demandas em nossa tecnologia de desenvolvimento.
Além disso, não há realmente nada a temer quando há um problema (bug). Depois que o problema for resolvido, o conhecimento e o crescimento que o bug traz para você serão um valor futuro.
Por fim, agradeço minha equipe e colegas. Vamos trabalhar muito juntos no futuro! Trabalhe duro, independente do resultado . Eu também espero que este artigo seja útil para todos.