Un fatal «Allowed memory size exhausted» termina la petición antes de devolver respuesta válida. Subir el límite puede restaurar servicio si era bajo, pero un bucle, carrito enorme o consulta de plugin consumirá también el nuevo margen.
Comprueba pedidos y pasarela antes de reproducir: el proveedor puede haber aceptado el pago aunque PHP fallara después.
Correlaciona el fatal exacto
Registra hora, ID si existe, tamaño del carrito, método y respuesta HTTP. Localiza el fatal correspondiente.
- bytes permitidos y solicitados
- archivo y línea
- worker y timestamp
- URI de petición
- referencia WooCommerce/pasarelaNo expongas campos, cookies o payloads.
Confirma el límite efectivo
Constantes WordPress, configuración PHP, plan y process manager pueden imponer valores. Comprueba el visto por la petición web, no solo un php.ini quizá inactivo.
error_log( 'Límite de memoria diagnóstico: ' . ini_get( 'memory_limit' ) );Usa logs protegidos temporales y retíralos. Nunca muestres configuración en checkout.
Mide el pico con seguridad
Reproduce en staging con PHP y plugins equivalentes y carrito anonimizado. Compara producto simple, carrito fallido y pasarelas.
memory_get_peak_usage( true ) puede registrar pico sin datos del pedido. Un salto después de un callback es más útil que la línea final, donde solo quedaba memoria agotada. No instales un profiler pesado en producción sin conocer su coste.
Mide varias ejecuciones: la primera puede cargar clases, traducciones y cachés. Registra memoria inicial, pico y diferencia al cargar checkout, recalcular envío, crear pedido y llamar a la pasarela. Así separas un coste fijo alto de un crecimiento acumulativo.
Inspecciona carrito y payloads
Variaciones grandes, add-ons, uploads y bundles recursivos crean arrays enormes. Código propio puede cargar todo el catálogo o pedidos en cada recálculo.
Busca get_posts, WP_Query o wc_get_orders sin límites. Añade límites y consulta solo campos necesarios. No guardes respuestas API grandes o imágenes en sesión y metadatos.
Comprueba si el código deserializa catálogos completos, duplica objetos al convertirlos en arrays o conserva referencias globales. Procesa listas extensas por páginas y libera resultados temporales. No uses unlimited en una petición interactiva.
Revisa plugins y hooks
Checkout recalcula varias veces. Un callback que añade datos en cada update_order_review o se registra repetidamente hace crecer memoria.
Desactiva el componente implicado en staging y compara picos. Actualiza código incompatible y elimina hooks duplicados. Un tema por defecto ayuda a localizar la capa, pero la reparación final debe conservar el diseño requerido.
Si ocurre solo con una pasarela, compara la creación del request y su respuesta. Algunos SDK cargan historiales o payloads excesivos. Actualiza la biblioteca desde el plugin propietario; no edites vendor manualmente.
No edites el núcleo para suprimir el fatal.
Establece un límite justificado
Si el pico normal es sano pero el techo es insuficiente, súbelo con cPanel, Plesk o controles soportados. Deja margen para servidor y workers simultáneos.
512 MB por worker puede agotar RAM con muchos checkouts. Coordina memoria por proceso, número de workers y tráfico. Recarga PHP solo mediante el hosting.
Calcula un presupuesto: memoria de sistema y MySQL, workers simultáneos y pico medido con margen. Observa swapping y procesos terminados. Un límite individual aceptable puede ser peligroso si veinte workers alcanzan el pico a la vez.
Con OPcache, confirma invalidación del despliegue: bytecode antiguo puede mantener el callback ya corregido.
Concilia intentos fallidos
Lista peticiones del incidente y compara órdenes con transacciones. Resuelve pagados-pendientes, duplicados y ausentes antes de reabrir.
No cambies estados en bloque. Añade notas privadas con referencias verificadas.
Busca intents autorizados sin pedido y órdenes duplicadas por reintentos. Coordina con la pasarela antes de pedir al cliente repetir el pago e informa a soporte del intervalo que debe revisar manualmente.
Verifica con carga realista
Completa compras de invitado y cuenta con carritos y pasarelas representativos. Confirma pico por debajo del umbral, un pago, stock y email.
El mantenimiento recurrente debe alertar sobre fatals y tendencias de memoria tras despliegues. Capacidad y código eficiente importan; una no debe ocultar el fallo de la otra.