SUPEE-6788 (Possible) Problèmes de cache


8

Depuis que nous avons appliqué le correctif SUPEE-6788 sur le site d'un client, environ une fois par jour, le site est en panne et la seule chose qui semble le ramener est de vider le cache. Nous avons examiné les journaux, et un tas d'entre eux semblent inclure "Le contrôleur frontal a atteint 100 itérations de correspondance de routeur". Ce problème ne se produisait pas avant l'application du correctif. Quelqu'un a une idée de ce qui pourrait causer cela? Certaines personnes disent que cela pourrait être un bug de cache dans le problème de magento, mais je ne peux pas le dire. Toute entrée serait utile!

Quelques notes supplémentaires:

  • Il n'y a pas eu de lourdes charges sur le serveur au moment où il tombe en panne, donc ce n'est pas un facteur.
  • Oui, tous les correctifs précédents ont été appliqués avec succès.
  • Nous utilisons memcache pour stocker le cache.

Je ne sais pas si cela est lié, mais ce module est spécifique aux performances avec les nouveaux blocs et variables ajoutés à SUPEE-6788 github.com/EcomDev/SUPEE6788-PerformanceFix
David Manners

Comme autre point de données, nous avons un site qui a également rencontré ce problème deux fois jusqu'à présent avec l'erreur d'itérations de correspondance de routeur 100. Il n'a pas commencé avant SUPEE-6788. Après la première fois, j'ai appliqué le patch AmpersandHQ (SUPEE-4755) mais le problème est toujours survenu quelques jours plus tard, donc ce patch n'a pas résolu le problème pour nous. Nous utilisons Magento 1.7.0.2 avec le cache Redis.
Nick

Réponses:


3

Moi et un autre développeur avons rencontré un problème similaire, mais nous semblons l'avoir résolu en appliquant le patch présent dans ce GitHub: https://github.com/AmpersandHQ/magento-ce-ee-config-corruption-bug

La cause semble être une sorte de condition de concurrence critique où le cache est effacé par un processus tout en étant réinstancié par un autre, j'ai pu le reproduire en suivant les étapes également répertoriées sur ce GitHub.

J'ai ouvert un ticket de support avec Magento pour ce problème et j'ai mes soupçons sur ce qui a commencé à le provoquer depuis le patch, mais j'attends de les entendre.

Vous pouvez en savoir plus à ce sujet sur la question suivante: problèmes avec la page sans style, chemins d'accès incorrects, perte de configuration de la mise en page après l'application du correctif SUPEE-6788 .


Ce correctif a-t-il été testé sur 1.8.1.0 avec SUPEE-6788 installé?
Daryl Gochnauer

@ dgwexdev13 Je ne l'ai pas testé sur 1.8, mais j'ai développé le patch sur 1.9 et 1.13 simultanément. Je ne pense pas que le module en question (Mage_Core_Model_Config) ait changé depuis longtemps alors le patch devrait à peu près s'appliquer à toutes les versions. J'ai vu ce correctif fonctionner avec bonheur avec les systèmes 1,12, 1,13, 1,14 avec SUPEE 6788 installé.
Luke Rodgers

Ps - Veuillez mettre à jour ici si / quand vous avez des nouvelles de Magento. Merci
Daryl Gochnauer

Je crains que l'application de SUPEE-4755 avec SUPEE-6788 ne fasse pas grand-chose pour arrêter les erreurs "100 itérations atteintes". J'ai appliqué les deux à un certain nombre de sites Web non liés et je continue de voir des plantages occasionnels sur chacun d'eux. Quelqu'un a-t-il eu plus de chance?
Jan Tomka

1

Nous avons le même problème avec la version 1.8.1 de 3 sites. Il a commencé à apparaître après SUPEE 6788. Le correctif ci-dessus n'a pas résolu le problème. En fait, il semble qu'il y ait un changement. Avant le correctif, les sites se bloquaient deux fois par jour, maintenant le dernier crash était après 2 jours. Mais c'est peut-être lié à la charge. Les 3 sites sont petits et peu chargés. Ce problème n'apparaît pas avec un grand site qui est la version 1.6.2 et SUPEE 6788 appliqué. Tous les sites sont sur le même serveur - le 3 avec la version 1.8.1 et le grand avec la version 1.6.2


Cela ne fournit pas de réponse, mieux adapté à un commentaire. Vous devriez poser de bonnes questions et fournir de bonnes réponses sur le site. Lorsque vous gagnez suffisamment de réputation, vous pourrez également publier des commentaires.
Prateek

1
oui, je comprends, mais quand j'essaye de commenter j'ai un message "Vous devez avoir 50 points de réputation pour commenter". Et je pense qu'il est important que cela se produise également sur d'autres sites. Et semble être spécifique à la version.
Dimitar Dimitrov

@DimitarDimitrov essentiellement la même chose - nous avons eu une journée bien remplie mardi et le site est tombé environ une fois par heure. En déplaçant le cache de configuration hors de Redis et en utilisant simplement la mise en cache de la base de fichiers (j'utilise toujours Redis pour FPC), j'ai pu stabiliser le magasin.
Phil Birnie

Après le grand magasin avec la version 1.6.2. s'est écrasé plusieurs fois avec une erreur différente: "Schéma illégal fourni, seuls les caractères alphanumériques sont autorisés" nous avons été contraints de rétablir le correctif. 24 heures depuis lors, aucun plantage et tous nos magasins sont stables. Je n'aime vraiment pas l'idée de travailler sans le patch, nous essayons de trouver la raison d'une installation de test, mais le problème est qu'elle ne plante pas. Probablement de vraies actions sont nécessaires pour le planter et je ne sais pas exactement. Nous avons essayé de provoquer le crash avec ab mais cela ne semble pas être lié à la charge.
Dimitar Dimitrov

J'ai oublié de mentionner que nous utilisons une simple mise en cache basée sur des fichiers. Le serveur est avec php 5.4 et opcache, mais la désactivation de la mise en cache php n'aide pas
Dimitar Dimitrov

1

Nous avons fait passer le cache du site de memcache à Redis, puis ajouté un cronjob pour vider le cache toutes les 12 heures. Il est passé de l'écrasement une fois par jour à environ 4-5 jours avant de redescendre. Nous avons ensuite modifié le cronjob pour vider toutes les 6 heures et il n'a pas baissé depuis (cela fait environ 3-4 jours depuis). Ni nous ni la société d'hébergement ne pouvons retrouver le problème réel, mais cela semble être une solution de travail pour nous. J'espère que cela aide quelqu'un.


Je vous recommande de saisir le formulaire de journalisation ici: github.com/AmpersandHQ/… De cette façon, vous verrez quel morceau de code déclenche continuellement des sauvegardes de corruption de cache de configuration.
Luke Rodgers

1

J'ai ajouté le code de débogage AmpersandHQ ce matin et tout à l'heure, l'exception «Le contrôleur frontal a atteint 100 itérations de correspondance de routeur» s'est produite environ 75 fois en 2 minutes. Mais cette fois, probablement parce que le code de débogage n'a pas enregistré l'entrée de cache corrompue, le site est toujours en place sans que tout le monde ne reçoive d'exceptions (je n'ai pas vidé le cache).

Je n'ai pas encore creusé cela pour enquêter, mais corrupt-cache.log contient:

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}

C'est sur Magento 1.7.0.2 avec le cache Redis et le correctif SUPEE-4755 d'AmpersandHQ déjà appliqué.


Mise à jour du 2 décembre 2015: voici une autre erreur avec la trace de pile complète:

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')

Compagnon fantastique. Merci d'avoir posté la trace de votre pile. Pourriez-vous s'il vous plaît lire cet essentiel? gist.github.com/convenient/2a30572d6d4bcae9796c J'ai une idée pour le réduire, qu'il s'agisse d'une useCache = trueerreur de cache d'objets ou de quelque chose d'autre.
Luke Rodgers

OK, j'ai patché ces fichiers supplémentaires. Merci pour le travail sur les patchs. Hier soir, après avoir posté, l'erreur s'est produite deux fois de plus en 30 minutes. Mais ensuite, cela ne s'est pas produit en 15 heures. Je ne sais donc pas vraiment comment prédire quand cela pourrait se reproduire.
Nick

D'accord, tenez-moi au courant. Merci
Luke Rodgers

J'ai eu 2 autres erreurs de correspondance de routeur 100 après avoir appliqué le patch supplémentaire que vous m'avez donné dans l'essentiel. Cela n'a donc pas réglé le problème. Après le premier, j'ai légèrement modifié le code de débogage pour donner la trace de la pile entière au lieu de la PHP tronquée. Je n'avais pas de place dans mon commentaire ici, j'ai donc modifié mon message d'origine ci-dessus pour inclure la nouvelle trace.
Nick

C'est donc une erreur dans le thème du module "find". Notre site n'utilise pas le module de recherche, et il semble que cette entreprise soit maintenant disparue de toute façon (mais le module était livré avec Magento par défaut), j'ai donc désactivé le module à l'avenir. Je ne sais pas si cela résoudra le problème ou s'il apparaîtra à nouveau en répertoriant un thème différent.
Nick

1

Nous rencontrons le même problème depuis des semaines avec divers sites Web Magento CE. Cependant, aucune des suggestions affichées ici n'a aidé. Après plusieurs séances de débogage frustrantes sur plusieurs semaines, nous avons finalement réussi à le déterminer.

En résumé, nous avons constaté que le problème était dû à une combinaison du correctif SUPEE-6788, Magento <1.9.2.0 et PHP> = 5.5.22, avec des attaquants potentiels ou même des scanners de sécurité capables de supprimer les sites à la demande. Nous avons publié tous les détails, y compris un correctif, sur notre blog . J'espère vraiment que cela aidera toutes les autres pauvres âmes souffrant du même problème.


0

Nous rencontrons ce problème et nos sites Web depuis la publication de SUPEE6788 et il semble que les appels frauduleux aux services Web xmlrpc pourraient être responsables de la corruption du cache.

Nous bloquons les appels de service Web de nos serveurs frontaux car nous ne les utilisons pas + en appliquant SUPEE 4755, je vous tiendrai au courant.


Ce correctif a modifié la validation xml à utiliser, libxml_disable_entity_loaderce qui n'est pas sûr pour les threads. Dans certains cas, cela peut entraîner la redirection de Magento vers la page d'installation, mais je pense qu'il est également possible qu'avant des erreurs comme celle-ci, il manque l'étape loadDB de la génération de configuration, enregistrant les données corrompues dans le cache. Voir magento.stackexchange.com/questions/30071/…
Luke Rodgers
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.