Cron bloquea MySQL

8

Después de mudarme a un nuevo servidor, recibo el problema de bloqueo de MySQL [1] una vez al día, que llega a mi correo electrónico y es molesto sin mencionar el impacto potencial. ¿Alguna pista sobre cómo depurar este problema?

Obviamente, el bloqueo ocurre, $schedule->save()así que intenté envolverlo con un intento ... atrapar pero eso no ayudó

SQLSTATE[HY000]: General error: 2006 MySQL server has gone away
Trace:
#0 /var/www/vhosts/site/store/lib/Zend/Db/Adapter/Pdo/Abstract.php(305): PDO->beginTransaction()
#1 /var/www/vhosts/site/store/lib/Zend/Db/Adapter/Abstract.php(495): Zend_Db_Adapter_Pdo_Abstract->_beginTransaction()
#2 /var/www/vhosts/site/store/lib/Varien/Db/Adapter/Pdo/Mysql.php(219): Zend_Db_Adapter_Abstract->beginTransaction()
#3 /var/www/vhosts/site/store/app/code/core/Mage/Core/Model/Resource/Abstract.php(76): Varien_Db_Adapter_Pdo_Mysql->beginTransaction()
#4 /var/www/vhosts/site/store/app/code/core/Mage/Core/Model/Abstract.php(313): Mage_Core_Model_Resource_Abstract->beginTransaction()
#5 /var/www/vhosts/site/store/app/code/core/Mage/Cron/Model/Observer.php(125): Mage_Core_Model_Abstract->save()
#6 /var/www/vhosts/site/store/app/code/core/Mage/Core/Model/App.php(1338): Mage_Cron_Model_Observer->dispatch(Object(Varien_Event_Observer))
#7 /var/www/vhosts/site/store/app/code/core/Mage/Core/Model/App.php(1317): Mage_Core_Model_App->_callObserverMethod(Object(Mage_Cron_Model_Observer), 'dispatch', Object(Varien_Event_Observer))
#8 /var/www/vhosts/site/store/app/Mage.php(447): Mage_Core_Model_App->dispatchEvent('default', Array)
#9 /var/www/vhosts/site/store/cron.php(46): Mage::dispatchEvent('default')
#10
{main}

Configuración de tiempo de espera:

mysql> show global variables like '%timeout%';
+----------------------------+----------+
| Variable_name              | Value    |
+----------------------------+----------+
| connect_timeout            | 10       |
| delayed_insert_timeout     | 300      |
| innodb_lock_wait_timeout   | 50       |
| innodb_rollback_on_timeout | OFF      |
| interactive_timeout        | 30       |
| lock_wait_timeout          | 31536000 |
| net_read_timeout           | 30       |
| net_write_timeout          | 60       |
| slave_net_timeout          | 3600     |
| wait_timeout               | 3600     |
+----------------------------+----------+
10 rows in set (0.00 sec)
Zifius
fuente
1
Esto es PHP perdiendo su conexión con MySQL. Conocer magento es probablemente porque el archivo cron.php tarda horas en ejecutarse. Intente mirar la configuración de tiempo de espera de MySQL ...
Matt Humphrey
¿Podrías consultar mysql LOG! lo más probable es que mysql falle y se reinicie una vez que intente consultar esa tabla
Meabed
El problema de @MattHumphrey es que solo ocurre una vez al día, mientras que cron.php se ejecuta cada 15 minutos, los tiempos de espera ya son bastante altos
Zifius
1
No creo que esta sea una pregunta específica de Magento. Lo que está describiendo es un tiempo de espera de conexión en un servidor MySQL, que normalmente se restaura configurando una opción de reconexión en la conexión y haciendo ping al servidor antes de usarlo. Vería su configuración de MySQL ( my.cnf) para ver cuál es el tiempo de espera y aumentarlo. Consulte stackoverflow.com/questions/4284194/… para más detalles.
Karlson
@Zifius ¿Cuáles son las configuraciones de tiempo de espera?
Karlson

Respuestas:

5

Como otros han dicho, es probable que sea provocado por un script de larga ejecución. Cualquier script que demore mucho tiempo en ejecutarse sin usar la base de datos puede potencialmente agotar el tiempo de espera.

Me ha pasado esto antes. Tenemos un script que se conecta a un servidor remoto, descarga algunos cientos de archivos xml, los analiza y los convierte en un archivo .csv para importarlos a través del módulo Magento ImportExport integrado. Tenemos un módulo de registro personalizado, que nos permite rastrear lo que sucedió con nuestras rutinas. Lo primero que hace la clase es agregar una fila a esta tabla de registro para decir que la rutina comenzó. Luego toma de 5 a 10 minutos recuperar los archivos xml remotos. Después de descargar los archivos, intenta escribir otra entrada de registro para decir que ha terminado. Dado que la conexión mysql ha estado abierta desde el primer evento de registro y no se ha utilizado desde entonces, mysql ha cerrado la conexión ya que no ha recibido ninguna consulta durante más tiempo que el tiempo de espera.

Peter O'Callaghan
fuente
Sí, parece ser el culpable teniendo en cuenta que los trabajos cron se ejecutan por encima de la línea que guarda la entrada. Se agregó más registro para averiguar qué trabajo es ese
Zifius
3

En su /etc/mysql/my.cnfintento de aumentar el valor demax_allowed_packet

P.ej.

max_allowed_packet = 256M

Luego reinicie MySQL.

Ben Lessani - Sonassi
fuente
En este momento está a 64M, intentará aumentar. También veo mucho "demasiado tarde para el horario". excepciones, debe ser un trabajo pesado corriendo demasiado tiempo
Zifius
Rastreador de FPC deshabilitado según su recomendación en otra pregunta, veamos cómo funciona
Zifius
Esta es la causa más frecuente del problema cuando nos encontramos con este error.
davidalger
1

Si me preguntas, no es una buena idea mantener una conexión mysql abierta durante horas. Entonces, la alternativa es, para verificar, si la conexión aún existe, si no, abra una nueva.

Fabian Blechschmidt
fuente
Es un código central, pero sí, tienes razón :) Solo necesito rastrear el trabajo que se ejecuta tanto tiempo ahora
Zifius
tal vez hay un observador que puede usar para verificar, si existe la conexión?
Fabian Blechschmidt
Creo que solo necesito encontrar y arreglar ese trabajo :)
Zifius
Dependiendo de la cantidad de vistas de tienda, categorías y productos que tenga, puede ser un indexador y esto puede llevar tiempo. Pero sí, "solo arregle el trabajo" y el problema desaparece: D
Fabian Blechschmidt