Cambié de Drupal 7.14 a 7.15 hace tres semanas y, por lo tanto, me encuentro con una serie de errores de límite de memoria muy sofisticados (para mí) . Esos errores ocurren cada vez que intento borrar el caché en el rendimiento o ejecutar scripts de actualización.

Mi empresa de alojamiento ha aumentado mi límite de memoria en php.ini hasta 126 M, 256 M, 512 M e incluso 1024 M. Pero los errores aún ocurren. He migrado mi sitio de compartido a VPS, pero el error aún ocurre increíblemente. No tengo forma ni idea de cómo avanzar.

Aquí están los errores:

• Error grave: tamaño de memoria permitido de 536870912 bytes agotados (intentó asignar 30 bytes) en /home/example/public_html/sites/all/modules/views/views.module en la línea 416

• Error grave: tamaño de memoria permitido de 536870912 bytes agotados (intentó asignar 108 bytes) en /home/example/public_html/includes/menu.inc en la línea 2736

• Error fatal: tamaño de memoria permitido de 536870912 bytes agotados (intentó asignar 71 bytes) en /home/example/public_html/sites/all/modules/chain_menu_access/chain_menu_access.module en la línea 59

• asignar 64 bytes) en /home/example/public_html/sites/all/modules/views/includes/base.inc en la línea 93

También he estado golpeándome la cabeza contra una pared la última vez que tuve problemas de memoria con Drupal. Aquí está mi conocimiento recopilado sobre el tema:

1. Las vistas (pueden) usar mucha memoria

Me encantan algunas vistas (y paneles y CTools y todo lo que Merlinofchaos toca con sus poderosos dedos), pero es posible crear configuraciones con múltiples relaciones que usan mucha memoria. Si deshabilita sus Vistas y el problema de memoria desaparece, es probable que sea una Vista mal construida lo que causa el problema.

¿Qué hacer si es una Vista y realmente necesita esa Vista para funcionar? Para comenzar, intente ponerlo en código (a través de Exportador masivo o características; consulte a continuación. He codificado a mano la funcionalidad similar a Vistas para mejorar el rendimiento con muy poco éxito). Otra idea es rehacer la Vista de una manera diferente: si al final lo que está obteniendo son términos de taxonomía, asegúrese de que el tipo de Vista sea una Vista de taxonomía al crearla; no cree una vista de contenido que use relaciones para llegar a términos de taxonomía.

También podría valer la pena mencionar aquí que los paneles también supuestamente usan mucha memoria; realmente no lo he comparado, así que no puedo confirmar esto.

2. Mover cosas de la base de datos al código es una muy buena práctica.

Me llevó varios sitios de Drupal darme cuenta de esto, pero mantener todo lo que se crea a través de una interfaz de usuario en la base de datos (especialmente las configuraciones de Vistas y Paneles) es una de las peores prácticas de Drupal. ¿Por qué? Aumenta la carga en la base de datos y no se puede controlar la versión. El primer punto es particularmente problemático en términos de uso de memoria: en lugar de simplemente cargar el contenido de la vista desde la base de datos, el sitio también debe cargar los componentes de la vista. Esto se ve exacerbado por la forma en que Drupal usa las tablas: al abstraer todo en el enésimo grado, cada parte de la funcionalidad de Drupal usa una nueva tabla, lo que resulta en algunas solicitudes que unen un bajillion de tablas. Esto da hernias a las personas de informática (advertencia: el enlace es una tontería), pero realmente no se puede evitar con un software tan modular y fácil de usar como lo es Drupal.

¿La solución? Use Bulk Exporter (Incluido con CTools) o Características para empaquetar bits de código que actualmente residen en la base de datos como código de módulo.

3. Los temas también pueden comer memoria

¿Su tema tiene muchos archivos de plantilla (es decir, archivos en themename / templates /)? Si es así, la memoria se consume cada vez que se carga uno de esos archivos. Si está creando plantillas específicamente para evitar que se muestren bits de Drupal, intente:

1. Cambiar los permisos para que ese bit no se muestre para roles específicos de usuarios que no sean administradores.
2. Usando CSS para ocultar elementos.

Obviamente, la primera opción es lo que desea hacer para las cosas que afectan la seguridad: no desea usar CSS para ocultar un botón de "edición" para ciertos usuarios, solo para que luego los muestren a través de Firebug o lo que sea.

4. No te excedas en los módulos contrib

Si bien a veces un sitio necesita muchos módulos contrib, no se exceda. Cada módulo habilitado (nota: habilitado. Los módulos deshabilitados no usan memoria) usa memoria. Esto es un poco obvio, pero vale la pena señalarlo independientemente.

5. El VPS es (a veces) una mentira

En mi experiencia, algunas empresas de alojamiento sin escrúpulos adoran tratar de llevar los sitios de Drupal a los servidores VPS: son más caros y liberan espacio de alojamiento compartido para cada vez más sitios web de WordPress. La situación empeora por el hecho de que los servidores de alojamiento web a menudo no anuncian (o incluso voluntariamente le dicen si se le pregunta) cuál es el límite superior de memoria para el alojamiento compartido.

Lamentablemente, a menudo si un sitio no está bajo mucho tráfico y sigue fallando, es probable que el problema tenga algo más que ver con la configuración de Drupal que con cualquier otra cosa. Empujar a un usuario a VPS simplemente enturbia las aguas y agrega más variables para tratar (¿Es la configuración del servidor web? ¿Configuración de PHP? ¿Configuración de invitado VPS? ¿Configuración de host VPS, incluso?).

6. Cuando todo lo demás falla, clona a localhost y golpéalo con un palo

Esta es una gran razón por la cual las personas usan la metodología de producción de etapas de desarrollo con control de versiones: cuando todo lo demás falla, puede hacer un volcado de base de datos, clonar el sitio en un servidor de prueba local y luego estropear el sitio en el probar el servidor sin preocuparse de romper realmente nada en el servidor de producción.

Para problemas de memoria, esto generalmente significa deshabilitar los módulos uno por uno hasta que quede expuesto el que está causando el problema. También puede señalar problemas relacionados con el alojamiento web: si el sitio funciona perfectamente bien en una instalación local con memoria configurada en algo razonable como 128 MB, entonces sabe que su servidor web está en crack.

tl; dr

Mi instinto es que es chain_menu_access lo que está causando el problema. Intente deshabilitar eso y borrar el caché, vea si funciona.

También agregaré a esta respuesta mientras pienso en otras cosas para probar ...

Puede intentar colocar el generador de perfiles PHP como XHProf o el generador de perfiles incorporado de Xdebug para inspeccionar lo que sucede en la solicitud.

Vistas es un cerdo de memoria. El almacenamiento en caché de Drupal puede ayudar. Drupal solo carga módulos activos, sin embargo, si crean tablas o tienen otros objetos, estos pueden colgar. Solo la desinstalación eliminará la mayoría de los artefactos. Utilizamos la autorización / permisos de drupal y escribimos nuestros propios módulos dentro. No es el mejor, pero el rendimiento es mucho mejor y más fácil de ajustar. Hacemos lo mismo para WP también.

En mi caso, el problema del límite de memoria fue generado por el sistema de caché (módulos Boost y Boost Expire). Esto me da problemas para actualizar el módulo o las vistas. Una vez deshabilitados, los módulos Boost funcionan bien.