El error fatal indica el límite de memoria configurado y la asignación que PHP intentó realizar cuando ya no quedaba espacio. El archivo señalado no siempre es quien originó el consumo: quizá solo pidió los últimos bytes después de que otro componente llenara la memoria.
Aumentar el límite puede permitir una carga legítima, pero también puede dejar que un bucle agote todo el servidor. Mide antes de cambiar.
Guarda el error fatal completo
Relaciona la hora de la petición con el registro PHP y anota bytes permitidos, asignación solicitada, archivo, línea y pila de llamadas.
Anota también:
petición web o CLI
URL o acción
versión y controlador de PHP
tamaño del carrito, importación o imagen
cambio reciente de código o configuraciónOculta nombres de cuenta del servidor, valores de consultas y datos de clientes.
Comprueba los límites efectivos
WordPress puede definir WP_MEMORY_LIMIT y WP_MAX_MEMORY_LIMIT, mientras PHP y el hosting imponen sus propios máximos. Consulta el valor dentro del contexto web o CLI que realmente falla.
error_log( 'Memory limit: ' . ini_get( 'memory_limit' ) );
error_log( 'Peak bytes: ' . memory_get_peak_usage( true ) );Utiliza un registro temporal protegido y retíralo después. No publiques la configuración en una página.
Reproduce con entradas medidas
Usa un staging con el mismo PHP y plugins y un conjunto de datos anonimizado. Compara una importación, imagen, página o acción pequeña con la que falla.
Si el pico crece aproximadamente con el número de elementos, probablemente debas procesar por lotes. Si crece en cada callback repetido, busca acumulación o recursión.
Los perfiladores añaden carga; úsalos en staging salvo que la investigación en producción esté controlada expresamente.
Establece una referencia normal
Mide la misma petición con la entrada válida más pequeña y luego con datos representativos. Registra el pico antes y después del callback principal del componente.
Importa más la curva que el número absoluto. Un coste fijo puede ser aceptable; varios megabytes adicionales por cada entrada fallarán al escalar. Repite la petición para detectar cachés o variables estáticas que crecen dentro de un proceso PHP persistente.
Localiza cargas de datos sin límite
Busca en la ruta WP_Query, get_posts(), consultas directas y APIs que recuperen todos los registros. Solicita solo identificadores o los campos necesarios en vez de objetos completos.
$ids = get_posts( array(
'post_type' => 'post',
'posts_per_page' => 100,
'fields' => 'ids',
) );Pagina más en webs grandes. El límite de 100 es un ejemplo, no un tamaño universal.
Revisa el procesamiento de archivos y medios
Una imagen grande ocupa al descomprimirse mucha más memoria que el fichero guardado. Generar PDF, extraer archivos o regenerar miniaturas también puede superar límites razonables.
Comprueba dimensiones en píxeles, profundidad de color y tamaños de imagen activos. Optimiza los originales y procesa medios en lotes acotados mediante CLI o en segundo plano.
No desactives la validación de seguridad de las subidas para ahorrar procesamiento.
Aísla el componente responsable
Usa la pila de llamadas y una comparación controlada para desactivar en staging un solo plugin, función del tema o fragmento propio. Examina aparte los plugins obligatorios y drop-ins.
Un error de memoria después de actualizar puede deberse a otro orden de hooks o a un registro duplicado. Compara versiones y changelogs.
No edites el núcleo ni desactives elementos de producción al azar.
Ajusta la capacidad con responsabilidad
Cuando el pico normal medido sea legítimo y el límite resulte bajo, auméntalo desde cPanel, Plesk o una configuración PHP compatible.
Multiplica el consumo por worker por la concurrencia posible y deja RAM para MySQL, servidor web y sistema operativo. Un techo elevado por petición puede provocar que el sistema mate procesos bajo tráfico.
Para tareas excepcionales de mantenimiento, utiliza CLI con límites planificados propios.
Verifica el pico y la recurrencia
Repite la acción original y un caso límite mayor mientras registras el pico. Confirma que las páginas públicas y las acciones administrativas concurrentes siguen respondiendo.
El mantenimiento recurrente debería seguir errores de memoria y picos después de cada despliegue. La reparación duradera identifica la carga, la acota y establece un límite respaldado por la capacidad real del servidor.