SUPEE-6788 (Kemungkinan) Masalah Cache

8

Sejak kami menerapkan tambalan SUPEE-6788 di situs klien, sekitar sekali sehari situs tersebut telah turun & satu-satunya hal yang tampaknya mengembalikannya adalah menghapus cache. Kami telah melihat log, & banyak dari mereka tampaknya termasuk "Pengontrol depan mencapai 100 iterasi pertandingan router". Masalah ini tidak terjadi sebelum tambalan diterapkan. Adakah yang tahu apa yang menyebabkan ini? Beberapa orang mengatakan itu bisa jadi bug cache dalam masalah magento, tapi saya tidak tahu. Setiap masukan akan sangat membantu!

Beberapa catatan tambahan:

  • Belum ada beban berat di server saat itu turun, jadi itu bukan faktor.
  • Ya, semua tambalan sebelumnya berhasil diterapkan.
  • Kami menggunakan memcache untuk menyimpan cache.
Daryl Gochnauer
sumber
Tidak yakin apakah ini terkait tetapi modul ini khusus untuk kinerja dengan blok baru dan variabel ditambahkan ke SUPEE-6788 github.com/EcomDev/SUPEE6788-PerformanceFix
David Manners
Sebagai titik data lain, kami memiliki situs yang juga memiliki masalah ini menurunkan situs dua kali sejauh ini dengan 100 kesalahan iterasi pertandingan router. Itu tidak mulai sampai SUPEE-6788. Setelah pertama kali saya menerapkan tambalan AmpersandHQ (SUPEE-4755) tetapi masalah masih terjadi beberapa hari kemudian, sehingga tambalan tidak memperbaiki masalah bagi kami. Kami menjalankan Magento 1.7.0.2 dengan cache Redis.
Nick

Jawaban:

3

Saya dan pengembang lain telah mengalami masalah serupa, namun kami tampaknya telah menyelesaikannya dengan menerapkan tambalan yang ada di GitHub ini: https://github.com/AmpersandHQ/magento-ce-ee-config-corruption-bug

Penyebabnya tampaknya semacam kondisi balapan di mana cache dihapus oleh satu proses saat sedang instantiated oleh yang lain, saya sudah bisa mereproduksi dengan mengikuti langkah-langkah yang juga tercantum pada GitHub itu.

Saya telah membuka tiket dukungan dengan Magento untuk masalah ini dan memiliki kecurigaan saya tentang apa yang mulai menyebabkannya sejak tambalan, tetapi saya menunggu untuk mendengar kembali.

Anda dapat membaca lebih lanjut tentang hal ini pada pertanyaan berikut: Masalah dengan Halaman Tidak Bergaya, Jalur Buruk, hilangnya konfigurasi tata letak setelah penerapan SUPEE-6788 Patch .

Persata
sumber
Apakah perbaikan ini telah diuji pada 1.8.1.0 w / SUPEE-6788 diinstal?
Daryl Gochnauer
@ dgwexdev13 Saya belum mengujinya di 1.8, tapi saya mengembangkan patch pada 1.9 dan 1.13 secara bersamaan. Saya tidak berpikir modul yang dimaksud (Mage_Core_Model_Config) telah berubah dalam PANJANG sementara jadi tambalan seharusnya cukup banyak berlaku untuk semua versi. Saya telah melihat tambalan ini berjalan dengan gembira dengan sistem 1,12, 1,13, 1,14 dengan SUPEE 6788 diinstal.
Luke Rodgers
Ps - Tolong lakukan pembaruan di sini jika / ketika Anda mendengar kabar dari Magento. Terima kasih
Daryl Gochnauer
Saya takut menerapkan SUPEE-4755 bersama dengan SUPEE-6788 tidak berbuat banyak untuk menghentikan kesalahan "100 iterasi tercapai". Saya telah menerapkan keduanya pada sejumlah situs web yang tidak terkait dan saya sering melihat crash pada semuanya. Adakah yang lebih beruntung?
Jan Tomka
1

Kami memiliki masalah yang sama dengan 3 situs versi 1.8.1. Itu mulai muncul setelah SUPEE 6788. Perbaikan dari atas tidak menyelesaikan masalah. Sebenarnya, sepertinya ada beberapa perubahan. Sebelum perbaikan, situs mengalami crash dua kali sehari, sekarang crash terakhir adalah setelah 2 hari. Tapi mungkin itu terkait dengan beban. 3 situs kecil dan tidak terlalu dimuat. Masalah ini tidak muncul dengan situs besar yang versi 1.6.2 dan SUPEE 6788 diterapkan. Semua situs berada di server yang sama - 3 dengan versi 1.8.1 dan yang besar dengan versi 1.6.2

Dimitar Dimitrov
sumber
Ini tidak memberikan jawaban, lebih cocok untuk komentar. Anda harus mengajukan beberapa pertanyaan bagus dan memberikan beberapa jawaban bagus di situs. Ketika Anda mendapatkan reputasi yang cukup, Anda juga dapat memposting komentar.
Prateek
1
ya, saya mengerti, tetapi ketika saya mencoba untuk berkomentar saya memiliki pesan "Anda harus memiliki 50 reputasi untuk berkomentar". Dan saya pikir ini adalah informasi penting bahwa ini terjadi pada situs lain juga. Dan tampaknya versi spesifik.
Dimitar Dimitrov
@DimitarDimitrov pada dasarnya hal yang sama - kami memiliki hari yang sibuk pada hari Selasa dan situs turun sekitar satu kali per jam. Dengan memindahkan cache konfigurasi Redis dan hanya menggunakan caching basis file (Saya masih menggunakan Redis untuk FPC), saya dapat menstabilkan toko.
Phil Birnie
Setelah toko besar dengan versi 1.6.2. jatuh berkali-kali dengan kesalahan berbeda: "Skema ilegal disediakan, hanya karakter alfanumerik yang diizinkan" kami terpaksa mengembalikan tambalan. 24 jam sejak itu tidak ada crash dan semua toko kami stabil. Saya benar-benar tidak suka ide bekerja tanpa tambalan, kami mencoba menemukan alasannya dengan satu instalasi pengujian, tetapi masalahnya adalah tidak macet. Mungkin tindakan nyata diperlukan untuk menghentikannya dan saya tidak tahu persis mana. Kami mencoba memprovokasi crash dengan ab tetapi tampaknya tidak terkait beban.
Dimitar Dimitrov
Saya lupa menyebutkan kami menggunakan caching berbasis file sederhana. Server menggunakan php 5.4 dan opcache, tetapi menonaktifkan caching php apa pun tidak membantu
Dimitar Dimitrov
1

Kami meminta cache situs beralih dari memcache ke Redis & kemudian menambahkan cronjob untuk membuang cache setiap 12 jam. Mulai dari mogok sekali sehari menjadi sekitar 4-5 hari sebelum turun lagi. Kami kemudian men-tweak cronjob untuk dibuang setiap 6 jam & itu belum turun sejak (sudah sekitar 3-4 hari sejak). Baik kami atau perusahaan hosting dapat melacak masalah yang sebenarnya, tetapi ini tampaknya merupakan perbaikan yang baik bagi kami. Semoga itu bisa membantu seseorang.

Daryl Gochnauer
sumber
Saya sarankan Anda memasukkan formulir logging di sini: github.com/AmpersandHQ/... Dengan begitu Anda akan melihat potongan kode apa yang terus-menerus memicu cache penyimpanan konfigurasi yang disimpan.
Luke Rodgers
1

Saya menambahkan kode debug AmpersandHQ pagi ini dan baru saja ada pengecualian "Pengontrol depan mencapai 100 router cocok iterasi" terjadi sekitar 75 kali dalam periode 2 menit. Tapi kali ini, mungkin karena kode debug tidak menyimpan entri cache yang korup, situs masih naik tanpa semua orang mendapatkan pengecualian (saya tidak membersihkan cache).

Saya belum menggali hal ini untuk menyelidiki tetapi corrupt-cache.log berisi:

2015-11-22T03:42:42+00:00 DEBUG (7):
#0 app/code/core/Mage/Core/Model/App.php(1147): Mage_Core_Model_Cache->save('<admin><design>...', 'config_global_s...', Array, NULL)
#1 app/code/core/Mage/Core/Model/Config.php(552): Mage_Core_Model_App->saveCache('<admin><design>...', 'config_global_s...', Array, NULL)
#2 app/code/core/Mage/Core/Model/Config.php(474): Mage_Core_Model_Config->_saveCache('<admin><design>...', 'config_global_s...', Array, NULL)
#3 app/code/core/Mage/Core/Model/App.php(421): Mage_Core_Model_Config->saveCache()
#4 app/code/core/Mage/Core/Model/App.php(343): Mage_Core_Model_App->_initModules()
#5 app/Mage.php(683): Mage_Core_Model_App->run(Array)
#6 index.php(87): Mage::run('', 'store')
#7 {main}

Ini ada di Magento 1.7.0.2 dengan cache Redis dan patch SUPEE-4755 AmpersandHQ sudah diterapkan.


Pembaruan 2 Des 2015: Ini adalah kesalahan lain dengan jejak tumpukan penuh:

2015-12-02T20:02:27+00:00 DEBUG (7):
#0 app/code/local/Mage/Core/Model/App.php(1156): save('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#1 app/code/local/Mage/Core/Model/Config.php(552): saveCache('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#2 app/code/local/Mage/Core/Model/Config.php(474): _saveCache('<admin><design><package><name>default</name></package><theme><default>find</default></theme></design></admin>', 'config_global_stores_admin', Array, NULL)
#3 app/code/local/Mage/Core/Model/App.php(430): saveCache()
#4 app/code/local/Mage/Core/Model/App.php(343): _initModules()
#5 app/Mage.php(683): run(Array)
#6 index.php(87): run('', 'store')
Nick
sumber
Teman yang fantastis. Terima kasih telah mengirim jejak tumpukan yoru. Bisakah Anda membaca intisari ini? gist.github.com/convenient/2a30572d6d4bcae9796c Saya punya ide untuk mempersempitnya menjadi apakah itu useCache = truekesalahan cache objek atau sesuatu yang lain sama sekali.
Luke Rodgers
OK saya tambal file-file tambahan itu. Terima kasih atas pekerjaan Anda di patch. Tadi malam setelah saya memposting, kesalahan terjadi dua kali lagi dalam periode 30 menit. Tapi kemudian setelah itu belum terjadi dalam 15 jam. Jadi saya tidak begitu yakin bagaimana memperkirakan kapan itu akan terjadi lagi.
Nick
Oke keren, tolong tetap up to date. Terima kasih
Luke Rodgers
Saya mendapat 2 kesalahan 100 router yang cocok setelah menerapkan tambalan tambahan yang Anda berikan pada saya. Jadi itu tidak memperbaiki masalah. Setelah yang pertama, saya sedikit memodifikasi kode debug untuk memberikan seluruh jejak stack bukannya yang PHP terpotong. Saya tidak punya ruang dalam komentar saya di sini jadi saya memodifikasi posting asli saya di atas untuk memasukkan jejak baru.
Nick
Jadi ada kesalahan dalam tema modul "find". Situs kami tidak menggunakan modul find, dan sepertinya perusahaan itu sekarang sudah tidak berfungsi lagi (tapi modulnya dulu dikirim dengan Magento secara default), jadi saya menonaktifkan modul itu ke depan. Tidak yakin apakah itu akan memperbaiki masalah atau apakah itu hanya akan muncul lagi daftar tema yang berbeda.
Nick
1

Kami telah mengalami masalah yang sama selama berminggu-minggu sekarang dengan berbagai situs web Magento CE. Namun, tidak ada saran yang diposting di sini yang membantu. Setelah beberapa sesi debug yang mengecewakan selama beberapa minggu, kami akhirnya berhasil mengatasinya.

Singkatnya, kami menemukan masalah karena kombinasi dari tambalan SUPEE-6788, Magento <1.9.2.0 dan PHP> = 5.5.22, dengan penyerang potensial atau bahkan pemindai keamanan dapat membuat situs turun sesuai permintaan. Kami telah memposting detail lengkap, termasuk perbaikan, di blog kami . Saya benar-benar berharap ini membantu jiwa-jiwa miskin lainnya yang menderita dengan masalah yang sama.

mustdobetter
sumber
0

Kami mengalami masalah ini dan situs web kami sejak kami merilis SUPEE6788 dan tampaknya panggilan penipuan ke layanan web xmlrpc dapat bertanggung jawab atas korupsi cache.

Kami memblokir panggilan layanan web dari server depan kami karena kami tidak menggunakannya + menerapkan SUPEE 4755, saya akan membuat Anda tetap diposting.

TERAS
sumber
Tambalan ini memang memodifikasi validasi xml untuk digunakan libxml_disable_entity_loaderyang bukan utas aman. Dalam beberapa contoh ini dapat menyebabkan Magento untuk mengarahkan ulang ke halaman instalasi, namun saya percaya itu juga mungkin bahwa sebelum kesalahan seperti ini, bahwa itu akan kehilangan langkah loadDB dari generasi konfigurasi, menyimpan data yang rusak ke dalam cache. Lihat magento.stackexchange.com/questions/30071/…
Luke Rodgers