Живой сайт пуст во внешнем интерфейсе или продолжает загружаться и никогда не загружается

23

Я сталкиваюсь с самой странной проблемой в истории magento. мы используем версию 1.9.0.

за последние 2 месяца наш действующий сайт "пуст" или "продолжает загружаться" для используемых браузеров. Значит в этом браузере мы заходили на сайт много раз.

в некоторых браузерах работает нормально. в некоторых показывается пустым.

но бэкэнд работает нормально во всех браузерах.

мы столкнулись с проблемой в Chrome, Mozilla, Opera и всех других браузерах.

1) Если мы очистим историю браузера [кеш и куки], чем он будет работать.

2) Если мы открываем один и тот же сайт в приватном окне, он работает.

3) Если мы открываем сайт в только что установленных браузерах, он работает некоторое время. снова пустой после того, как мы использовали сайт.

4) Если мы очистим папку var / session, то она через некоторое время начнет работать для всех браузеров. опять сайт пустой.

5) иногда сайт будет продолжать загружаться и никогда не будет загружаться ....

Я проверил system.log & exception.log . но, похоже, нет ошибок, связанных с этим. мы используем https для защищенных страниц. даже у нас есть живое приложение Andriod для этого сайта. иногда мы получим фатальные ошибки:

**Fatal error**: Allowed memory size of 536870912 bytes exhausted (tried to allocate 85 bytes) in /lib/Zend/Db/Statement/Pdo.php or lib/Varien/Object.php or /lib/Varien/Db/Select.php or app/code/core/Mage/Core/Model/Config.php

мы устанавливаем memory_limit = 1512 Мб в php.ini

в .htaccess у нас есть следующие файлы.

php_value memory_limit 1512M php_value max_execution_time 18000

мы раскомментировали это:

ini_set('display_errors', 1);

но нет ошибки отображения в веб-интерфейсе. Это журнал ошибок apache :

дочерний pid 23845 выходной сигнал Ошибка сегментации (11), возможный coredump в / etc / apache2

Действительно изо всех сил пытается решить эту проблему. Эта проблема связана с нашим кодом или эта проблема связана со стороной сервера?

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

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

Ребенок в Мадженто
источник
Возможно ли, что это проблема с cookie? stackoverflow.com/questions/15491819/…
pzirkind
ссылка, которую я вставил, предназначена для бэкэнда, но во внешнем интерфейсе также может быть проблема с файлом cookie ... это может быть связано с временем существования файла cookie и с отключением временной метки сервера
pzirkind
@pzirkind в нашем случае backend подходит для всех браузеров. чем мы должны увеличить время жизни куки через код? и я не получил о временной отметке сервера выключен. мы должны сделать это на?
Ребенок в Magento
@Babby в Magento иногда, если на сервере нет правильной метки времени, он создает cookie, срок действия которого истекает до текущей даты, поэтому, когда клиент перезагружает сайт и magento проверяет его как недействительный
pzirkind
@pzirkind Есть ли вероятность, что ошибка apache, опубликованная в вопросе или отметке времени, может быть причиной этой пустой страницы?
Ребенок в Magento

Ответы:

10

Сначала включите режим разработчика в вашем .htaccessфайле, добавьте следующее в конец файла:

SetEnv MAGE_IS_DEVELOPER_MODE "true"

Затем отредактируйте index.phpи раскомментируйте строку:

#ini_set('display_errors', 1);

Линия ссылается:

Затем войдите в систему через SSH и найдите файл дампа основной памяти в /tmpкачестве упомянутой ошибки сбоя сегмента. Иногда он также может быть в корне /или в корневой директории самого сайта, например: /var/www/html/videomergerapp/.

Если вы не можете найти какие-либо файлы дампа памяти, вы можете добавить некоторые дополнительные директивы в PHP / Apache.

Посмотрите здесь:

Если у вас есть файл (ы) основного дампа, вы можете использовать gdb(если --enable-debug), который был использован при настройке PHP. Вы можете сделать это определение, введя следующее из командной строки:

php -i | grep debugили просто создайте файл скрипта php в корне вашего веб-сервера с помощью: <?php phpinfo(); ?>в его содержимом и просмотрите файл через веб-браузер, чтобы увидеть значения конфигурации PHP.

Если он не был включен, вы не сможете получить полную обратную трассировку в самом PHP, а только системные вызовы более высокого уровня и / или обратную трассировку apache:

Если у вас есть доступ к файлу дампа основной памяти, выдача чего-то вроде следующего даст вам обратную трассировку, чтобы помочь найти точку сбоя:

gdb /usr/local/apache2/bin/httpd /tmp/core.2027


Если вы испытываете только случайные проблемы на веб-интерфейсе, а не на бэкэнде, то большинство признаков указывают на возможную проблему с кодированием вашего шаблона. После появления пустых страниц (и / или отображается ошибка, если вы включили режим разработчика и отображение ошибки). Войдите к своему администратору и отключите все кэши и очистите все кэши и хранилища кэша.

Затем зайдя в app/etc/local.xmlи установите для отключения локальных модулей значение true.

<disable_local_modules>true</disable_local_modules>

Это отключит автозагрузчик от загрузки любых модулей в app/code/local.

Чтобы отключить модули сообщества, проще всего просмотреть все файлы определений модулей, найденные в app/etc/modulesи отключив их, установив для активного узла значение false, например, так:

<active>false</active>

Таким образом, вы можете помочь исключить, если сторонний модуль вызывает источник проблемы в процессе устранения. Примечание: Вы не можете disable_local_modulesи просто пройти через все ваши НЕОСНОВНЫХ модули (все Mage_ * игнорировать!).

Если проблемы не устранены, я временно попытался бы использовать пакет шаблонов по умолчанию, перейдя в «Система»> «Дизайн» и определив новый дизайн, например, по умолчанию или базовый. Если стандартные шаблоны пакетов работают, то вы будете знать, что причина ошибки заключается в ваших файлах дизайна шаблонов (.phtml).

Многие шаблоны, с которыми я столкнулся, плохо подходят для Mage::getModel()->load()циклов foreach, так как это плохая практика и в конечном итоге может потреблять большие объемы памяти и ресурсов сервера.

В Magento есть инструмент для анализа кода, который может помочь отсканировать файлы вашего шаблона, чтобы определить, есть ли какой-либо из этих плохих фрагментов кода:

Дальнейшее чтение:

Кроме того, для всех может быть полезно, в каком кеше и хранилище сессии вы используете, что определено app/etc/local.xml.

Надеюсь это поможет!

B00MER
источник
я попробую это, дадим вам знать ....
Малыш в Magento
мы очистили папку var / session. чем это решило нашу проблему до сегодняшнего дня. но сегодня эта проблема снова произошла. чем я добавил это в .htaccess: SetEnv MAGE_IS_DEVELOPER_MODE "true" и раскомментировать ini_set ('display_errors', 1); эта линия. и <disable_local_modules> true </ disable_local_modules>. Тогда я получил ошибку: magento.stackexchange.com/questions/94559/…
Ребенок в Magento
я не очищаю sessin после того, как я делаю некоторые изменения, если я очищаю сессию автоматически, она собирается решить все проблемы. Вы не думаете, что это что-то связанное куки или сессии? есть ли способ решить это?
Ребенок в Magento
@BabyinMagento Удалось ли решить проблему на основе предоставленной информации? Если да, в чем была проблема для тех, кто испытывает подобную проблему? Спасибо.
B00MER
1
Спасибо большое за вашу поддержку. мы очистили папку сеанса и скрыли связанные с куки вещи в varien.php. но все же нам нужно подождать еще некоторое время, чтобы проверить, получили ли мы постоянное решение или нет. Хорошо, мы получили решение, как мы очистили папку сеанса.
Ребенок в Magento
3

Я предполагаю, что в вашем коде есть рекурсия. Отредактируйте файл lib/Varien/Db/Adapter/Pdo/Mysql.phpи набор $_debugи $_logCallStackистина. Это должно зарегистрировать стек вызовов в var/debug/pdo_mysql.logфайле, который должен дать вам представление о том, есть ли в вашем коде рекурсия, когда она загружается вечно. Обратите внимание, что этот файл будет расти очень быстро, поэтому в идеале включите его, когда вы думаете, что проблема началась на сайте.

Другой способ - отключить ошибочные модули / расширения, которые, по вашему мнению, могут вызвать это. Это может быть также ваше простое настраиваемое расширение цен, попробуйте временно его отключить и посмотрите, поможет ли оно предотвратить проблему.

Kalpesh
источник
я изменил значения «$ _debug» и «$ _logCallStack» на true, теперь я жду файл pdo_mysql.log. и наши папки журналов заполняются слишком много, их почти 90 ГБ журналов там. я установил простое настраиваемое расширение до 2 недель, эта проблема была там с 2 месяцев. но все же нужно посмотреть на другие глючные модули.
Ребенок в Magento
я до сих пор не нашел этот файл var / debug / pdo_mysql.log, но системные журналы и журналы исключений созданы. я могу видеть этот журнал в основном: «lib / Varien / Simplexml / Config.php на линии 510»
Baby in Magento
90 гб бревен? Вот Это Да! Сделайте резервную копию их в другое место и очистите файлы. это должно помочь улучшить скорость вашего сайта.
Kalpesh
да ты прав. мы продолжаем удалять через несколько раз. эти журналы из-за этой проблемы? и до сих пор я не нашел ни одного pdo_mysql.log
Baby в Magento
Проверьте значение $_debugFileв файле Mysql.php и убедитесь, что у вашего varкаталога есть необходимые разрешения, необходимые для создания папки и файла.
Kalpesh
2

У меня была такая же проблема на сайте клиента. Проверьте ваш Magento на наличие вредоносных программ.

Это хорошо известный сценарий, обычно это вредоносная программа, перенаправляющая контент поста пользователя на внешний сайт.

Начните проверять index.php, они обычно взламывают его. Прокрутите код до конца, также проверьте справа и между закомментированными строками в заголовке лицензии. Хакеры используются для сокрытия кода таким способом.

У вас есть «вечная загрузка», потому что он пытается связаться с веб-сайтами, заблокированными вашим провайдером.

Должно быть довольно легко найти вредоносное ПО, выполнить поиск по строкам «base64», «eval», «mcrypt».

Phoenix128_RiccardoT
источник
это наш index.php => pastebin.com/N8xnWMa7
Ребенок в Magento
наш сайт был взломан до 3 месяцев, после этого появилась только эта проблема. но позже мы приняли много мер безопасности со стороны сервера. но вы думаете, что взломанный код все еще присутствует на сайте и создает проблему?
Ребенок в Magento
Что ж, ваш index.php в порядке, но ваши симптомы действительно похожи на те, которые я видел у некоторых взломанных клиентов веб-сайтов. Я предлагаю вам выполнить полный поиск в поисках следующих шаблонов: «base64», «eval», «mcrypt», «$ _POST». Они дадут вам массу ложных срабатываний, поэтому вам нужно их проверить. Если вы не нашли ничего плохого, я предлагаю вам выполнить анализ кэширования или пошаговый анализ xdebug.
Phoenix128_RiccardoT
я буду искать эти слова в файлах нашего сайта.
Ребенок в Magento
я нахожу неограниченное количество раз: "base64" кодирует и декодирует тексты ........
Малыш в Magento
2

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

Конфигурация базовых URL-адресов была неправильной. Для параметра URL-адреса безопасной базы задан неправильный веб-сайт, в то время как URL-адрес небезопасной базы был задан правильно.

Поэтому, чтобы исправить это, если администратор даже не работает должным образом, необходимо изменить значения в таблице core_config_data для правильного веб-сайта, т. Е. Установить правильный URL-адрес с помощью «http: //» и косой черты в поле значения, соответствующем путь "web / unsecure / base_url" и "web / secure / base_url" для правильного scope_id, представляющего идентификатор веб-сайта.

введите описание изображения здесь

Обратите внимание, что безопасный URL-адрес является http только потому, что это был демонстрационный сайт.

Брач
источник