Cron crash MySQL

Setelah pindah ke server baru saya mendapatkan masalah MySQL crash [1] sekali sehari, yang datang ke email saya dan mengganggu belum lagi dampak potensial. Adakah petunjuk tentang cara men-debug masalah ini?

Jelas crash terjadi $schedule->save()jadi saya mencoba untuk membungkusnya dengan mencoba ... menangkap tetapi itu tidak membantu

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}

Pengaturan batas waktu:

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
sumber

Ini adalah PHP yang kehilangan koneksi dengan MySQL. Mengetahui magento mungkin karena file cron.php membutuhkan waktu berjam-jam untuk dijalankan. Coba lihat pengaturan waktu tunggu MySQL Anda ...

— Matt Humphrey

Bisakah Anda memeriksa LOG mysql! kemungkinan besar mysql mogok dan memulai kembali setelah Anda mencoba untuk menanyakan tabel itu

— Meabed

@MattHumphrey masalah adalah ini terjadi hanya sekali sehari sementara cron.php berjalan setiap 15 menit, waktu tunggu sudah cukup tinggi

— Zifius

Saya tidak berpikir ini adalah pertanyaan khusus Magento. Apa yang Anda gambarkan adalah batas waktu koneksi pada server MySQL, yang biasanya dipulihkan dengan menetapkan opsi koneksi kembali pada koneksi dan melakukan ping server sebelum digunakan. Saya akan melihat konfigurasi MySQL Anda ( my.cnf) untuk melihat batas waktu dan meningkatkannya. Lihat stackoverflow.com/questions/4284194/… untuk detailnya.

— Karlson

@Zifius Apa pengaturan batas waktu?

— Karlson

Jawaban:

Seperti yang orang lain katakan itu kemungkinan dipicu oleh skrip yang berjalan lama. Skrip apa pun yang membutuhkan waktu lama untuk berjalan tanpa menggunakan database dapat berpotensi habis.

Saya pernah mengalami ini sebelumnya. Kami memiliki skrip yang menghubungkan ke server jarak jauh, mengunduh beberapa ratus file xml, mem-parsing dan mengonversinya menjadi file .csv untuk diimpor melalui modul Magento ImportExport bawaan. Kami memiliki modul log kustom, yang memungkinkan kami untuk melacak apa yang terjadi dengan rutinitas kami. Hal pertama yang dilakukan kelas adalah menambahkan baris ke tabel log ini untuk mengatakan rutin dimulai. Kemudian diperlukan 5-10 menit untuk mengambil file xml jarak jauh. Setelah mengunduh file itu mencoba untuk menulis entri log lain untuk mengatakan bahwa itu selesai. Karena koneksi mysql telah dibuka sejak peristiwa log pertama dan belum digunakan sejak saat itu, mysql telah menutup koneksi karena tidak menerima permintaan lebih lama dari periode waktu habis.

— Peter O'Callaghan
sumber

Ya, sepertinya pelakunya memperhitungkan bahwa pekerjaan cron dijalankan di atas garis yang menyimpan entri. Menambahkan lebih banyak log untuk mencari tahu pekerjaan mana yang

— Zifius

Dalam upaya Anda /etc/mysql/my.cnfmeningkatkan nilai untukmax_allowed_packet

Misalnya.

max_allowed_packet = 256M

Kemudian restart MySQL.

— Ben Lessani - Sonassi
sumber

Saat ini di 64M, akan mencoba meningkat. Saya juga melihat banyak "Sudah terlambat untuk jadwal." pengecualian, pasti pekerjaan berat yang berjalan terlalu lama

— Zifius

Perayap FPC yang dinonaktifkan sesuai rekomendasi Anda dalam pertanyaan lain, mari kita lihat bagaimana hasilnya

— Zifius

Ini adalah penyebab paling sering masalah ketika kita mengalami kesalahan ini.

— davidalger

Jika Anda bertanya kepada saya, itu bukan ide yang baik untuk menjaga koneksi mysql terbuka selama berjam-jam. Jadi alternatifnya adalah, untuk memeriksa, apakah koneksi masih ada, jika tidak, buka yang baru.

— Fabian Blechschmidt
sumber

Ini adalah kode inti, tetapi ya, Anda benar :) Hanya perlu melacak pekerjaan yang berjalan begitu lama sekarang

— Zifius

mungkin ada pengamat yang dapat Anda gunakan untuk memeriksa, apakah koneksi ada?

— Fabian Blechschmidt

Saya pikir saya hanya perlu mencari dan memperbaiki pekerjaan itu :)

— Zifius

Bergantung pada berapa banyak tampilan toko, kategori dan produk yang Anda miliki, ini bisa menjadi pengindeks dan ini mungkin hanya memakan waktu. Tapi ya, "perbaiki saja pekerjaannya" dan masalahnya hilang: D

— Fabian Blechschmidt