Cron вылетает MySQL

8

После перехода на новый сервер я получаю проблему сбоя 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)
Zifius
источник
1
Это PHP теряет связь с MySQL. Знание magento возможно потому, что запуск файла cron.php занимает несколько часов. Попробуйте посмотреть настройки тайм-аута MySQL ...
Мэтт Хамфри,
Не могли бы вы проверить mysql LOG! наиболее вероятный сбой и повторный
запуск
Проблема @MattHumphrey в том, что это происходит только один раз в день, в то время как cron.php запускается каждые 15 минут, время ожидания уже довольно велико
Zifius,
1
Я не думаю, что это специфический для Magento вопрос. То, что вы описываете, - это тайм-аут соединения на сервере MySQL, который обычно восстанавливается установкой опции повторного соединения для соединения и проверкой связи с сервером перед использованием. Я бы посмотрел на вашу конфигурацию MySQL ( my.cnf), чтобы узнать, каково время ожидания и как его увеличить. См. Stackoverflow.com/questions/4284194/… для получения подробной информации.
Карлсон
@Zifius Каковы настройки времени ожидания?
Карлсон

Ответы:

5

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

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

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

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

Например.

max_allowed_packet = 256M

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

Бен Лессани - Сонасси
источник
Прямо сейчас на 64M, попробую увеличить. Я также вижу много «слишком поздно для графика». исключения, должно быть какая-то тяжелая работа, выполняемая слишком долго
Zifius
Отключил сканер FPC в соответствии с вашей рекомендацией в другом вопросе, давайте посмотрим, как это будет
Zifius
Это самая частая причина проблемы, когда мы сталкиваемся с этой ошибкой.
Давидгер
1

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

Фабиан Блехшмидт
источник
Это основной код, но да, вы правы :) Просто нужно отследить работу, которая теперь выполняется так долго
Zifius
может быть, есть наблюдатель, которого вы можете использовать, чтобы проверить, существует ли связь?
Фабиан Блехшмидт
Я думаю, что мне просто нужно найти и исправить эту работу :)
Zifius
В зависимости от количества просмотров магазина, категорий и продуктов, он может быть индексатором, и это может занять некоторое время. Но да, «просто починить работу» и проблема исчезла: D
Фабиан Блехшмидт