Errores de memoria y tiempo de ejecución en PrestaShop: memory_limit y compañía

Lanzas una importación de productos y a mitad se para con una pantalla en blanco. Una tarea programada que sincroniza stock lleva semanas sin terminar. La exportación de pedidos funciona con un mes pero no con un año. En el registro de errores aparecen mensajes como Allowed memory size of ... bytes exhausted o Maximum execution time of ... seconds exceeded.

Son los dos límites más habituales de PHP, y hay más de los que parece. Vamos a ver cuáles son, dónde se configuran y cuándo tiene sentido subirlos.

Los límites que intervienen

memory_limit

La memoria máxima que puede usar un proceso de PHP. Si la petición la supera, PHP la corta con un error fatal: Allowed memory size exhausted. En la tienda se ve como una pantalla en blanco o un error 500.

max_execution_time

El tiempo máximo, en segundos, que un script puede estar ejecutándose. Al superarlo, PHP lo para: Maximum execution time exceeded. Ojo: en Linux este contador no incluye el tiempo que el script pasa esperando a la base de datos o a una API externa, solo el tiempo de ejecución propio.

Los que están fuera de PHP

Aunque PHP no haya cortado, la petición puede morir antes por otro lado:

• El gestor de procesos de PHP (PHP-FPM) tiene su propio tiempo máximo por petición.
• El servidor web o el proxy (Apache, Nginx, un balanceador o una CDN) cierran la conexión si no reciben respuesta en cierto tiempo. El cliente ve un error 502 o 504, mientras el script quizá sigue ejecutándose detrás.
• La base de datos puede cortar conexiones inactivas o consultas demasiado largas.
• max_input_vars, que no es de memoria ni de tiempo pero da síntomas parecidos: limita cuántos campos acepta un formulario. Una ficha de producto con muchas combinaciones o una pantalla de traducciones puede guardar solo una parte de los datos sin dar ningún error visible.

Dónde se configuran

Depende del hosting:

• En el panel del hosting, en la sección de configuración de PHP, es lo más habitual.
• En un fichero php.ini o .user.ini en la raíz de la web, si el hosting lo permite.
• En la configuración del servidor, si tienes un VPS o un servidor dedicado.

Para saber qué valores tiene de verdad la tienda, no te fíes de lo que dice el panel: compruébalo en la información del servidor del back-office (Parámetros avanzados → Información) o con una página temporal que muestre la configuración de PHP, y bórrala después.

Dónde aparecen en PrestaShop

• Importaciones CSV grandes, sobre todo con imágenes que se descargan de una URL durante la importación.
• Regeneración de miniaturas en catálogos con muchas fotos o fotos muy grandes.
• Tareas programadas de módulos que sincronizan con un ERP, un proveedor o un marketplace.
• Exportaciones de pedidos, clientes o productos de periodos largos.
• Generación de PDFs con muchas facturas a la vez.
• Vaciar la caché o recompilar el contenedor de Symfony en PrestaShop 8 y 9, que necesita bastante memoria de golpe.
• Páginas concretas: una categoría con miles de productos sin paginar, un producto con cientos de combinaciones, una ficha de pedido con muchas líneas.

Cuándo subir el límite y cuándo no

Subir memory_limit o max_execution_time es razonable cuando el proceso es legítimamente grande y puntual: una importación inicial, una migración, una regeneración completa. PrestaShop pide de por sí un mínimo de memoria generoso, y muchos hostings vienen con valores por debajo de lo que la tienda necesita.

Pero si cada vez necesitas más, el problema es otro:

• Un proceso que carga todo en memoria (todos los productos, todos los pedidos) en lugar de trabajar por lotes. Con el catálogo de hoy cabe; con el del año que viene, no.
• Un bucle que no termina o que procesa lo mismo una y otra vez, por un error del módulo.
• Consultas sin índice sobre tablas que han crecido, que tardan cada vez más.
• Llamadas a APIs externas lentas dentro del mismo proceso, una por producto.

Si un límite enorme «arregla» una página normal de la tienda, como una categoría o una ficha, no está arreglado: esa página consume recursos que no debería, y bajo tráfico tirará el servidor.

Cómo diagnosticarlo

1. Lee el mensaje completo en el registro de errores de PHP: dice el fichero y la línea donde se agotó la memoria o el tiempo. A veces es la línea de un módulo concreto; otras, una función del núcleo llamada desde un módulo.
2. Distingue web y terminal: ¿el fallo es al pedir una URL o al lanzar un script por consola? Cada uno tiene sus límites.
3. Mira el código de respuesta: un 500 suele ser PHP; un 502 o 504, el servidor web o el proxy cansado de esperar.
4. Reprodúcelo en una copia, activando el modo depuración de PrestaShop, que muestra el error en pantalla en lugar de una página en blanco.
5. Comprueba si crece con los datos: si falla con un año y no con un mes, el proceso no trabaja por lotes.

Buenas prácticas para los procesos largos

• Lanza las tareas pesadas por terminal, no pidiendo una URL, siempre que el módulo lo permita.
• Divide las importaciones grandes en ficheros más pequeños.
• Programa las tareas pesadas fuera de las horas de tráfico y evita que dos coincidan.
• Usa módulos que trabajen por lotes y retomen donde lo dejaron si se interrumpen.
• Mantén PrestaShop, PHP y módulos actualizados: las versiones modernas de PHP consumen menos memoria y son más rápidas con el mismo código.

Cómo resolverlo en PrestaShop

RKR Sentinel te avisa por Telegram cuando la tienda da errores de memoria agotada, tiempos agotados, fatales o respuestas 500, con el mensaje, el fichero y la línea, un extracto del código, la traza, la URL y las versiones, sin tener que activar el modo depuración en producción. Cada error se agrupa por su huella para que las repeticiones no te llenen el chat. Si el problema está en un proceso que hay que rehacer para que trabaje por lotes, o en límites del servidor que no sabes dónde se configuran, con un bono de horas de soporte de Rekire lo diagnosticamos sobre una copia y lo corregimos.