Rastreo de fugas de la conexión MySQL

Question

Tengo un servidor de aplicaciones (embarcadero 6 en una caja Linux) que aloja 15 aplicaciones individuales (guerras individuales). Cada 3 o 4 días recibo una alerta de nagios con respecto al número de conexiones TCP abiertas. Tras la inspección, veo que la gran mayoría de estas conexiones son para el servidor MySQL.

netstat -ntu | grep TIME_WAIT 

Shows más de 10.000 conexiones en el servidor MySQL desde el servidor de aplicaciones (nótese el estado TIME_WAIT es). Si reinicio el embarcadero las conexiones caen casi a cero.

algunos valores interesantes desde un estado de espectáculo:

mysql> show status; 
+--------------------------+-----------+ 
| Variable_name   | Value  | 
+--------------------------+-----------+ 
| Aborted_clients   | 244  | 
| Aborted_connects   | 695853860 | 
| Connections    | 697203154 | 
| Max_used_connections  | 77  | 
+--------------------------+-----------+ 

un "show processlist" no muestra nada fuera de lo normal (que es lo que sería de esperar ya que la mayoría de las conexiones son ralentí - recordar la Estado TIME_WAIT desde arriba).

Tengo una PRUEBA env para este servidor pero nunca tiene ningún problema. Obviamente, no recibe mucho tráfico y el servidor de aplicaciones se reinicia constantemente, por lo que la eliminación de errores no es de mucha ayuda. Supongo que podría profundizar en cada aplicación individual y escribir una prueba de carga que golpearía el código de la base de datos, pero esto tomaría mucho tiempo/molestia.

¿Alguna idea de cómo podría rastrear la aplicación que está tomando todas estas conexiones y nunca dejar ir?

Answer 1

La respuesta parece estar añadiendo las siguientes entradas en my.cnf en [mysqld] :

wait_timeout=60 
interactive_timeout=60 

lo encontré aquí (todo el camino en la parte inferior): http://community.livejournal.com/mysql/82879.html

El valor por defecto el tiempo de espera para matar una conexión obsoleta es de 22800 segundos. Para verificar :

EDIT: se me olvidó mencionar, que también añadió lo siguiente a /etc/sysctl.conf:

net.ipv4.tcp_fin_timeout = 15 

Esto se supone para ayudar a bajar el umbral de espera del OS antes de reutilizar los recursos de conexión.

EDIT 2: /etc/init.d/mysql recargar realmente no se recargue su my.cnf (ver el enlace más abajo)

Answer 2

Bueno, una cosa que me viene a la mente (aunque no soy un experto en esto) es aumentar el registro en mySQL y buscar todos los mensajes de conexión/cierre. Si eso no funciona, puede escribir un pequeño proxy para sentarse entre el servidor mySQL real y su suite de aplicaciones que hace el registro adicional y sabrá quién se está conectando/saliendo.

Answer 3

Posiblemente el grupo de conexiones están mal configurados para aferrarse a demasiadas conexiones y se mantienen en demasiados procesos inactivos.

Aparte de eso, todo lo que puedo pensar es que una parte del código se mantiene en un conjunto de resultados, pero parece menos probable. Para ver si es una consulta lenta que se agota, también puede configurar mysql para escribir en un registro lento de consultas en el archivo conf, y luego escribirá todas las consultas que tarden más de X segundos (el valor predeterminado es 5, creo) .

Answer 4

SHOW PROCESSLIST muestra el usuario, servidor y base de datos para cada hilo.A menos que todas sus 15 aplicaciones utilicen la misma combinación, entonces debería poder diferenciar el uso de esta información.

Answer 5

Tuve el mismo problema con +30,000 TIME_WAIT en mi servidor cliente. Se ha solucionado el problema mediante la adición, en /etc/sysctl.conf:

net.ipv4.tcp_syncookies = 1 
net.ipv4.tcp_tw_reuse = 1 
net.ipv4.tcp_tw_recycle = 1 
net.ipv4.tcp_fin_timeout = 30 

Entonces:

/sbin/sysctl -p 

después de 2 o 3 minutos, conexiones TIME_WAIT fueron de 30 000-7 000.

Answer 6

/proc/sys/net/ipv4/tcp_fin_timeout fue 60 en RHEL7.tcp_tw_reuse y tcp_tw_recycle se cambió a 1 y se mejoró el rendimiento.