Veja a imagem anexa do Fusion Reactor, mostrando páginas que continuam funcionando. Os tempos subiram para milhões e deixei-os para ver se completavam, mas isso foi quando eram apenas 2 ou 3.
Agora estou recebendo dezenas de páginas que nunca terminam. E são consultas diferentes, não consigo ver nenhum padrão enorme, exceto que parece se aplicar apenas a 3 dos meus 7 bancos de dados.
topmostrafusão a frioO uso da CPU em torno de 70-120%, e se aprofundar nas páginas de detalhes do Fusion Reactor, mostra que todo o tempo de construção é gasto exclusivamente em consultas Mysql.
show processlistnão retorna nada incomum, exceto 10 a 20 conexões emdormirestado.
Durante esse período, muitas páginas são concluídas, mas à medida que o número de páginas suspensas aumenta e elas parecem nunca terminar, o servidor eventualmente retorna apenas páginas em branco.
A única solução a curto prazo parece ser reiniciar o Coldfusion, o que está longe de ser o ideal.
Foi adicionado recentemente um script Node.js que é executado a cada 5 minutos e verifica se há arquivos CSV em lote para processar. Eu me perguntei se isso estava causando um problema com o roubo de todas as conexões MySQL, então desativei isso (o script não tem connection.end () nele), mas isso é apenas um palpite rápido.
Não faço ideia por onde começar, alguém pode ajudar?
A pior parte é que as páginas NUNCA expiram, se isso acontecesse não seria tão ruim, mas depois de um tempo nada é veiculado.
Estou executando uma pilha CentOS LAMP com Coldfusion e NodeJS como minhas principais linguagens de script
ATUALIZE ANTES DE POSTAR REALMENTE
Durante o tempo que levei para escrever este post, que comecei após desabilitar o script Node e reiniciar o Coldfusion, o problema parece ter desaparecido.
Mas eu ainda gostaria de ajuda para identificar exatamente por que as páginas não atingiram o tempo limite e confirmar se o script do Node precisa de algo comoconnection.end()
Além disso, isso só pode acontecer sob carga, então não tenho 100% de certeza de que desapareceu
ATUALIZAR
Ainda com problemas, acabei de copiar uma das consultas que atualmente dura até 70 segundos no Fusion Reactor, executei-a manualmente no banco de dados e ela foi concluída em alguns milissegundos. As consultas em si não parecem ser um problema.
OUTRA ATUALIZAÇÃO
Rastreamento de pilha de uma das páginas ainda em execução. O servidor não para de servir páginas há algum tempo, todos os scripts do Node estão atualmente desativados
MAIS ATUALIZAÇÕES
Eu tive mais alguns deles hoje - eles realmente terminaram e descobri esse erro no FusionReactor:
Error Executing Database Query. The last packet successfully received from the server was 7,200,045 milliseconds ago. The last packet sent successfully to the server was 7,200,041 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
AINDA MAIS ATUALIZAÇÕES
Pesquisando o código, tentei procurar "2 h", "120" e "7200", pois achei que o tempo limite de 7200000 ms era uma coincidência demais.
Encontrei este código:
// 3 occurrences of this
createObject( "java", "coldfusion.tagext.lang.SettingTag" ).setRequestTimeout( javaCast( "double", 7200 ) );
// 1 occurrence of this
<cfsetting requestTimeOut="7200">
As 4 páginas que fazem referência a essas linhas de código são executadas muito raramente, nunca apareceram nos logs com o tempo limite de mais de 2h e estão em uma área protegida por senha, portanto não podem ser copiadas (eram para upload de arquivos e processamento de CSV, agora movido para nodejs).
É possível que essas configurações possam ser definidas de alguma forma por uma página, mas existam no servidor e afetem outras solicitações?
Responder1
1) publique um rastreamento de pilha.
Eu garanto que eles estarão pendurados em Socket.read() (ou similar)
O que está acontecendo é que metade da conexão TCP com o banco de dados está sendo fechada, deixando o cf aguardando uma resposta que nunca obterá.
Existem problemas de rede entre a caixa cf e o banco de dados.
Os drivers de banco de dados Java em geral são ruins para lidar com isso
Obrigado pelo rastreamento de pilha
Isso confirma minha suposição de que é metade do fechamento da conexão TCP.
Eu suspeito que um dos seguintes 1) o mysql está no linux e há um bug na pilha TCP, então você precisa atualizar o linux nessa caixa - sim, eu já vi isso antes 2) o coldfusion está no linux .. .conforme 1 ) 3) há um cabo/hardware com defeito em ou entre qualquer uma das caixas 4) se você estiver executando o Windows DESABILITE TCP OFFLOAD!!!
número 3) é o difícil. Você precisaria executar o wireshark em ambas as caixas e provar a perda de pacotes. A solução mais simples seria mover as VMs da Rackspace para diferentes hosts físicos e ver se elas desaparecem. (Há uma rara chance de seu código ser muito ruim e você estar saturando a rede entre a caixa CF e a caixa MySQL, mas não tenho certeza se é possível escrever um código tão ruim)
Responder2
Passei mais algum tempo investigando isso e tenho mais detalhes a acrescentar sobre a causa específica dos problemas de rede e uma solução alternativa encontrada com a ajuda de Charlie Arehart.
Primeiramente, a conexão de rede estava sendo interrompida por um acionamento automatizado de script iptables restart. Isso estava atualizando uma lista de endereços IP que poderiam acessar o servidor, mas também interrompendo quaisquer conexões entre o aplicativo e o servidor de banco de dados.
Era mais provável que isso acontecesse em páginas mais lentas ou que fossem executadas com mais frequência, mas qualquer coisa que coincidisse com o iptables restartcódigo seria cortada.
A Rackspace encontrou isso para mim e sugeriu alterar o código de:
/sbin/service iptables restart
para
/sbin/iptables-restore < /etc/sysconfig/iptables
Isso interrompe a reinicialização do serviço e se aplica apenas a novas conexões.
Essa foi a causa raiz do problema, mas o verdadeiro problema é o fato de que o Coldfusion, ou mesmo o JDBC subjacente, não parava de esperar pela resposta do servidor de banco de dados.
Não tenho certeza de onde ocorreu o tempo limite de 2 horas (supondo que seja um padrão), mas Charlie mostrou uma maneira de definir um tempo limite menor na string de conexão CFIDE - isso diz ao CF para esperar um tempo máximo antes de desistir do banco de dados.
Portanto, nossa string de conexão é:
__fusionreactor_name=datasourcename;connectTimeout=600000;socketTimeout=600000;
Não me lembro dos detalhes desses 2, mas eles estão configurando um tempo em milissegundos para esperar e depois desistir da conexão db:
- connectTimeout=600000;
- soqueteTimeout=600000;
Este é simplesmente rotular a fonte de dados no Fusion Reactor - se você tiver, é muito útil para encontrar problemas em seus aplicativos CF. Se você não possui o Fusion Reactor, deixe esta parte de fora.
- __fusionreactor_name=dsnapi;
Você terá que aplicar isso a CADA fonte de dados em seu CFIDE
