Sitio en vivo en blanco en la interfaz o seguir cargando y nunca cargar

23

Estoy enfrentando el problema más extraño en magento. Estamos utilizando la versión 1.9.0.

Desde los últimos 2 meses, nuestro sitio en vivo está "en blanco" o "sigue cargando" para los navegadores usados. Significa que en este navegador visitamos el sitio muchas veces.

en algunos navegadores, funciona bien. en algunos mostrando en blanco.

pero el backend funciona bien en todos los navegadores.

Estamos enfrentando problemas en Chrome, Mozilla, Opera y todos los demás navegadores.

1) Si borramos el historial del navegador [caché y cookies], entonces está funcionando.

2) Si abrimos el mismo sitio en una ventana privada, está funcionando.

3) Si abrimos el sitio en navegadores recién instalados, funciona por algún tiempo. de nuevo en blanco después de usar el sitio.

4) Si borramos la carpeta var / session, comenzará a funcionar para todos los navegadores durante algún tiempo. de nuevo sitio en blanco.

5) a veces, el sitio seguirá cargándose y nunca se cargará ...

Revisé system.log y exception.log . pero parece que no hay errores relacionados con esto. Estamos usando https para páginas seguras . incluso tenemos la aplicación Andriod en vivo para este sitio. a veces obtendremos errores fatales:

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

configuramos memory_limit = 1512 Mb en php.ini

en .htaccess tenemos los siguientes archivos.

php_value memory_limit 1512M php_value max_execution_time 18000

Descomentamos esto:

ini_set('display_errors', 1);

pero no se muestra ningún error en la interfaz. Este es el registro de errores de apache :

child pid 23845 señal de salida Falla de segmentación (11), posible coredump en / etc / apache2

Realmente luchando para resolver este problema. ¿Está este problema relacionado con nuestro código o está relacionado con el lado del servidor?

¿Es la cookie del navegador el principal problema? Si es así, ¿qué debe hacer para resolver este problema de cookies para todos los navegadores? ¿Por qué comenzó a funcionar una vez que borramos la carpeta de sesión?

Nos enfrentamos a estos problemas al navegar por nuestro sitio. ingrese la descripción de la imagen aquí ingrese la descripción de la imagen aquí ingrese la descripción de la imagen aquí

Bebé en magento
fuente
¿Es posible que sea un problema de cookies? stackoverflow.com/questions/15491819/…
pzirkind
el enlace Pegué es para back-end, pero la interfaz puede tener un problema de galletas también ... puede ser debido a la duración de la cookie y la fecha y hora del servidor está apagado
pzirkind
@pzirkind en nuestro caso, el backend está bien para todos los navegadores. entonces, ¿tenemos que aumentar la vida útil de las cookies a través del código? y no entendí que la fecha y hora del servidor está desactivada. ¿tenemos que hacerlo?
Bebé en Magento
@Babby en Magento a veces, si el servidor no tiene la marca de tiempo correcta, generará una cookie que caducará antes de la fecha actual, por lo que cuando el cliente vuelva a cargar el sitio y magento verifique que la cookie no es válida
pzirkind
@pzirkind ¿Existe alguna posibilidad de que el error de apache publicado en la pregunta o la marca de tiempo sea la razón de esta página en blanco?
Bebé en Magento

Respuestas:

10

Primero habilite el modo Desarrollador en su .htaccessarchivo, agregue lo siguiente al final del archivo:

SetEnv MAGE_IS_DEVELOPER_MODE "true"

A continuación, edite index.phpy descomente la línea:

#ini_set('display_errors', 1);

Línea referenciada:

Luego, inicie sesión a través de SSH y busque un archivo de volcado de núcleo /tmpcomo se menciona en el error de falla del segmento. A veces también puede estar en la raíz /o en el directorio raíz del sitio en sí, por ejemplo: /var/www/html/videomergerapp/.

Si no puede localizar ningún archivo de volcado de núcleo, puede agregar algunas directivas adicionales a PHP / Apache.

Echa un vistazo aquí:

Una vez que tenga los archivos de volcado de núcleo, puede usar gdb(if --enable-debug) cuando se configuró PHP. Puede hacer esta determinación emitiendo lo siguiente desde la línea de comandos:

php -i | grep debugo simplemente creando un archivo de script php en la raíz de su servidor web con: <?php phpinfo(); ?>en su contenido y vea el archivo a través del navegador web para ver los valores de configuración de PHP.

Si no estaba habilitado, entonces no podrá obtener un rastreo completo en PHP, sino solo llamadas de sistema de nivel superior y / o rastreo de apache:

Si tiene acceso al archivo de volcado del núcleo, la emisión de algo como lo siguiente le dará un seguimiento para ayudarlo a encontrar el punto de falla:

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


Si solo está experimentando problemas aleatorios en el frontend y nunca en el backend, entonces la mayoría de los signos apuntan a un posible problema con la codificación de su plantilla. Una vez que experimente las páginas en blanco (y / o aparece un error si ha habilitado el modo de desarrollador y la visualización de error). Inicie sesión en su administrador y desactive todas las memorias caché y vacíe todas las memorias caché y los almacenes de memoria caché.

Luego, ingrese app/etc/local.xmly configure los módulos locales de desactivación en verdadero.

<disable_local_modules>true</disable_local_modules>

Esto impedirá que el cargador automático cargue los módulos app/code/local.

Para deshabilitar los módulos de la comunidad, es más fácil pasar por cada uno de los archivos de definición de módulos que se encuentran app/etc/modulesy deshabilitar configurando el nodo activo en falso de la siguiente manera:

<active>false</active>

De esta manera, puede ayudar a descartar si un módulo de terceros está causando el origen del problema por el proceso de eliminación. NOTA: No puede disable_local_modulesy simplemente debe pasar por todos sus módulos NO CORE (¡cualquier cosa que Mage_ * ignore!).

Si todavía hay problemas, intentaré un paquete de plantilla predeterminado temporalmente yendo a Sistema> Diseño y definiendo un nuevo diseño de algo como predeterminado o base. Si los paquetes de plantillas de stock funcionan, entonces sabrá que la causa del error reside en sus archivos de diseño de plantilla (.phtml).

Muchas de las plantillas con las que me he encontrado son malas para usar Mage::getModel()->load()dentro de los bucles foreach, ya que esta es una mala práctica y, en última instancia, puede consumir grandes cantidades de memoria y recursos del servidor.

Magento tiene una herramienta de análisis de código que puede ayudar a escanear sus archivos de plantilla para determinar si hay alguno de estos fragmentos de código incorrectos:

Otras lecturas:

Además, puede ser útil para todos qué almacenamiento en caché y sesión está utilizando que se define en app/etc/local.xml.

¡Espero que esto ayude!

B00MER
fuente
Lo intentaré y te lo haré saber ...
Bebé en Magento
Limpiamos la carpeta var / session. de lo que resolvió nuestro problema hasta hoy. Pero hoy este problema volvió a ocurrir. luego agregué esto en .htaccess: SetEnv MAGE_IS_DEVELOPER_MODE "true" y descomenta ini_set ('display_errors', 1); esta línea. y <disable_local_modules> verdadero </disable_local_modules>. De lo que recibí este error: magento.stackexchange.com/questions/94559/…
Bebé en Magento
No estoy borrando ninguna sesión después de hacer algunos cambios, si borro la sesión automáticamente resolverá todo el problema. ¿no crees que es algo relacionado con cookies o sesiones? Hay alguna forma de resolver esto ?
Bebé en Magento
@BabyinMagento ¿Pudo resolver el problema en función de la información proporcionada? Si es así, ¿cuál fue el problema para aquellos que experimentaron un problema similar? Gracias.
B00MER
1
Muchas gracias por su ayuda. borramos la carpeta de sesión y ocultamos cosas relacionadas con cookies en varien.php. pero aún así debemos esperar un poco más de tiempo para verificar si tenemos una solución permanente o no. a la derecha tenemos una solución a medida que borramos la carpeta de sesión.
Bebé en Magento
3

Supongo que hay una recurrencia en su código. Edite el archivo lib/Varien/Db/Adapter/Pdo/Mysql.phpy configúrelo $_debugcomo $_logCallStackverdadero. Esto debería registrar la pila de llamadas en el var/debug/pdo_mysql.logarchivo, lo que debería darle una idea si hay una recurrencia en su código cuando se tarda una eternidad en cargar. Tenga en cuenta que este archivo seguirá creciendo muy rápidamente, así que idealmente habilítelo cuando piense que el problema ha comenzado en el sitio.

Otra forma es deshabilitar los módulos / extensiones con errores que cree que podrían causar esto. Esta podría ser también su extensión de precios configurable simple, intente deshabilitarla temporalmente y vea si ayuda a prevenir el problema.

Kalpesh
fuente
Cambié los valores de "$ _debug" y "$ _logCallStack" a verdadero, ahora estoy esperando el archivo pdo_mysql.log. y nuestras carpetas de registros se están llenando demasiado, hay casi 90 gb de registros allí. instalé la extensión configurable simple antes de 2 semanas, este problema estaba allí desde 2 meses. pero aún necesita mirar otros módulos con errores.
Bebé en Magento
No encontré este archivo var / debug / pdo_mysql.log hasta ahora, pero se crearon registros de sistema y excepciones. puedo ver este registro principalmente: "lib / Varien / Simplexml / Config.php en la línea 510"
Bebé en Magento
90 GB de registros? ¡Guauu! Haz una copia de seguridad en un lugar diferente y vacía los archivos. eso debería al menos ayudar a mejorar un poco la velocidad de su sitio.
Kalpesh
Sí, tiene usted razón. seguimos eliminando después de algunas veces. ¿Son esos registros debido a este problema? y hasta ahora no encontré ningún pdo_mysql.log
Bebé en Magento
Verifique el valor de $_debugFileen el archivo Mysql.php y asegúrese de que su vardirectorio tenga los permisos necesarios para crear una carpeta y un archivo.
Kalpesh
2

Tuve el mismo problema en el sitio web de un cliente. Verifique su Magento en busca de malware.

Este es un escenario bien conocido, usualmente es un walware que redirige el contenido de la publicación del usuario a un sitio web externo.

Comience a verificar index.php, generalmente lo piratean. Desplace el código hasta el final, también marque a la derecha y entre las líneas comentadas en el encabezado de la licencia. Los hackers se utilizan para ocultar código de esta manera.

Usted tiene la "carga para siempre" porque intenta contactar sitios web que su ISP bloqueó.

Debería ser bastante fácil encontrar el malware, buscar cadenas "base64", "eval", "mcrypt".

Phoenix128_RiccardoT
fuente
este es nuestro index.php => pastebin.com/N8xnWMa7
Bebé en Magento
nuestro sitio fue pirateado antes de 3 meses, después de eso solo surgió este problema. pero luego tomamos muchas medidas de seguridad desde el lado del servidor. pero, ¿crees que el código pirateado todavía está presente en el sitio y crea problemas?
Bebé en Magento
Bueno, su index.php está bien, pero sus síntomas son realmente como los que he visto en algunos sitios web pirateados por clientes. Le sugiero que realice una búsqueda completa buscando los siguientes patrones: "base64", "eval", "mcrypt", "$ _POST". Le darán toneladas de falsos positivos, por lo que debe verificarlos. Si no encuentra nada malo, le sugiero un análisis de caché o un análisis paso a paso de xdebug.
Phoenix128_RiccardoT
Buscaré esas palabras en los archivos de nuestro sitio.
Bebé en Magento
Estoy encontrando tiempos ilimitados: codificación y decodificación de "base64" textos ........
Bebé en Magento
2

He experimentado un comportamiento similar en un Magento que tenía dos sitios web. El sitio se cargaba bien durante unas pocas páginas y luego se cargaba para siempre.

La configuración de las URL base era incorrecta. La configuración de URL base segura se estableció en el sitio web incorrecto mientras que la URL base no segura se configuró correctamente.

Entonces, para solucionar esto si el administrador ni siquiera funciona correctamente, los valores deben cambiarse en la tabla core_config_data para el sitio web correcto, es decir, establecer la URL correcta con "http: //" y una barra diagonal en el campo de valor correspondiente a la ruta "web / unsecure / base_url" y "web / secure / base_url" para el scope_id correcto que representa el ID del sitio web.

ingrese la descripción de la imagen aquí

Tenga en cuenta que la URL segura es http solo porque era un sitio web de demostración.

Brac
fuente