Conexiones "pegadas"?

[Ayesha]

Hola!

Recientemente tengo un problema con el mySQL, aparentemente las conexiones se quedan "pegadas" en la cola de procesos y eso hace que los demás usuarios no puedan conectarse. Si reinicio el servicio se arregla momentáneamente o si no hago nada, al cabo de un rato se arregla también.

Mi cola de procesos tiene algo así:

mysql> show processlist;
+------+----------------+-----------+---------------------+---------+------+--------------+------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+----------------+-----------+---------------------+---------+------+--------------+------------------------------------------------------------------------------------------------------+
| 2917 | vpsslash_slash | localhost | vpsslash_slasheaven | Query | 397 | Sending data | SELECT COUNT(DISTINCT author.uid) FROM fanfiction_authors as author LEFT JOIN fanfiction_stories as |
| 2919 | vpsslash_slash | localhost | vpsslash_slasheaven | Query | 394 | Locked | UPDATE fanfiction_stories SET count = count + 1 WHERE sid = '18563' LIMIT 1 |
| 2920 | vpsslash_slash | localhost | vpsslash_slasheaven | Query | 393 | Locked | SELECT stories.*, author.penname as penname, UNIX_TIMESTAMP(stories.date) as date, UNIX_TIMESTAMP(st |
| 2923 | vpsslash_slash | localhost | vpsslash_slasheaven | Query | 392 | Locked | SELECT stories.*, author.penname as penname, UNIX_TIMESTAMP(stories.date) as date, UNIX_TIMESTAMP(st |
| 2924 | vpsslash_slash | localhost | vpsslash_slasheaven | Query | 389 | Locked | SELECT count(sid) FROM fanfiction_stories as stories WHERE validated > 0 AND (FIND_IN_SET(15, storie |

Como ven, hay procesos que están 397 segundos pegados y eso me parece que es lo que causa el problema; sin embargo en el mes y medio que llevo en el VPS no me había pasado, lo que me lleva a pensar que han modificado algo y no me lo quieren decir.

No tenía un php.ini, de modo que puse uno y lo he configurado para el mySQL del siguiente modo:

[MySQL]
; Allow or prevent persistent links.
mysql.allow_persistent = Off

; Maximum number of persistent links. -1 means no limit.
mysql.max_persistent = 0

; Maximum number of links (persistent + non-persistent). -1 means no limit.
mysql.max_links = -1

; Default port number for mysql_connect(). If unset, mysql_connect() will use
; the $MYSQL_TCP_PORT or the mysql-tcp entry in /etc/services or the
; compile-time value defined MYSQL_PORT (in that order). Win32 will only look
; at MYSQL_PORT.
mysql.default_port =

; Default socket name for local MySQL connects. If empty, uses the built-in
; MySQL defaults.
mysql.default_socket =

; Default host for mysql_connect() (doesn't apply in safe mode).
mysql.default_host =

; Default user for mysql_connect() (doesn't apply in safe mode).
mysql.default_user =

; Default password for mysql_connect() (doesn't apply in safe mode).
; Note that this is generally a *bad* idea to store passwords in this file.
; *Any* user with PHP access can run 'echo get_cfg_var("mysql.default_password")
; and reveal this password! And of course, any users with read access to this
; file will be able to reveal the password as well.
mysql.default_password =

; Maximum time (in seconds) for connect timeout. -1 means no limit
mysql.connect_timeout = 60

; Trace mode. When trace_mode is active (=On), warnings for table/index scans and
; SQL-Errors will be displayed.
mysql.trace_mode = Off

Sin embargo, el problema no se ha resuelto.

Yo estoy decidida a cambiar de hosting pero no quiero regalarles el mes y medio que ya pagué, de modo que me gustaría saber si hay algo más que pueda intentar respecto a la configuración.

Agradeceré cualquier ayuda.

[ideasmultiples]

Iniciado por Ayesha

Hola!

Recientemente tengo un problema con el mySQL, aparentemente las conexiones se quedan "pegadas" en la cola de procesos y eso hace que los demás usuarios no puedan conectarse. Si reinicio el servicio se arregla momentáneamente o si no hago nada, al cabo de un rato se arregla también.

Mi cola de procesos tiene algo así:



Como ven, hay procesos que están 397 segundos pegados y eso me parece que es lo que causa el problema; sin embargo en el mes y medio que llevo en el VPS no me había pasado, lo que me lleva a pensar que han modificado algo y no me lo quieren decir.

No tenía un php.ini, de modo que puse uno y lo he configurado para el mySQL del siguiente modo:



Sin embargo, el problema no se ha resuelto.

Yo estoy decidida a cambiar de hosting pero no quiero regalarles el mes y medio que ya pagué, de modo que me gustaría saber si hay algo más que pueda intentar respecto a la configuración.

Agradeceré cualquier ayuda.

El php.ini SI tienes que haberlo tenido en tu servidor, sin eso no funcionaria y está en el directorio /etc/php.ini

Para cambiar la configuracion de MySQL debes de modificar el /etc/my.cnf como hacerlo y que parámetros usar dependen sobre todo de la memoria de tu máquina.

Cambia o añade estos :
interactive_timeout=100
wait_timeout=60
connect_timeout=10
long_query_time=5

restaura el mysql y prueba de nuevo.

De todas formas los datos que pones indican que tiene serios problemas en tu servidor, probablemente falta de memoria y/o tablas muy grandes y mal optimizadas.

[Ayesha]

Muchas gracias por la respuesta.

Hay algo que no entiendo, mi directorio /etc está vacío, sólo tiene otro directorio llamado dominio.com y allí hay unos archivos llamados passwd y cosas así.

El php.ini que uso lo he copiado recién en public_html

Otra consulta, los parámetros
interactive_timeout=100
wait_timeout=60
connect_timeout=10
long_query_time=5

Son para el php.ini o para my.cnf?? ¿dónde puedo conseguir un my.cfn de ejemplo?

Según dice lo que he contratado, esto es lo que mi servidor tiene:

20 GB Raid Disk Space
300 GB Monthly Data Transfer
512 MB Guaranteed Ram
1 GB Burstable Ram
Virtuozzo Power Panel
cPanel/WHM w/ Fantastico & RVskin
Free WHMAP or CE Billing Software
4 IP Addresses Included

También he optimizado la base de datos, y hace una semana funcionaba muy bien, no ha crecido tanto y no entiendo qué pasa.

[ideasmultiples]

Iniciado por Ayesha

Muchas gracias por la respuesta.

Hay algo que no entiendo, mi directorio /etc está vacío, sólo tiene otro directorio llamado dominio.com y allí hay unos archivos llamados passwd y cosas así.

El php.ini que uso lo he copiado recién en public_html

Otra consulta, los parámetros
interactive_timeout=100
wait_timeout=60
connect_timeout=10
long_query_time=5

Son para el php.ini o para my.cnf?? ¿dónde puedo conseguir un my.cfn de ejemplo?

Según dice lo que he contratado, esto es lo que mi servidor tiene:

20 GB Raid Disk Space
300 GB Monthly Data Transfer
512 MB Guaranteed Ram
1 GB Burstable Ram
Virtuozzo Power Panel
cPanel/WHM w/ Fantastico & RVskin
Free WHMAP or CE Billing Software
4 IP Addresses Included

También he optimizado la base de datos, y hace una semana funcionaba muy bien, no ha crecido tanto y no entiendo qué pasa.

El php.ini debe de ir en /etc/ en donde lo has puesto no sirve de nada...

Los datos que te dí son para el my.cnf

Consulta con tu soporte técnico que para eso les pagas o busca en los foros encontraras varios ejemplos

[Ayesha]

Gracias, en eso estoy.

[Ayesha]

¡Hola!

He modificado los parámetros según me indican y he reiniciado el servidor; sin embargo, en la cola de procesos veo todavía en la columna "Time" tiempos superiores a los 100 segundos y no lo entiendo, porque se supone que las variables del php.ini y el my.cnf controlarían eso.

Mis tablas más usadas tienen 8000 y 30000 registros aproximadamente y funcionaban sin problemas hace algunos días. La verdad no sé a qué se debe la lentitud que tienen ahora.

He activado logs para poder monitorar lo que pasa, pero agradeceré cualquier ayuda.

[ideasmultiples]

Iniciado por Ayesha

¡Hola!

He modificado los parámetros según me indican y he reiniciado el servidor; sin embargo, en la cola de procesos veo todavía en la columna "Time" tiempos superiores a los 100 segundos y no lo entiendo, porque se supone que las variables del php.ini y el my.cnf controlarían eso.

Mis tablas más usadas tienen 8000 y 30000 registros aproximadamente y funcionaban sin problemas hace algunos días. La verdad no sé a qué se debe la lentitud que tienen ahora.

He activado logs para poder monitorar lo que pasa, pero agradeceré cualquier ayuda.

Es muy probable entonces que el nodo de tu VPS esté saturado por demasiado tráfico de I/O.

Recuerda que despues de los cambios tienes que reinicializar el apache y el mysql.

Has comprobado si te pasa lo mismo en la noche?

[Ayesha]

Hola

Gracias por la ayuda. Bueno... por la noche la cosa es peor. He monitoreado queries de 1000 segundos.

Pero por qué no se desactivan si los parámetros dicen eso? Yo he reiniciado todo, apache, mysql, servidor y no parece haber una gran mejoría.

¿Cómo puedo saber si el nodo del VPS está saturado?

[ideasmultiples]

Iniciado por Ayesha

Hola

Gracias por la ayuda. Bueno... por la noche la cosa es peor. He monitoreado queries de 1000 segundos.

Pero por qué no se desactivan si los parámetros dicen eso? Yo he reiniciado todo, apache, mysql, servidor y no parece haber una gran mejoría.

¿Cómo puedo saber si el nodo del VPS está saturado?

Sería bueno que pongas cual es tu página para poder ver como está organizada.

No hay forma de ver el rendimiento de un nodo más que por el administrador del mismo.

Lo único que te queda es que te solucione el problema tu proveedor de hosting y si no deberías ir pensando en cambiar a otro....

[lizardopc]

Veo que estas usando cpanel, si tienes cpanel lo mas seguro es que el archivo php.ini este en /usr/local/lib/php.ini lo mejor es que hagas un archivo <? phpinfo(); ?> y ver que archivo esta usando. Si tienes php-cgi con suexec podria ser que estes usando el archivo que subiste en el public_html por eso fijate bien que archivo php.ini estas usando.

[Ayesha]

Muchas gracias a todos ^^

De momento encontré dos queries asesinos en la aplicación. He desactivado uno, pero el otro desgraciadamente se usa en algunas páginas que son útiles para mis usuarios, así que estoy probando parámetros para queries con left joins y subqueries.

Estoy usando:
join_buffer_size=4M
tmp_table_size=324M

Mi hosting actual ofrece 512RAM garantizado (que realmente no me consta) y no estoy segura si esos valores servirán o son demasiado altos/bajos.

La consulta asesina es esta:

SELECT count( stories.sid ) as stories,
author.penname as penname,
author.uid as uid
FROM fanfiction_authors as author
LEFT JOIN fanfiction_authorprefs AS ap
ON author.uid = ap.uid
LEFT JOIN fanfiction_stories AS stories
ON stories.validated > 0
AND (FIND_IN_SET(author.uid, stories.coauthors) > 0 OR stories.uid = author.uid)
WHERE author.penname LIKE '%Ameba%' GROUP BY author.uid

Y las tablas de stories y authors tienen 8000 registros cada una.

[ImeldaTrejo]

Definitivamente tu problema no es de configuración, sino de las consultas que bien llamas "asesinas". El LEFT JOIN es una maravilla y tu consulta tiene una buena construcción, yo tambien tuve hoy problemas semejantes y la forma de resolverlos fué "angostar" la consulta poniendo condiciones en el WHERE, es decir, si en alguna de las tablas hay algun campo que puedas comparar para reducir el numero de registros involucrados, eso beneficia tremendamente el tiempo de respuesta. Por ejemplo, si tienes algún campo de "estatus" vigente o un intervalo de fechas para comparar. Cualquier cosa que aligere el numero de regitros que se va a llevar a relacionar con el LEFT JOIN.
Espero que esto también te sirva

[WebTech]

ImeldaTrejo,

Bienvenido a Foros del Web!

Esperemos que le sirva si, aunque este post tiene ya casi 6 meses inactivo

Un saludo!

[Ayesha]

¡Hola!

Gracias por la ayuda. Resolví el problema haciendo justamente eso, había un query espantoso (no el que cité en el post) que era el que se comía los recursos.

Me costó lo suyo encontrarlo, pero felizmente ahora la página se porta bien.

[shapeware]

Ejem, la base de datos es MyISAM o innoDB? Por que justamente el problema que tienes con las queries locked es porque son queries de UPDATE, y seguramente tienes el problema de que MyISAM tiene que hacer los updates de forma secuencial, y mientras se hace un update otros updates y selects se bloquean.

Pasa la base de datos a innoDB y veras como te desaparecen los locked de las queries.

MyISAM = Databases básicamente de lectura
innoDB = Databases con muchos updates