SUPEE-6788 (возможно) проблемы с кешем

8

С тех пор, как мы применили исправление SUPEE-6788 на сайте клиента, примерно один раз в день сайт выходил из строя, и единственное, что, кажется, возвращает его, - это очистить кеш. Мы просмотрели журналы, и некоторые из них, по-видимому, включают «Фронт-контроллер достиг 100 итераций сопоставления маршрутизаторов». Эта проблема не возникала до применения патча. Кто-нибудь знает, что может быть причиной этого? Некоторые люди говорят, что это может быть ошибка кеша в magento, но я не могу сказать. Любой вклад будет полезен!

Некоторые дополнительные заметки:

  • Не было никаких тяжелых нагрузок на сервер, когда он выходит из строя, так что это не фактор.
  • Да, все предыдущие исправления были успешно применены.
  • Мы используем memcache для хранения кеша.
Дэрил Гохнауэр
источник
Не уверен, что это связано, но этот модуль специфичен для производительности с новыми блоками и переменными, добавленными в SUPEE-6788 github.com/EcomDev/SUPEE6788-PerformanceFix
Дэвид Мэннерс
В качестве еще одного пункта данных у нас есть сайт, на котором эта проблема также дважды приводила к сбою сайта с ошибкой 100 повторений совпадений маршрутизатора. Это не началось до SUPEE-6788. После первого раза я применил патч AmpersandHQ (SUPEE-4755), но проблема все еще возникла несколько дней спустя, так что патч не решил эту проблему для нас. Мы работаем с Magento 1.7.0.2 с кешем Redis.
Ник

Ответы:

3

У меня и другого разработчика возникла похожая проблема, однако мы, похоже, решили ее, применив патч, присутствующий в этом GitHub: https://github.com/AmpersandHQ/magento-ce-ee-config-corruption-bug

Причина, по-видимому, в каком-то состоянии состязания, когда кэш очищается одним процессом, а другой экземпляр повторно создается, и я смог воспроизвести его, выполнив шаги, также перечисленные на этом GitHub.

Я открыл службу поддержки Magento для этой проблемы, и у меня есть подозрения о том, что стало причиной этого после патча, но я жду ответа.

Вы можете прочитать больше об этом по следующему вопросу: Проблемы с Unstyled Page, Bad Paths, потеря конфигурации макета после применения патча SUPEE-6788 .

Persata
источник
Было ли это исправление протестировано на 1.8.1.0 с установленным SUPEE-6788?
Дэрил Гохнауэр
@ dgwexdev13 Я не тестировал его на 1.8, но я разработал патч на 1.9 и 1.13 одновременно. Я не думаю, что рассматриваемый модуль (Mage_Core_Model_Config) изменился в LONG, в то время как патч должен в значительной степени применяться ко всем версиям. Я видел, как этот патч успешно работает с системами 1,12, 1,13, 1,14 с установленным SUPEE 6788.
Люк Роджерс
Ps - Пожалуйста, обновите здесь, если / когда вы получили ответ от Magento. Спасибо
Дэрил Гохнауэр
Боюсь, что применение SUPEE-4755 вместе с SUPEE-6788 не слишком помогает остановить ошибки «100 итераций достигнуто». Я применил оба к ряду несвязанных веб-сайтов, и я продолжаю видеть случайные сбои на всех них. Кому-нибудь повезло больше?
Ян Томка
1

У нас та же проблема с 3 сайтами версии 1.8.1. Он начал появляться после SUPEE 6788. Исправление сверху не решило проблему. На самом деле, похоже, есть некоторые изменения. До исправления сайты зависали два раза в день, теперь последний сбой был через 2 дня. Но может быть это связано с нагрузкой. 3 сайта маленькие и не очень загруженные. Эта проблема не возникает с большим сайтом версии 1.6.2 и SUPEE 6788. Все сайты находятся на одном сервере - 3 с версией 1.8.1 и большой с версией 1.6.2

Димитар Димитров
источник
Это не дает ответа, больше подходит для комментария. Вы должны задать несколько хороших вопросов и дать несколько хороших ответов на сайте. Когда вы заработаете достаточно репутации, вы также сможете оставлять комментарии.
Prateek
1
да, я понимаю, но когда я пытаюсь комментировать, у меня появляется сообщение «У вас должно быть 50 репутации, чтобы комментировать». И я думаю, что это важная информация, что это происходит и с другими сайтами. И, похоже, зависит от версии.
Димитар Димитров
@DimitarDimitrov в основном то же самое - у нас был насыщенный день во вторник, и сайт закрывался примерно раз в час. Переместив кеш конфигурации из Redis и просто используя файловое кеширование (я все еще использую Redis для FPC), я смог стабилизировать хранилище.
Фил Бирни
После большого магазина с версией 1.6.2. вылетал много раз с ошибкой: «Неверная схема предоставлена, разрешены только буквенно-цифровые символы», мы были вынуждены отменить патч. 24 часа с тех пор никаких сбоев и все наши магазины стабильны. Мне действительно не нравится идея работать без патча, мы пытаемся найти причину с помощью одной тестовой установки, но проблема в том, что она не падает. Вероятно, необходимы реальные действия, чтобы разбить его, и я не знаю, какие именно. Мы попытались спровоцировать сбой с помощью ab, но это не связано с нагрузкой.
Димитар Димитров
Я забыл упомянуть, что мы используем простое файловое кэширование. Сервер с php 5.4 и opcache, но отключение любого php-кэширования не помогает
Димитр Димитров
1

Мы переключили кэш сайта с memcache на Redis, а затем добавили cronjob для сброса кэша каждые 12 часов. Он переходил от сбоя один раз в день к 4-5 дням, прежде чем снова падал. Затем мы настраивали cronjob для сброса каждые 6 часов, и с тех пор он не снижался (с тех пор прошло около 3-4 дней). Ни мы, ни хостинговая компания не можем отследить реальную проблему, но это, похоже, исправление для нас. Надеюсь, что это помогает кому-то.

Дэрил Гохнауэр
источник
Я рекомендую вам ввести форму регистрации здесь: github.com/AmpersandHQ/… Таким образом, вы увидите, какой фрагмент кода постоянно вызывает сохранение повреждения кэша конфигурации.
Люк Роджерс
1

Я добавил код отладки AmpersandHQ этим утром и только сейчас произвел исключение «Фронтальный контроллер достиг 100 итераций сопоставления маршрутизатора» примерно 75 раз за 2 минуты. Но на этот раз, предположительно из-за того, что код отладки не сохраняет поврежденную запись в кэше, сайт все еще работает, и все не получают исключений (я не очищал кэш).

Я еще не копался в этом, чтобы исследовать, но коррупционный-cache.log содержит:

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}

Это на Magento 1.7.0.2 с уже установленным кешем Redis и патчем SUPEE-4755 от AmpersandHQ.


Обновление от 2 декабря 2015 г. Вот еще одна ошибка с полной трассировкой стека:

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')
Ник
источник
Фантастический друг. Спасибо за публикацию вашего стека трассировки. Не могли бы вы прочитать эту суть? gist.github.com/convenient/2a30572d6d4bcae9796c У меня есть идея сузить его до того, является ли это useCache = trueошибкой объектного кэша или чем-то еще полностью.
Люк Роджерс
ОК, я пропатчил эти дополнительные файлы. Спасибо Тебе за работу над патчами. Вчера вечером после того, как я написал, ошибка произошла еще два раза за 30 минут. Но потом этого не произошло за 15 часов. Так что я не совсем уверен, как предсказать, когда это может произойти снова.
Ник
Хорошо, круто, пожалуйста, держи меня в курсе. Спасибо
Люк Роджерс
Я получил еще 2 ошибки 100 совпадений маршрутизатора после применения дополнительного патча, который вы мне дали. Так что это не решило проблему. После первого я немного изменил код отладки, чтобы получить полную трассировку стека вместо усеченного кода PHP. У меня не было места в моем комментарии здесь, поэтому я изменил свой оригинальный пост выше, чтобы включить новый след.
Ник
Так что это ошибка в теме модуля "найти". Наш сайт не использует модуль поиска, и похоже, что компания все равно больше не существует (но модуль по умолчанию поставлялся с Magento), поэтому я отключил модуль в дальнейшем. Не уверен, если это решит проблему, или если он просто появится снова, показывая другую тему.
Ник
1

Мы уже несколько недель испытываем ту же проблему с различными веб-сайтами Magento CE. Однако ни одно из размещенных здесь предложений не помогло. После нескольких разочаровывающих отладочных сессий в течение нескольких недель нам наконец-то удалось установить это.

Таким образом, мы обнаружили, что проблема заключается в комбинации патча SUPEE-6788, Magento <1.9.2.0 и PHP> = 5.5.22, с потенциальными злоумышленниками или даже сканерами безопасности, способными блокировать сайты по требованию. Мы разместили полную информацию, включая исправление, в нашем блоге . Я искренне надеюсь, что это поможет любым другим бедным душам, страдающим той же проблемой.

mustdobetter
источник
0

Мы сталкиваемся с этой проблемой и с нашими веб-сайтами с момента выпуска SUPEE6788, и кажется, что мошеннические обращения к веб-сервисам xmlrpc могут быть причиной повреждения кэша.

Мы блокируем вызовы веб-сервисов с наших фронт-серверов, так как мы их не используем + применяем SUPEE 4755, я буду держать вас в курсе.

SMASHED
источник
Этот патч изменил валидацию XML для использования, libxml_disable_entity_loaderчто не является потокобезопасным. В некоторых случаях это может привести к перенаправлению Magento на страницу установки, однако я полагаю, что перед такими ошибками также возможно, что он пропустит шаг loadDB генерации конфигурации, сохраняя поврежденные данные в кеше. См. Magento.stackexchange.com/questions/30071/…
Люк Роджерс