Desactivación temporal Tapatalk

Suko · 07-feb-2014, 11:40

Hola a todos, durante unos días vamos a desactivar Tapatalk porque es posible que el plugin esté afectando al rendimiento del foro.

En las últimas semanas estamos recibiendo muchos errores de timeout que genera el plugin, aquí os dejo un ejemplo de hoy mismo:

2014/02/07 11:12:57 [error] 32696#0: *69997688 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 37.132.10.202, server: todocircuito.com, request: "POST /foro/mobiquo/mobiquo.php HTTP/1.1", upstream: "http://37.59.53.227:7080/foro/mobiquo/mobiquo.php", host: "www.todocircuito.com"

El problema, hablando en cristiano, es que cuando tratas de cargar una página del foro, el plugin de tapatalk no responde en ocasiones y se queda la página cargando en blanco, hasta que te da un error 504. El fallo es indiferente estés usando un ordenador o un móvil, y pasa tanto dentro como fuera de Tapatalk (algún usuario ya me lo ha comentado por privado).

Tapatalk es un plugin externo del cual no tenemos casi control, ellos te dan el paquete, lo instalas y si hay problemas son ellos los que deben ayudarnos a ver de dónde viene. Nos hemos puesto en contacto con ellos para ver si pueden identificar el error.

Como decía al principio, hemos desactivado el plugin de forma temporal para comprobar si los momentos de lentitud del foro vienen originados por tapatalk tal y como sospechamos. Mientras tanto, os recordamos a los usuarios de Tapatak que el foro dispone de versión móvil que se activa automáticamente cuando entras desde un dispositivo móvil.

A ver si, con suerte, el lunes está resuelto y podemos activarlo de nuevo.

Saludos.

GabiRR · 07-feb-2014, 13:38

Así es Suko, no siempre pero a veces se queda pillado y da ese error

rsv4@prc · 07-feb-2014, 16:55

A mi tambien me paso ara 15 dias

Joric · 07-feb-2014, 17:04

A mí me daba problemas alguna vez pero no tenía ni idea de qué era...

camposkr · 09-feb-2014, 12:50

Ok suko, todo aclarado, ojala se arregle pronto porque nos es muy como tapatalk, graciasss

Thesxer · 10-feb-2014, 18:43

Uffff yo estoy jodidillo sin Tapatalk, ojalá se solucione pronto. Gracias por todo el soporte.

Suko · 10-feb-2014, 19:26

Hola, de momento no tenemos solución desde el soporte de Tapatalk, aunque esperamos que nos lo den en breve.

En cualquier caso no es seguro que todo el problema venga del plugin, ya que si bien da errores, creeemos que hay otro proceso sobrecargando la base de datos cada XX minutos. El problema está en el servidor que aloja la bbdd del foro, el otro servidor no tiene problemas de acceso, así que tiene que ser algo del foro.

Este tipo de problemas se solucionan así, dejando pasar los días y "acotando" los errores que van saliendo hasta encontrar qué los original.

Confiamos en que para finales de semana esté solucionado y tapatalk activo de nuevo.

Lagartijuancho · 10-feb-2014, 22:04

Estos días sin Tapatalk se me están haciendo eternos, y no me entero de nada del foro!! A ver si se soluciona pronto

Newton · 11-feb-2014, 08:17

Cita:

Originalmente publicado por Suko

Hola, de momento no tenemos solución desde el soporte de Tapatalk, aunque esperamos que nos lo den en breve.

En cualquier caso no es seguro que todo el problema venga del plugin, ya que si bien da errores, creeemos que hay otro proceso sobrecargando la base de datos cada XX minutos. El problema está en el servidor que aloja la bbdd del foro, el otro servidor no tiene problemas de acceso, así que tiene que ser algo del foro.

Este tipo de problemas se solucionan así, dejando pasar los días y "acotando" los errores que van saliendo hasta encontrar qué los original.

Confiamos en que para finales de semana esté solucionado y tapatalk activo de nuevo.

Si como dices el problema pueda estar en la BBDD, puede que el causante es que os quedéis sin recursos por el tamaño del buffer de conexiones, revisad el net.ipv4.tcp_max_syn_backlog y net.core.somaxconn del kernel y el back_log de MySQL

Más info:

El numero de peticiones de conexión que puede tener MySQL. Esto se usa cuando el thread principal de MySQL recibe muchas peticiones de conexión en un pequeño lapso de tiempo. Necesita algo de tiempo (aunque muy poco) el thread principal para comprobar la conexión y empezar un nuevo thread. El valor de back_log indica cuántas peticiones pueden almacenarse duarnte este corto espacio de tiempo antes que MySQL temporalmente pare de responder a nuevas peticiones. Necesita incrementarlo sólo si espera un gran número de conexiones en un pequeño lapso de tiempo.

En otras palabras, este valor es el tamaño de la cola que escucha conexiones TCP/IP entrantes. El sistema operativo tiene su propio límite en el tamaño de la cola. La página del manual para la llamada de sistema Unix listen() proporcion más detalles. Consulte la documentación del SO para el máximo valor de esta variable. Intentar cambiar el valor de back_log por encima del límite del sistema operativo no es efectivo.

Newton · 11-feb-2014, 08:19

Sobre mi mensaje... ejecuta netstat -s y busca una cadena como esta

"1334 times the listen queue of a socket overflowed"

Si el número (1334 en este caso) es muy alto.... ya tienes la respuesta

Suko · 11-feb-2014, 08:46

Cita:

Originalmente publicado por Newton

Si como dices el problema pueda estar en la BBDD, puede que el causante es que os quedéis sin recursos por el tamaño del buffer de conexiones, revisad el net.ipv4.tcp_max_syn_backlog y net.core.somaxconn del kernel y el back_log de MySQL

Más info:

El numero de peticiones de conexión que puede tener MySQL. Esto se usa cuando el thread principal de MySQL recibe muchas peticiones de conexión en un pequeño lapso de tiempo. Necesita algo de tiempo (aunque muy poco) el thread principal para comprobar la conexión y empezar un nuevo thread. El valor de back_log indica cuántas peticiones pueden almacenarse duarnte este corto espacio de tiempo antes que MySQL temporalmente pare de responder a nuevas peticiones. Necesita incrementarlo sólo si espera un gran número de conexiones en un pequeño lapso de tiempo.

En otras palabras, este valor es el tamaño de la cola que escucha conexiones TCP/IP entrantes. El sistema operativo tiene su propio límite en el tamaño de la cola. La página del manual para la llamada de sistema Unix listen() proporcion más detalles. Consulte la documentación del SO para el máximo valor de esta variable. Intentar cambiar el valor de back_log por encima del límite del sistema operativo no es efectivo.

Gracias amigo, en cualquier caso el servidor es administrado, y la verdad es que funcionan muy bien, siempre que hemos tenido un problema lo han resuelto al poco tiempo. Les facilitaré tu mensaje, aunque imagino que ya lo habrán tenido en cuenta.

También estamos buscando un especialista en vBulletin para revisar tablas y depurar algunos de los procesos automáticos que se ejecutan.

De todos modos, lo poco que entiendo de lo que pones, vienes a decir que es un fallo por un excesivo número de conexiones, el problema no está en que haya más o menos conexiones de usuarios, hemos tenido más de 700 activos de forma simultánea e iba todo como la seda. El problema está en un proceso concreto que colapsa la bbdd durante unos segundos cada XX minutos, y es lo que están buscando.

Newton · 11-feb-2014, 08:55

Cita:

Originalmente publicado por Suko

Gracias amigo, en cualquier caso el servidor es administrado, y la verdad es que funcionan muy bien, siempre que hemos tenido un problema lo han resuelto al poco tiempo. Les facilitaré tu mensaje, aunque imagino que ya lo habrán tenido en cuenta.

También estamos buscando un especialista en vBulletin para revisar tablas y depurar algunos de los procesos automáticos que se ejecutan.

De todos modos, lo poco que entiendo de lo que pones, vienes a decir que es un fallo por un excesivo número de conexiones, el problema no está en que haya más o menos conexiones de usuarios, hemos tenido más de 700 activos de forma simultánea e iba todo como la seda. El problema está en un proceso concreto que colapsa la bbdd durante unos segundos cada XX minutos, y es lo que están buscando.

De nada, a ver si sirve de algo

De todas maneras, no depende del número de conexiones simultáneas sino de las consultas que en su momento haga cualquier proceso contra la BBDD. Cuenta también que las búsquedas del foro consumen muchísimos recursos y los robots otro tanto.

Administro un foro de vBulletin y nos hemos enfrentado con muchos problemas parecidos que a base de "tuning" se han solventado y esos errores vienen normalmente por buffers o por bloqueos de una tabla

Estadisticas de ahora mismo del foro que administro para que veas que es "parecido" a Todocircuito.

Actualmente hay 531 usuarios en línea. 139 miembros y 392 visitantes.
Mayor cantidad de usuarios en un mismo día: 2,044, 05/01/2014 a las 23:17.

Suko · 11-feb-2014, 08:59

Cita:

Originalmente publicado por Newton

De nada, a ver si sirve de algo

De todas maneras, no depende del número de conexiones simultáneas sino de las consultas que en su momento haga cualquier proceso contra la BBDD. Cuenta también que las búsquedas del foro consumen muchísimos recursos y los robots otro tanto.

Administro un foro de vBulletin y nos hemos enfrentado con muchos problemas parecidos que a base de "tuning" se han solventado y esos errores vienen normalmente por buffers o por bloqueos de una tabla

Estadisticas de ahora mismo del foro que administro para que veas que es "parecido" a Todocircuito.

Actualmente hay 531 usuarios en línea. 139 miembros y 392 visitantes.
Mayor cantidad de usuarios en un mismo día: 2,044, 05/01/2014 a las 23:17.

Tienes un privado

Suko · 11-feb-2014, 23:07

Bueno pues Tapatalk activo de nuevo, a ver si ahora va la cosa bien.

Quiero dar las gracias al forero @Newton que se ha tirado media día optimizando cosas del servidor y la bbdd, ¡es un crack el tío!

Inicio de sesión