Cómo determinar qué código PHP abre las conexiones MySQL que no se están cerrando

StackOverflow https://stackoverflow.com/questions/1643652

Pregunta

Tenemos una aplicación que se compone de un par de aplicaciones PHP estándar (ExpressionEngine y XCart), así como nuestro propio código personalizado.

No hice el análisis real, así que no sé exactamente cómo se determinó, pero no me sorprende escuchar que demasiadas conexiones MySQL se quedan sin cerrar (no me sorprende porque he estado viendo una pérdida de memoria significativa en nuestro servidor de desarrollo, donde en el transcurso de un día o dos, a partir de 100 MB en el arranque inicial, se consume todo el concierto de ram, y se almacena muy poco en caché).

Entonces, ¿cómo hacemos para determinar con precisión qué código PHP es el culpable? Tengo experiencia previa con XDebug, y he sugerido que, cuando tengamos nuestro entorno de etapas separado razonablemente estable, que adaptemos XDebug en dev y lo usemos para hacer algunos análisis. ¿Es esto razonable y / o alguien más tiene sugerencias más específicas y / o adicionales?

¿Fue útil?

Solución

Puedes usar el 

 SHOW PROCESSLIST

Comando SQL para ver qué procesos se están ejecutando. Eso le dirá el nombre de usuario, el host, la base de datos, etc. que están en uso en cada proceso. Eso debería darle una idea de lo que está sucediendo, especialmente si tiene varias bases de datos a las que se accede.

Más aquí: http://codeinthehole.com/archives/2- Monitoring-MySQL-projects.html

Otros consejos

Esto no debe ser causado por un código php porque se supone que las conexiones mysql se cierran automáticamente.

cf: http://www.php.net/manual/function .mysql-connect.php :

  

El enlace al servidor se cerrará   tan pronto como se ejecute el script   termina, a menos que esté cerrado antes por   llamando explícitamente a mysql_close ().

Algunas sugerencias:

  • ¿su desarrollador tiene técnicamente un acceso directo a su servidor mysql de producción? en caso afirmativo, entonces probablemente dejen abierto su Mysql Manager :)
  • ¿tiene algún proceso por lotes diario? en caso afirmativo, tal vez hay algún proceso zombi en la memoria

PHP cierra automáticamente cualquier conexión mysql cuando finaliza la página. la única razón por la que una aplicación web PHP tendría demasiadas conexiones mysql no cerradas es 1) está utilizando la agrupación de conexiones o 2) hay un error en el servidor mysql o el conector.

pero si realmente desea ver su código para encontrar dónde se conecta, consulte http: // xdebug. org / docs / profiler

Como otros dijeron, PHP termina las conexiones MySQL creadas a través de mysql_connect o los equivalentes msqli / PDO.

Sin embargo, puede crear conexiones persistentes con mysql_pconnect . Buscará las conexiones existentes abiertas y las usará; Si no puede encontrar uno, abrirá uno nuevo. Si tuviera muchas solicitudes a la vez, podría haber causado que se abrieran y se mantuvieran abiertas muchas conexiones.

Puede disminuir el número máximo de conexiones o disminuir el tiempo de espera para conexiones persistentes. Consulte los comentarios en la parte inferior de la página del manual para obtener más información. detalles.

Solía ??ejecutar un script que sondeó SHOW STATUS para el recuento de subprocesos y noté que usar mysql_pconnect siempre fomentaba un gran número de subprocesos. Lo encontré muy desconcertante porque entonces no podía decir cuándo mi tasa de conexión estaba cayendo. Así que me aseguré de centralizar todos los lugares donde se llamó a mysql_connect () y eliminar mysql_pconnect ().

Lo siguiente que hice fue mirar los tiempos de espera de conexión y ajustarlos a más como 30 segundos porque. Entonces ajusté mi my.cnf con

connect-timeout = 30

para poder ver la cantidad de conexiones que se caen. Para determinar la cantidad de conexiones que necesita abrir depende de cuántos trabajadores de apache esté ejecutando, la cantidad de conexiones de base de datos que abrirán cada una.

La otra cosa que comencé a hacer fue agregar una nota a mis consultas para detectarlas en SHOW PROCESSLIST o mytop, agregaría una columna de nota a mis resultados como: 

$q = "SELECT '".__FILE__.'.'.__LINE__."' as _info, * FROM table ...";

Esto me mostraría el archivo que emitía la consulta cuando miraba mytop, y no frustraba la caché de consultas de MySQL como si usara 

/* __FILE__.'.'.__LINE__ */

al comienzo de mi consulta.

Supongo que otro par de cosas que puedo hacer, con respecto al problema de memoria general, en oposición específicamente a MySQL, y particularmente dentro del contexto de nuestro propio código personalizado, sería envolver nuestro código con llamadas a uno o al otras de las siguientes funciones integradas de PHP:

memory_get_usage

memory_get_peak_usage

En particular, dado que actualmente estoy trabajando en iniciar sesión desde algún código personalizado, puedo registrar el uso de la memoria mientras estoy en ello

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top