SUPEE-6788 (Posible) Problemas de caché

8

Desde que aplicamos el parche SUPEE-6788 en el sitio de un cliente, aproximadamente una vez al día el sitio se ha caído y lo único que parece recuperarlo es borrar el caché. Hemos examinado los registros, y algunos de ellos parecen incluir "El controlador frontal alcanzó las 100 iteraciones de coincidencia del enrutador". Este problema no ocurría antes de aplicar el parche. Alguien tiene alguna idea de lo que podría estar causando esto? Algunas personas dicen que podría ser un error de caché en el problema de magento, pero no puedo decirlo. ¡Cualquier entrada sería útil!

Algunas notas adicionales:

  • No ha habido cargas pesadas en el servidor justo cuando se cae, así que eso no es un factor.
  • Sí, todos los parches anteriores se aplicaron con éxito.
  • Estamos usando memcache para almacenar el caché.
Daryl Gochnauer
fuente
No estoy seguro si esto está relacionado, pero este módulo es específico para el rendimiento con los nuevos bloques y variables agregados a SUPEE-6788 github.com/EcomDev/SUPEE6788-PerformanceFix
David Manners
Como otro punto de datos, tenemos un sitio que también ha tenido este problema derribar el sitio dos veces hasta ahora con el error de 100 iteraciones de coincidencia de enrutador. No comenzó hasta SUPEE-6788. Después de la primera vez que apliqué el parche AmpersandHQ (SUPEE-4755) pero el problema aún ocurrió unos días después, por lo que ese parche no nos solucionó el problema. Estamos ejecutando Magento 1.7.0.2 con el caché de Redis.
Nick

Respuestas:

3

Yo y otro desarrollador hemos estado experimentando un problema similar, sin embargo, parece que lo hemos resuelto aplicando el parche presente en este GitHub: https://github.com/AmpersandHQ/magento-ce-ee-config-corruption-bug

La causa parece ser una especie de condición de carrera en la que un proceso borra el caché mientras otro lo reinicia, he podido reproducirlo siguiendo los pasos que también figuran en ese GitHub.

Abrí un ticket de soporte con Magento para este problema y tengo mis sospechas sobre lo que comenzó a causarlo desde el parche, pero estoy esperando recibir una respuesta.

Puede leer más al respecto en la siguiente pregunta: Problemas con la página sin estilo, rutas incorrectas, pérdida de la configuración del diseño después de la aplicación del parche SUPEE-6788 .

Persata
fuente
¿Se ha probado esta solución en 1.8.1.0 w / SUPEE-6788 instalado?
Daryl Gochnauer
@ dgwexdev13 No lo he probado en 1.8, pero desarrollé el parche en 1.9 y 1.13 simultáneamente. No creo que el módulo en cuestión (Mage_Core_Model_Config) haya cambiado mucho tiempo, por lo que el parche debería aplicarse a todas las versiones. He visto este parche funcionando felizmente con 1,12, 1.13, 1.14 sistemas con SUPEE 6788 instalado.
Luke Rodgers el
Ps: actualice aquí si / cuando ha recibido noticias de Magento. Gracias
Daryl Gochnauer
Me temo que aplicar SUPEE-4755 junto con SUPEE-6788 no está haciendo mucho para detener los errores de "100 iteraciones alcanzadas". Los he aplicado a varios sitios web no relacionados y sigo viendo fallas ocasionales en todos ellos. ¿Alguien ha tenido más suerte?
Jan Tomka
1

Tenemos el mismo problema con 3 sitios versión 1.8.1. Comenzó a aparecer después de SUPEE 6788. La solución de arriba no resolvió el problema. En realidad, parece que hay algún cambio. Antes de la reparación, los sitios se bloquearon dos veces al día, ahora el último bloqueo fue después de 2 días. Pero puede ser que esté relacionado con la carga. Los 3 sitios son pequeños y poco cargados. Este problema no aparece con un sitio grande que es la versión 1.6.2 y se aplica SUPEE 6788. Todos los sitios están en el mismo servidor: el 3 con la versión 1.8.1 y el grande con la versión 1.6.2

Dimitar Dimitrov
fuente
Esto no proporciona una respuesta, más adecuado para un comentario. Debe hacer algunas buenas preguntas y proporcionar algunas buenas respuestas en el sitio. Cuando ganes suficiente reputación, también podrás publicar comentarios.
Prateek
1
Sí, entiendo, pero cuando trato de comentar tengo un mensaje "Debes tener 50 reputación para comentar". Y creo que es información importante que esto también les pase a otros sitios. Y parece ser la versión específica.
Dimitar Dimitrov
@DimitarDimitrov básicamente lo mismo: tuvimos un día ocupado el martes y el sitio se cayó aproximadamente una vez por hora. Al mover el caché de configuración fuera de Redis y simplemente usando el almacenamiento en caché base de archivos (todavía estoy usando Redis para FPC), pude estabilizar la tienda.
Phil Birnie
Después de la gran tienda con la versión 1.6.2. se bloqueó muchas veces con un error diferente: "Se proporcionó un esquema ilegal, solo se permiten caracteres alfanuméricos", nos vimos obligados a revertir el parche. 24 horas desde entonces no hay accidentes y todas nuestras tiendas son estables. Realmente no me gusta la idea de trabajar sin el parche, estamos tratando de encontrar la razón con una instalación de prueba, pero el problema es que no se bloquea. Probablemente se necesitan acciones reales para bloquearlo y no sé cuál exactamente. Intentamos provocar el bloqueo con ab pero parece que no está relacionado con la carga.
Dimitar Dimitrov
Olvidé mencionar que estamos usando un simple almacenamiento en caché basado en archivos. El servidor tiene php 5.4 y opcache, pero deshabilitar el almacenamiento en caché de php no ayuda
Dimitar Dimitrov
1

Cambiamos el caché del sitio de memcache a Redis y luego agregamos un cronjob para volcar el caché cada 12 horas. Pasó de estrellarse una vez al día a pasar unos 4-5 días antes de que volviera a caer. Luego ajustamos el cronjob para volcar cada 6 horas y no se ha reducido desde entonces (han pasado unos 3-4 días desde entonces). Ni nosotros ni la empresa de hosting podemos rastrear el problema real, pero esto parece ser una solución funcional para nosotros. Espero que ayude a alguien.

Daryl Gochnauer
fuente
Le recomiendo que ingrese el formulario de registro aquí: github.com/AmpersandHQ/… De esa manera verá qué parte del código desencadena continuamente la corrupción de la caché de configuración.
Luke Rodgers el
1

Agregué el código de depuración AmpersandHQ esta mañana y justo ahora la excepción "El controlador frontal alcanzó las 100 iteraciones de coincidencia del enrutador" sucedió aproximadamente 75 veces en un período de 2 minutos. Pero esta vez, presumiblemente debido a que el código de depuración no guarda la entrada de caché corrupta, el sitio todavía está activo sin que todos obtengan excepciones (no eliminé el caché).

Todavía no he profundizado en esto para investigar, pero corrupto-cache.log contiene:

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}

Esto está en Magento 1.7.0.2 con el caché de Redis y el parche SUPEE-4755 de AmpersandHQ ya aplicado.


Actualización del 2 de diciembre de 2015: Aquí hay otro error con el seguimiento de la pila completa:

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')
Mella
fuente
Fantástico compañero. Gracias por publicar yoru stack trace. ¿Podrías leer esta esencia? gist.github.com/convenient/2a30572d6d4bcae9796c Tengo una idea para reducirlo a si es un useCache = trueerror de caché de objeto o algo completamente diferente.
Luke Rodgers el
OK, parcheé esos archivos adicionales. Gracias por el trabajo en los parches. Anoche después de publicar, el error ocurrió dos veces más en un período de 30 minutos. Pero luego de eso no ha sucedido en 15 horas. Así que no estoy seguro de cómo predecir cuándo podría volver a ocurrir.
Nick
Está bien, por favor mantenme al día. Gracias
Luke Rodgers
Obtuve 2 errores más de 100 coincidencias de enrutador después de aplicar el parche adicional que me diste en la esencia. Entonces eso no solucionó el problema. Después del primero, modifiqué ligeramente el código de depuración para dar a todo el seguimiento de la pila en lugar del PHP truncado. No tenía espacio en mi comentario aquí, así que modifiqué mi publicación original anterior para incluir la nueva traza.
Nick
Por lo tanto, es un error en el tema del módulo "buscar". Nuestro sitio no utiliza el módulo de búsqueda, y parece que esa compañía ahora está extinta de todos modos (pero el módulo solía enviarse con Magento de forma predeterminada), por lo que desactivé el módulo en el futuro. Sin embargo, no estoy seguro de si eso solucionará el problema o si simplemente aparecerá nuevamente con un tema diferente.
Nick
1

Hemos estado experimentando el mismo problema durante semanas con varios sitios web de Magento CE. Sin embargo, ninguna de las sugerencias publicadas aquí ha ayudado. Después de varias sesiones de depuración frustrantes durante varias semanas, finalmente hemos logrado precisar esto.

En resumen, encontramos que el problema se debe a una combinación del parche SUPEE-6788, Magento <1.9.2.0 y PHP> = 5.5.22, con posibles atacantes o incluso escáneres de seguridad capaces de eliminar los sitios a pedido. Hemos publicado todos los detalles, incluida una solución, en nuestro blog . Realmente espero que esto ayude a otras almas pobres que sufren con el mismo problema.

mustdobetter
fuente
0

Estamos experimentando este problema y nuestros sitios web desde que lanzamos SUPEE6788 y parece que las llamadas fraudulentas a los servicios web xmlrpc podrían ser responsables de la corrupción de la memoria caché.

Estamos bloqueando las llamadas de servicio web desde nuestros servidores frontales ya que no las usamos + aplicando SUPEE 4755, lo mantendré informado.

COLOCADO
fuente
Este parche modificó la validación xml para usar, lo libxml_disable_entity_loaderque no es seguro para subprocesos. En algunos casos, esto puede hacer que Magento redirija a la página de instalación, sin embargo, creo que también es posible que ante errores como este, se pierda el paso loadDB de la generación de configuración, guardando datos corruptos en la memoria caché. Ver magento.stackexchange.com/questions/30071/…
Luke Rodgers el