前端的活动站点空白或继续加载，永不加载

23

我在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

我们在php.ini中设置memory_limit = 1512 Mb

在.htaccess中，我们有以下文件。

php_value memory_limit 1512M php_value max_execution_time 18000

我们对此没有评论：

ini_set('display_errors', 1);

但前端未显示任何错误。这是apache错误日志：

子pid 23845退出信号分段错误（11），可能在/ etc / apache2中有coredump

确实在努力解决这个问题。这个问题与我们的代码有关还是与服务器端有关？

浏览器cookie是主要问题吗？如果是这样，该怎么做才能解决所有浏览器的cookie问题。清除会话文件夹后，为什么它开始工作？

我们在浏览我们的网站时会遇到这些问题。

cache frontend cookie

— 婴儿在Magento
source

它可能是cookie问题吗？stackoverflow.com/questions/15491819/…–

— pzirkind

我粘贴的链接是针对后端的，但前端也可能存在cookie问题...这可能是由于cookie的寿命以及服务器的时间戳已关闭

— pzirkind

在我们这种情况下，@pzirkind后端适用于所有浏览器。我们是否必须通过代码来延长cookie的生存期？而且我没有关闭服务器的时间戳。我们必须坚持下去吗？

— Magento的婴儿，2015年

@Magento中的@Babby有时，如果服务器没有正确的时间戳，它将生成一个cookie，该cookie在当前日期之前过期，因此，当客户重新加载该站点并且magento检查该cookie无效时

— pzirkind

@pzirkind是否有可能该问题或时间戳中发布的apache错误可能是此空白页的原因？

— Magento的婴儿，2015年

10

首先在.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添加一些其他指令。

在这里看看：

拥有核心转储文件后，就可以使用gdb（如果--enable-debug已配置PHP）。您可以通过从命令行发出以下命令来做出此确定：

php -i | grep debug或者只是在您的Web服务器根目录中使用以下命令创建一个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简单地浏览所有的NON-CORE模块（任何Mage_ *忽略！）。

如果仍然存在问题，那么我将暂时尝试使用默认模板包，方法是进入“系统”>“设计”并定义一个新的设计，例如“ default”或“ base”。如果库存模板包有效，则您将知道错误原因存在于模板设计文件（.phtml）中。

我遇到的许多模板都不能Mage::getModel()->load()在foreach循环中使用，因为这是不好的做法，最终会消耗大量的服务器内存和资源。

Magento确实具有代码分析工具，可以帮助您扫描模板文件以确定是否存在以下不良代码：

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

进一步阅读：

调试Magento商店的基础知识

同样，它可能对每个人都有用，它们在中定义了您正在使用的缓存和会话存储app/etc/local.xml。

希望这可以帮助！

— B00MER
source

我会尝试这个NAD让你知道....

— 婴儿在Magento

我们清除了var / session文件夹。直到今天解决了我们的问题。但是今天这个问题又发生了。比我在.htaccess中添加的要多：SetEnv MAGE_IS_DEVELOPER_MODE“ true”和取消注释ini_set（'display_errors'，1）; 这条线。和<disable_local_modules> true </ disable_local_modules>。：比我得到tjis错误magento.stackexchange.com/questions/94559/...

— 婴儿在Magento

如果我自动清除会话，它将不会解决所有问题，因此我在进行一些更改后不会清除任何sessin。您不认为它与Cookie或会话有关吗？有什么办法解决这个问题？

— 婴儿在Magento

@BabyinMagento您是否能够根据提供的信息解决问题？如果是这样，那么其他遇到类似问题的人又怎么了？谢谢。

— B00MER

1

非常感谢您的支持。我们清除了会话文件夹，并在varien.php中隐藏了与cookie相关的内容。但是我们仍然需要等待一些时间来检查我们是否获得了永久解决方案。正确，我们在清除会话文件夹后得到了解决方案。

— Magento中的婴儿，2015年

3

我的猜测是您的代码中有递归。编辑文件lib/Varien/Db/Adapter/Pdo/Mysql.php和设置$_debug，并$_logCallStack为true。这应该将调用堆栈记录在var/debug/pdo_mysql.log文件中，这应该让您了解在永久加载代码时代码是否存在递归。请注意，此文件将保持快速增长，因此，当您认为问题已开始在现场时，理想情况下将其启用。

其他方法是禁用您认为可能导致此问题的错误模块/扩展。这也可能是您可配置的简单价格扩展，请尝试暂时将其禁用，看看是否有助于防止此问题。

— 卡尔佩什
source

我将“ $ _debug”和“ $ _logCallStack”的值更改为true，现在我正在等待pdo_mysql.log文件。而且我们的日志文件夹已填满，其中几乎有90 gb的日志存在。我在2周前安装了简单的可配置扩展程序，这个问题在2个月后就出现了。但仍然需要查看其他越野车模块。

— Magento中的婴儿，

直到现在我都没有找到该文件var / debug / pdo_mysql.log，但是创建了系统日志和异常日志。我主要看到此日志：“第510行上的lib / Varien / Simplexml / Config.php”

— Magento的宝贝，

90 GB的日志？哇！将它们备份到其他位置，然后清空文件。至少可以帮助您提高网站速度。

— Kalpesh

是的，你是对的。我们会在一段时间后继续删除。那些日志是因为这个问题吗？直到现在我还没有找到任何pdo_mysql.log

— Magento的宝贝，

检查$_debugFileMysql.php文件中的值，并确保您的var目录具有创建文件夹和文件所需的适当权限。

— Kalpesh

2

我在客户网站上遇到了同样的问题。检查您的Magento是否存在恶意软件。

这是一个众所周知的场景，通常是一种将用户帖子内容重定向到外部网站的蠕虫病毒。

开始检查index.php，他们通常会对其进行破解。滚动代码直到结尾，也请在许可证标题的右侧和注释行之间进行检查。黑客习惯于以这种方式隐藏代码。

您具有“永远加载”的状态，因为它试图与您的ISP阻止的网站联系。

查找恶意软件，搜索“ base64”，“ eval”，“ mcrypt”字符串应该非常容易。

— Phoenix128_RiccardoT
source

这是我们的index.php => pastebin.com/N8xnWMa7

— Magento的宝贝，

我们的网站在3个月前遭到黑客入侵，之后才出现此问题。但是后来我们从服务器端采取了许多安全措施。但是您认为被入侵的代码仍然存在于网站中并造成问题吗？

— Magento中的婴儿，

好吧，您的index.php很好，但是您的症状确实像我在某些客户入侵的网络专家中看到的那样。我建议您执行完整搜索以查找以下模式：“ base64”，“ eval”，“ mcrypt”，“ $ _ POST”。它们会给您带来大量误报，因此您需要检查它们。如果您没有发现任何问题，建议您进行cachegrind分析或xdebug分步分析。

— Phoenix128_RiccardoT

我将在我们的站点文件中搜索这些单词。

— Magento中的婴儿，

我发现无限的时间：“ base64”编码和解码文本........

— 婴儿在Magento

2

我在具有两个网站的Magento上遇到了类似的行为。该网站加载了好几个页面，然后就永远加载了。

基本URL的配置错误。“安全基本URL”设置设置为错误的网站，而“不安全基本URL”设置正确。

因此，要解决此问题，如果管理员甚至无法正常工作，则需要在core_config_data表中为正确的网站更改值，即，在正确的URL上使用“ http：//”和在对应于代表网站ID的正确scope_id的路径“ web / unsecure / base_url”和“ web / secure / base_url”。

请注意，安全网址仅是http，因为它是一个演示网站。

— 布拉克
source