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

Я сталкиваюсь с самой странной проблемой в истории 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 для всех браузеров. почему он начал работать, когда мы очищаем папку сеанса?

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

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

SetEnv MAGE_IS_DEVELOPER_MODE "true"

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

#ini_set('display_errors', 1);

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

• https://github.com/OpenMage/magento-mirror/blob/magento-1.9/index.php#L73

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

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

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

• /server/470407/how-to-get-a-core-dump-from-apache-when-segfaulting
• http://www.cyberciti.biz/tips/configure-apache-web-server-for-core-dump.html

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

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

• https://bugs.php.net/bugs-generating-backtrace.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 есть инструмент для анализа кода, который может помочь отсканировать файлы вашего шаблона, чтобы определить, есть ли какой-либо из этих плохих фрагментов кода:

• https://github.com/magento-ecg/magniffer

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

• Основы отладки магазина Magento

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

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

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

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

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

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

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

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

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

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

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

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

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