Site ao vivo em branco no front-end ou continue carregando e nunca carregue

23

Estou enfrentando o problema mais estranho de todos os tempos no magento. estamos usando a versão 1.9.0.

nos últimos dois meses, nosso site ativo está "em branco" ou "continue carregando" para navegadores usados. Significa que neste navegador visitamos o site várias vezes.

em alguns navegadores, está funcionando bem. em alguns mostrando em branco.

mas o back - end está funcionando bem em todos os navegadores.

estamos enfrentando problemas no chrome, mozilla, opera e todos os outros navegadores.

1) Se limparmos o histórico do navegador [cache e cookies], ele estará funcionando.

2) Se abrirmos o mesmo site em janela privada, está funcionando.

3) Se abrirmos o site em navegadores recém-instalados, ele funcionará por algum tempo. novamente em branco depois que usamos o site.

4) Se limparmos a pasta var / session, ela começará a funcionar para todos os navegadores por algum tempo. novamente site em branco.

5) às vezes, o site continuará carregando e nunca será carregado ....

Eu verifiquei system.log & exception.log . mas parece que não há erros relacionados a isso. estamos usando https para páginas seguras . até temos o aplicativo Andriod ao vivo para este site. Às vezes, temos erros fatais:

**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

definimos memory_limit = 1512 Mb no php.ini

em .htaccess , temos os seguintes arquivos.

php_value memory_limit 1512M php_value max_execution_time 18000

nós comentamos isso:

ini_set('display_errors', 1);

mas nenhum erro é exibido no front-end. Este é o log de erros do apache :

child pid 23845 sinal de saída Falha na segmentação (11), possível coredump em / etc / apache2

Realmente lutando para resolver este problema. Esse problema está relacionado ao nosso código ou ao lado do servidor?

O cookie do navegador é o principal problema? Em caso afirmativo, o que é preciso fazer para resolver esse problema de cookie para todos os navegadores. por que começou a funcionar depois que limpamos a pasta da sessão?

enfrentamos esses problemas ao navegar em nosso site. insira a descrição da imagem aqui insira a descrição da imagem aqui insira a descrição da imagem aqui

Bebê em Magento
fonte
é possível que seja um problema de cookie? stackoverflow.com/questions/15491819/…
pzirkind
o link i colado é para backend, mas o frontend pode ter um problema cookie também ... pode ser devido ao tempo de vida do cookie e a hora do servidor está fora
pzirkind
@pzirkind no nosso caso, o back-end é bom para todos os navegadores. do que precisamos aumentar a vida útil do cookie por meio de código? e eu não tenho sobre timestamp do servidor está desligado. é que temos que fazer isso?
Baby in Magento
@Babby em Magento, por vezes, se o servidor não tem timestamp correto ele irá gerar um cookie que expira antes da data atual, por isso, quando as recargas dos clientes do site e Magento verifica o cookie sua inválida
pzirkind
@pzirkind Existe alguma possibilidade de que o erro do apache postado em questão ou no carimbo de data / hora possa ser o motivo desta página em branco?
Baby in Magento

Respostas:

10

Primeiro, ative o modo Desenvolvedor no seu .htaccessarquivo, adicione o seguinte no final do arquivo:

SetEnv MAGE_IS_DEVELOPER_MODE "true"

Em seguida, edite index.phpe remova o comentário da linha:

#ini_set('display_errors', 1);

Linha referenciada:

Em seguida, efetue login via SSH e procure um arquivo de despejo principal sob /tmpo erro de falha de segmento mencionado. Às vezes, ele também pode estar na raiz /ou no diretório raiz do site em si, por exemplo: /var/www/html/videomergerapp/.

Se você não conseguir localizar nenhum arquivo de despejo principal, poderá adicionar algumas diretivas adicionais ao PHP / Apache.

Dê uma olhada aqui:

Depois de ter o (s) arquivo (s) de despejo principal, você pode usar gdb(se --enable-debug) foi usado quando o PHP foi configurado. Você pode fazer essa determinação emitindo o seguinte na linha de comando:

php -i | grep debugou simplesmente criando um arquivo de script php na raiz do servidor da web com: <?php phpinfo(); ?>em seu conteúdo e visualize o arquivo via navegador da web para ver os valores de configuração do PHP.

Se não estiver ativado, você não poderá obter um backtrace completo no próprio PHP, mas apenas chamadas de sistema de nível superior e / ou backache de apache:

Se você tiver acesso ao arquivo de despejo principal, emitir algo como o seguinte fornecerá um retorno para ajudar a encontrar o ponto de falha:

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


Se você estiver enfrentando apenas problemas aleatórios no front-end e nunca no back-end, a maioria dos sinais apontará para um possível problema com a codificação do modelo. Depois de experimentar as páginas em branco (e / ou o erro será exibido se você tiver ativado o modo de desenvolvedor e a exibição de erros). Faça login no administrador e desative todos os caches e limpe todos os caches e armazenamentos de cache.

Depois, entre app/etc/local.xmle defina os módulos locais de desativação como true.

<disable_local_modules>true</disable_local_modules>

Isso desativará o carregador automático de carregar qualquer módulo app/code/local.

Para desativar os módulos da comunidade, é mais fácil analisar cada um dos arquivos de definição de módulos encontrados app/etc/modulese desativados, configurando o nó ativo como false, como:

<active>false</active>

Dessa forma, você pode ajudar a descartar se um módulo de terceiros está causando a origem do problema pelo processo de eliminação. NOTA: Você não pode disable_local_modulese simplesmente passa por todos os seus módulos NÃO CORE (qualquer coisa que Mage_ * ignore!).

Se ainda houver problemas, tentarei temporariamente um pacote de modelos padrão acessando Sistema> Design e definindo um novo design de algo como padrão ou base. Se os pacotes de modelos de ações funcionarem, você saberá que a causa do erro está nos arquivos de design do modelo (.phtml).

Muitos modelos que encontrei são ruins sobre o uso de Mage::getModel()->load()loops foreach, pois isso é uma prática ruim e pode consumir grandes quantidades de memória e recursos do servidor.

O Magento possui uma ferramenta de análise de código que pode ajudar a verificar seus arquivos de modelo para determinar se existe algum desses trechos de código incorretos:

Leitura adicional:

Além disso, pode ser útil para todos em que armazenamento de cache e sessão você está usando e está definido app/etc/local.xml.

Espero que isto ajude!

B00MER
fonte
eu vou tentar isso nad que você saiba .... #
11555 Baby in Magento
limpamos a pasta var / session. do que resolveu nosso problema até hoje. mas hoje esse problema aconteceu novamente. do que adicionei em .htaccess: SetEnv MAGE_IS_DEVELOPER_MODE "true" e descomente ini_set ('display_errors', 1); está linha. e <disable_local_modules> true </disable_local_modules>. Então eu recebi este erro: magento.stackexchange.com/questions/94559/…
Baby in Magento
Eu não estou limpando nenhuma sessão depois de fazer algumas mudanças, se eu limpar a sessão automaticamente, isso resolverá todo o problema. você não acha que é algo relacionado a cookies ou sessões? Existe alguma maneira de resolver isto ?
Baby in Magento
@BabyinMagento Você conseguiu resolver o problema com base nas informações fornecidas? Em caso afirmativo, qual foi o problema para os outros que estão enfrentando um problema semelhante? Obrigado.
B00MER
1
Muito obrigado pelo seu apoio. limpamos a pasta da sessão e ocultamos coisas relacionadas a cookies no varien.php. mas ainda precisamos esperar mais um pouco para verificar se temos solução permanente ou não. certo, temos solução ao limpar a pasta da sessão.
Baby in Magento
3

Meu palpite é que há uma recursão no seu código. Edite o arquivo lib/Varien/Db/Adapter/Pdo/Mysql.phpe defina $_debuge $_logCallStackcomo true. Isso deve registrar a pilha de chamadas no var/debug/pdo_mysql.logarquivo, o que deve lhe dar uma idéia se houver uma recursão no seu código quando levar uma eternidade para carregar. Observe que esse arquivo continuará crescendo muito rapidamente, portanto, habilite-o idealmente quando você achar que o problema foi iniciado no local.

Outra maneira é desativar os módulos / extensões com erros que você acha que podem causar isso. Também pode ser sua extensão simples de preços configuráveis, tente desativá-la temporariamente e veja se isso ajuda a evitar o problema.

Kalpesh
fonte
alterei os valores de "$ _debug" e "$ _logCallStack" para true, agora estou aguardando o arquivo pdo_mysql.log. e nossas pastas de log estão ficando muito cheias, são quase 90 GB de logs. Eu instalei a extensão configurável simples antes de 2 semanas, esse problema ocorreu a partir de 2 meses. mas ainda precisa olhar para outros módulos de buggy.
Bebê em Magento
Eu não encontrei este arquivo var / debug / pdo_mysql.log até agora, mas foram criados logs de sistema e de exceção. eu posso ver esse log principalmente: "lib / Varien / Simplexml / Config.php na linha 510"
Baby in Magento
90 GB de logs? Uau! Faça backup deles em algum lugar diferente e esvazie os arquivos. pelo menos isso deve ajudar a melhorar um pouco a velocidade do site.
21416 Kalpesh
sim você está certo. continuamos a excluir após alguns momentos. são esses logs devido a esse problema? e até agora eu não encontrei nenhum pdo_mysql.log
Baby in Magento
Verifique o valor $_debugFileno arquivo Mysql.php e verifique se o seu vardiretório possui as permissões apropriadas necessárias para criar uma pasta e um arquivo.
21416 Kalpesh
2

Eu tive o mesmo problema no site de um cliente. Verifique seu Magento quanto a malware.

Esse é um cenário bem conhecido, geralmente é um walware que redireciona o conteúdo da postagem do usuário para um site externo.

Comece a verificar o index.php, eles geralmente o cortam. Role o código até o final, verifique também à direita e entre as linhas comentadas no cabeçalho da licença. Os hackers são usados ​​para ocultar o código dessa maneira.

Você tem o "carregamento permanente", pois ele tenta entrar em contato com sites que seu ISP bloqueou.

Deve ser bastante fácil encontrar o malware, procurar por "base64", "eval", "mcrypt".

Phoenix128_RiccardoT
fonte
este é o nosso index.php => pastebin.com/N8xnWMa7
Bebê em Magento
nosso site foi hackeado antes de três meses, depois disso apenas esse problema surgiu. mas depois adotamos várias medidas de segurança do lado do servidor. mas você acha que o código invadido ainda está presente no site e está criando problemas?
Bebê em Magento
Bem, o seu index.php está bem, mas seus sintomas são realmente os que eu já vi em alguns clientes hackers. Eu sugiro que você realize uma pesquisa completa procurando os seguintes padrões: "base64", "eval", "mcrypt", "$ _POST". Eles fornecerão toneladas de falsos positivos, então você precisa verificá-los. Se você não encontrar nada errado, sugiro uma análise de cachegrind ou uma análise passo a passo do xdebug.
Phoenix128_RiccardoT 16/02
procurarei essas palavras nos arquivos do site.
Bebê em Magento
eu estou encontrando tempos ilimitados: "base64" codifica e decodifica textos ........
Baby in Magento
2

Eu experimentei um comportamento semelhante em um Magento que tinha dois sites. O site estava carregando bem por algumas páginas e depois carregando para sempre.

A configuração dos URLs base estava incorreta. A configuração do URL da Base segura foi definida como o site errado, enquanto o URL da base não segura foi definido corretamente.

Portanto, para corrigir isso, se o administrador nem estiver funcionando corretamente, os valores precisam ser alterados na tabela core_config_data para o site certo, ou seja, defina o URL correto com o "http: //" e uma barra no campo de valor correspondente a o caminho "web / inseguro / base_url" e "web / secure / base_url" para o scope_id correto que representa o ID do site.

insira a descrição da imagem aqui

Observe que o URL seguro é http apenas porque era um site de demonstração.

Brac
fonte