Живой сайт пуст в интерфейсе или продолжает загружаться и никогда не загружается
Я столкнулся с самой странной проблемой, когда-либо возникавшей в magento. мы используем версию 1.9.0.
За последние 2 месяца наш живой сайт "пуст" или "продолжает загружаться" для используемых браузеров. Означает, что в этом браузере мы посещали сайт много раз.
В некоторых браузерах он работает нормально. в некоторых изображениях пусто.
Но серверная часть отлично работает во всех браузерах.
Мы столкнулись с проблемой в chrome, mozilla, opera и всех других браузеры.
1) Если мы очистим историю браузера [кэш и файлы cookie], то он будет работать.
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_ Значение memory_limit 1512 М значение php_ значение max_execution_time 18000
Мы откомментировали это :
ini_set('display_errors', 1);
Но во внешнем интерфейсе не отображается ошибка. Это ошибка apache журнал регистрации:
Дочерний pid 23845 ошибка сегментации выходного сигнала (11), возможный сброс в/etc/apache2
Действительно изо всех сил пытается решить эту проблему. Связана ли эта проблема с нашим кодом или эта проблема связана со стороной сервера?
Является ли cookie-файл браузера основной проблемой? Если да, то что нужно сделать, чтобы решить эту проблему с файлами cookie для всех браузеров. почему он начал работать, как только мы очистили сессию папка?
Мы сталкиваемся с этими проблемами при просмотре нашего сайта.
4 answers
Сначала включите режим разработчика в вашем файле .htaccess, добавьте следующее в конце файла:
SetEnv MAGE_IS_DEVELOPER_MODE "true"
Затем отредактируйте index.php и раскомментируйте строку:
#ini_set('display_errors', 1);
Ссылка на строку:
Затем войдите в систему через SSH и найдите файл дампа ядра в разделе /tmp в качестве упомянутой ошибки ошибки сегмента. Иногда он также может быть в корне / или например, в корневом каталоге самого сайта: /var/www/html/videomergerapp/.
Если вы не можете найти файлы дампа ядра, возможно, вам захочется добавить некоторые дополнительные директивы в PHP/Apache.
Взгляните сюда:
- https://serverfault.com/questions/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.
Если он не был включен, то вы не сможете получить полный обратная трассировка в сам 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 и просто пройти через все ваши НЕПРОФИЛЬНЫЕ модули (все, что Маг_*игнорирует!).
Если все еще есть проблемы, я бы временно попытался создать пакет шаблонов по умолчанию, перейдя в раздел Система > Дизайн и определив новый дизайн чего-то вроде стандартного или базового. Если пакеты стандартных шаблонов работают, то вы будете знать, что причина ошибки кроется в файлах дизайна вашего шаблона (.phtml).
Многие шаблоны, с которыми я сталкивался, плохо подходят для использования Mage::getModel()->load() в циклах foreach, так как это плохая практика и в конечном итоге может потреблять большое количество памяти и ресурсов сервера.
В Magento есть инструмент анализа кода, который может помочь сканировать файлы шаблонов, чтобы определить, есть ли какие-либо из этих плохих фрагментов код:
Дальнейшее чтение:
Кроме того, это может быть полезно для всех, какой кэш и хранилище сеансов вы используете, которые определены в app/etc/local.xml.
Надеюсь, это поможет!
Я предполагаю, что в вашем коде есть рекурсия. Отредактируйте файл lib/Varien/Db/Adapter/Pdo/Mysql.php и установите для $_debug и $_logCallStack значение true. Это должно регистрировать стек вызовов в файле var/debug/pdo_mysql.log, который должен дать вам представление о том, есть ли рекурсия в вашем коде, когда загрузка занимает целую вечность. Обратите внимание, что этот файл будет расти очень быстро, поэтому в идеале включите его, когда вы считаете, что проблема началась на месте.
Другой способ - отключить глючные модули/расширения, которые, по вашему мнению, могут вызвать это. Это может быть вашим простым настраиваемое расширение цен также попробуйте отключить его временно и посмотрите, поможет ли оно предотвратить проблему.
У меня была такая же проблема на веб-сайте клиента. Проверьте свой Magento на наличие вредоносных программ.
Это хорошо известный сценарий, обычно это программное обеспечение, перенаправляющее содержимое сообщения пользователя на внешний веб-сайт.
Начать проверку index.php , они обычно взламывают его. Прокрутите код до конца, также отметьте справа и между прокомментированными строками в заголовке лицензии. Хакеры используются для сокрытия кода таким образом.
У вас есть "загрузка навсегда", потому что он пытается связаться сайты, которые заблокировал ваш провайдер.
Должно быть довольно легко найти вредоносное ПО, найдите строки "base64", "eval", "mcrypt".
Я сталкивался с подобным поведением на Magento, у которого было два веб-сайта. Сайт хорошо загружался в течение нескольких страниц, а затем загружался навсегда.
Конфигурация базовых URL-адресов была неправильной. Параметр Безопасного базового URL-адреса был установлен на неправильный веб-сайт, в то время как Незащищенный базовый URL-адрес был установлен правильно.
Поэтому, чтобы исправить это, если администратор даже не работает должным образом, необходимо изменить значения в таблице core_config_data для правильного веб-сайта, т.е. установить правильный URL-адрес с "http://" и завершающей косой чертой в поле значения, соответствующем пути "web/незащищенный/base_url" и "web/безопасный/base_url" для правильного идентификатора области действия, представляющего идентификатор веб-сайта.
Обратите внимание, что безопасный URL-адрес является http только потому, что это был демонстрационный веб-сайт.