Veja a imagem anexada do Fusion Reactor, mostrando as páginas que continuam em execução.
Os tempos subiram para milhões e eu os deixei para ver se eles terminariam, mas foi quando havia 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 ele só parece se aplicar a três dos meus sete bancos de dados.
top mostra o uso da CPU coldfusion em torno de 70-120%, e cavar mais fundo nas páginas de detalhes do Fusion Reactor mostra que todo o tempo gasto é gasto somente nas consultas do Mysql.
show processlist não retorna nada incomum, executa 10 a 20 conexões no estado sleep .
Durante esse tempo, muitas páginas são concluídas, mas à medida que o número de páginas penduradas se acumula e elas parecem nunca terminar o servidor, acaba retornando as páginas brancas.
A única solução de curto prazo parece estar reiniciando o Coldfusion, o que está longe de ser ideal.
Um script do Node.js foi adicionado recentemente e executado a cada 5 minutos e verifica se há arquivos CSV em lote para processar, fiquei imaginando se isso estava causando um problema com o roubo de todas as conexões do MySQL, então desativei (o script não tem método connection.end ()), mas isso é apenas um palpite rápido.
Não tem ideia de por onde começar, alguém pode ajudar?
A pior parte é que as páginas NUNCA acabam, se o fizerem não seria tão ruim, mas depois de um tempo nada é servido.
Estou executando uma pilha CentOS LAMP com Coldfusion e NodeJS como minhas principais linguagens de script
ATUALIZAÇÃOANTESDEPOSTARATUALMENTE
Duranteotempoquelevouparaescreverestepost,queinicieidepoisdedesabilitaroscriptNodeereiniciaroColdfusion,oproblemapareceterdesaparecido.
MaseuaindagostariadeajudaparaidentificarexatamenteporqueaspáginasnãoexpirarameconfirmarqueoscriptdoNodeprecisadealgocomoconnection.end()
Alémdisso,issopodeacontecerapenassobcarga,entãonãotenho100%decertezadequefoieliminado
ATUALIZAÇÃO
Aindatendoproblemas,acabeidecopiarumadasconsultasqueestãoatualmenteematé70segundosnoFusionReactoreexecutá-lasmanualmentenobancodedadoseelasforamconcluídasemalgunsmilissegundos.Asconsultasemsinãoparecemserumproblema.
OUTRAATUALIZAÇÃO
Rastreamentodepilhadeumadaspáginasaindaemandamento.Oservidornãoparoudeservirpáginasporumtempo,todososscriptsdoNodeestãoatualmentedesativados
link
MAIS ATUALIZAÇÕES
Eu tinha mais alguns deles hoje - eles realmente terminaram e vi 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.
MESMO MAIS ATUALIZAÇÕES
Pesquisando o código, tentei procurar "2 h", "120" e "7200", pois achei que o tempo limite de 7200000ms foi uma coincidência demais.
Eu 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 saídas de tempo de 2h + e estão em uma área protegida por senha, portanto não podem ser raspadas (eram para uploads de arquivos e CSV processamento, agora movido para nodejs).
É possível que essas configurações possam, de alguma forma, ser definidas por uma página, mas existirem no servidor e afetarem outras solicitações?
