Cron вылетает MySQL

После перехода на новый сервер я получаю проблему сбоя MySQL [1] один раз в день, которая приходит на мою электронную почту и раздражает, не говоря уже о потенциальном воздействии. Любые советы о том, как отладить эту проблему?

Очевидно, происходит сбой, $schedule->save()поэтому я попытался обернуть его с попыткой ... поймать, но это не помогло

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}

Настройки тайм-аута:

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)

database error

— Zifius
источник

Это PHP теряет связь с MySQL. Знание magento возможно потому, что запуск файла cron.php занимает несколько часов. Попробуйте посмотреть настройки тайм-аута MySQL ...

— Мэтт Хамфри,

Не могли бы вы проверить mysql LOG! наиболее вероятный сбой и повторный

— запуск

Проблема @MattHumphrey в том, что это происходит только один раз в день, в то время как cron.php запускается каждые 15 минут, время ожидания уже довольно велико

— Zifius,

Я не думаю, что это специфический для Magento вопрос. То, что вы описываете, - это тайм-аут соединения на сервере MySQL, который обычно восстанавливается установкой опции повторного соединения для соединения и проверкой связи с сервером перед использованием. Я бы посмотрел на вашу конфигурацию MySQL ( my.cnf), чтобы узнать, каково время ожидания и как его увеличить. См. Stackoverflow.com/questions/4284194/… для получения подробной информации.

— Карлсон

@Zifius Каковы настройки времени ожидания?

— Карлсон

Ответы:

Как уже говорили другие, это, вероятно, вызвано длительным сценарием. Любой сценарий, выполнение которого занимает много времени без использования базы данных, может потенциально истечь.

У меня было это раньше. У нас есть скрипт, который подключается к удаленному серверу, загружает несколько сотен XML-файлов, анализирует и преобразует их в CSV-файл для импорта через встроенный модуль Magento ImportExport. У нас есть специальный модуль регистрации, который позволяет нам отслеживать, что произошло с нашими процедурами. Самое первое, что делает класс, это добавляет строку в эту таблицу журнала, чтобы сказать, что подпрограмма запущена. Затем для извлечения удаленных XML-файлов требуется 5-10 минут. После загрузки файлов он пытается написать еще одну запись в журнале, чтобы сказать, что она закончена. Поскольку соединение mysql было открыто с момента первого события журнала и с тех пор не использовалось, mysql закрыло соединение, так как оно не получало никаких запросов дольше, чем время ожидания.

— Питер О'Каллаган
источник

Да, похоже, виновник принимает во внимание, что задания cron выполняются выше линии, которая сохраняет запись. Добавлена дополнительная регистрация, чтобы узнать, какая это работа

— Zifius

В вашей /etc/mysql/my.cnfпопытке увеличить значение дляmax_allowed_packet

Например.

max_allowed_packet = 256M

Затем перезапустите MySQL.

— Бен Лессани - Сонасси
источник

Прямо сейчас на 64M, попробую увеличить. Я также вижу много «слишком поздно для графика». исключения, должно быть какая-то тяжелая работа, выполняемая слишком долго

— Zifius

Отключил сканер FPC в соответствии с вашей рекомендацией в другом вопросе, давайте посмотрим, как это будет

— Zifius

Это самая частая причина проблемы, когда мы сталкиваемся с этой ошибкой.

— Давидгер

Если вы спросите меня, не стоит держать соединение mysql открытым в течение нескольких часов. Таким образом, альтернатива состоит в том, чтобы проверить, существует ли еще соединение, если нет, откройте новое.

— Фабиан Блехшмидт
источник

Это основной код, но да, вы правы :) Просто нужно отследить работу, которая теперь выполняется так долго

— Zifius

может быть, есть наблюдатель, которого вы можете использовать, чтобы проверить, существует ли связь?

— Фабиан Блехшмидт

Я думаю, что мне просто нужно найти и исправить эту работу :)

— Zifius

В зависимости от количества просмотров магазина, категорий и продуктов, он может быть индексатором, и это может занять некоторое время. Но да, «просто починить работу» и проблема исчезла: D

— Фабиан Блехшмидт