Vea la imagen adjunta de Fusion Reactor, que muestra páginas que siguen ejecutándose. Los tiempos han subido a millones y los he dejado para ver si se completaban pero eso fue cuando solo quedaban 2 o 3.
Ahora recibo docenas de páginas que nunca terminan. Y son consultas diferentes, no puedo ver ningún patrón importante, excepto que solo parece aplicarse a 3 de mis 7 bases de datos.
topmuestrafusión fríaEl uso de la CPU es de alrededor del 70-120%, y profundizar en las páginas de detalles del Fusion Reactor muestra que todo el tiempo de construcción se dedica únicamente a consultas de Mysql.
show processlistno devuelve nada inusual, excepto 10 - 20 conexiones endormirestado.
Durante este tiempo, muchas páginas se completan, pero a medida que aumenta el número de páginas que cuelgan y parece que nunca terminan, el servidor finalmente devuelve páginas en blanco.
La única solución a corto plazo parece ser reiniciar Coldfusion, lo que está lejos de ser ideal.
Recientemente se agregó un script Node.js que se ejecuta cada 5 minutos y verifica si hay archivos csv por lotes para procesar. Me preguntaba si eso estaba causando un problema al robar todas las conexiones MySQL, así que lo deshabilité (el script no tiene conexión). () método en él), pero eso es sólo una suposición rápida.
No tengo idea de por dónde empezar, ¿alguien puede ayudar?
La peor parte es que las páginas NUNCA caducan, si así fuera no sería tan malo, pero después de un tiempo no se sirve nada.
Estoy ejecutando una pila CentOS LAMP con Coldfusion y NodeJS como mis lenguajes de programación principales
ACTUALIZAR ANTES DE PUBLICAR REALMENTE
Durante el tiempo que me llevó escribir esta publicación, que comencé después de deshabilitar el script de Node y reiniciar Coldfusion, el problema parece haber desaparecido.
Pero aún así me gustaría recibir ayuda para identificar exactamente por qué las páginas no expiran y confirmar que el script de Node necesita algo comoconnection.end()
Además, es posible que solo ocurra bajo carga, por lo que no estoy 100% seguro de que haya desaparecido.
ACTUALIZAR
Sigo teniendo problemas, acabo de copiar una de las consultas que actualmente tiene una duración de hasta 70 segundos en Fusion Reactor, la ejecuté manualmente en la base de datos y se completó en unos pocos milisegundos. Las consultas en sí no parecen ser un problema.
OTRA ACTUALIZACIÓN
El rastro de pila de una de las páginas aún continúa. El servidor no ha dejado de publicar páginas desde hace un tiempo, todos los scripts de Node actualmente están deshabilitados
MÁS ACTUALIZACIONES
Tuve algunos más de estos hoy; de hecho, terminaron y vi este error en 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.
AÚN MÁS ACTUALIZACIONES
Indagando en el código, intenté buscar "2 h", "120" y "7200", ya que sentí que el tiempo de espera de 7200000 ms era demasiada coincidencia.
Encontré este código:
// 3 occurrences of this
createObject( "java", "coldfusion.tagext.lang.SettingTag" ).setRequestTimeout( javaCast( "double", 7200 ) );
// 1 occurrence of this
<cfsetting requestTimeOut="7200">
Las 4 páginas que hacen referencia a esas líneas de código se ejecutan muy raramente, nunca han aparecido en los registros con tiempos de espera de más de 2 horas y están en un área protegida con contraseña, por lo que no se pueden eliminar (eran para carga de archivos y procesamiento CSV, ahora movido a nodejs).
¿Es posible que estas configuraciones puedan ser establecidas de alguna manera por una página pero existan en el servidor y afecten otras solicitudes?
Respuesta1
1) publicar un seguimiento de la pila.
Te garantizo que estarán colgados en Socket.read() (o similar)
Lo que está ocurriendo es que la mitad de la conexión tcp a la base de datos se está cerrando, dejando a cf esperando una respuesta que nunca obtendrá.
Hay problemas de red entre cf box y db.
Los controladores de base de datos de Java en general no son buenos para lidiar con esto
Gracias por el seguimiento de la pila.
Esto confirma mi suposición de que se está cerrando la mitad de la conexión TCP.
Sospecho que uno de los siguientes 1) mysql está en Linux y hay un error en la pila TCP, por lo que necesita actualizar Linux en ese cuadro; sí, he visto esto antes 2) Coldfusion está en Linux... según 1 ) 3) hay un cable/hardware defectuoso en o entre cualquiera de las cajas 4) si está ejecutando Windows, ¡¡¡DESHABILITE LA DESCARGA TCP!!!
El número 3) es el difícil. Debería ejecutar Wirehark en ambas cajas y demostrar la pérdida de paquetes. La solución más sencilla sería mover las máquinas virtuales de Rackspace a diferentes hosts físicos y ver si desaparece. (Existe una rara posibilidad de que su código sea muy malo y esté saturando la red entre el cuadro CF y el cuadro MySQL, pero no estoy seguro de que sea posible escribir un código tan malo)
Respuesta2
He dedicado más tiempo a investigar esto y tengo más detalles que agregar sobre la causa específica de los problemas de red y una solución alternativa encontrada con la ayuda de Charlie Arehart.
En primer lugar, la conexión de red estaba siendo interrumpida por un script automático que se activaba iptables restart. Esto fue actualizar una lista de direcciones IP que podían acceder al servidor pero también romper cualquier conexión entre la aplicación y el servidor de base de datos.
Era más probable que ocurriera en páginas más lentas o en aquellas que se ejecutaban con más frecuencia, pero cualquier cosa que coincidiera con el iptables restartcódigo se cortaría.
Rackspace encontró esto por mí y sugirió cambiar el código de:
/sbin/service iptables restart
a
/sbin/iptables-restore < /etc/sysconfig/iptables
Esto detiene el reinicio del servicio y solo se aplica a nuevas conexiones.
Esta fue la causa raíz del problema, pero el verdadero problema es el hecho de que Coldfusion, o realmente el JDBC subyacente, no dejaba de esperar la respuesta del servidor de base de datos.
No estoy seguro de dónde entró el tiempo de espera de 2 horas (suponiendo que sea un valor predeterminado), pero Charlie mostró una manera de establecer un tiempo de espera más bajo en la cadena de conexión CFIDE; esto le dice a CF que espere un tiempo máximo antes de abandonar la base de datos.
Entonces nuestra cadena de conexión es:
__fusionreactor_name=datasourcename;connectTimeout=600000;socketTimeout=600000;
No recuerdo los detalles de estos 2, pero están estableciendo un tiempo en milisegundos para esperar y luego abandonar la conexión de base de datos:
- conectarTimeout=600000;
- socketTimeout=600000;
Este simplemente etiqueta la fuente de datos en Fusion Reactor; si lo tiene, es muy útil para encontrar problemas en sus aplicaciones CF. Si no tienes Fusion Reactor, omite esta parte.
- __fusionreactor_name=dsnapi;
Tendrás que aplicar esto a CADA fuente de datos en tu CFIDE
