Un fatal «Allowed memory size exhausted» acaba la petició abans de retornar una resposta vàlida. Augmentar el límit pot restaurar servei si era baix, però un bucle, carretó enorme o consulta defectuosa també consumirà el marge nou.
Comprova comandes i passarel·la abans de reproduir: el proveïdor pot haver acceptat el pagament encara que PHP fallés després.
Correlaciona el fatal exacte
Registra hora, ID si existeix, mida del carretó, mètode i resposta HTTP. Localitza el fatal corresponent.
- bytes permesos i sol·licitats
- fitxer i línia
- worker i timestamp
- URI de petició
- referència WooCommerce/passarel·laNo exposis camps, cookies o payloads.
Confirma el límit efectiu
Constants WordPress, configuració PHP, pla i process manager poden imposar valors. Comprova el que veu la petició web, no només un php.ini que potser no s’aplica.
error_log( 'Límit de memòria diagnòstic: ' . ini_get( 'memory_limit' ) );Utilitza logs protegits temporals i retira’ls. No mostris configuració al checkout.
Mesura el pic amb seguretat
Reprodueix a staging amb PHP i plugins equivalents i un carretó anonimitzat. Compara producte simple, carretó fallit i passarel·les.
memory_get_peak_usage( true ) pot registrar el pic sense dades de l’ordre. Un salt després d’un callback és més útil que la línia final. No instal·lis un profiler pesat a producció sense conèixer-ne el cost.
Mesura diverses execucions. Registra memòria inicial, pic i diferència en carregar checkout, recalcular enviament, crear comanda i cridar la passarel·la. Així separes cost fix de creixement acumulatiu.
Inspecciona carretó i payloads
Variacions grans, add-ons, uploads i bundles recursius creen arrays enormes. El codi propi pot carregar tot el catàleg o comandes a cada recàlcul.
Busca get_posts, WP_Query o wc_get_orders sense límits. Consulta només camps necessaris i no guardis respostes API grans o imatges a la sessió.
Comprova si es deserialitzen catàlegs complets, es dupliquen objectes en arrays o es conserven referències globals. Processa llistes per pàgines i allibera resultats temporals.
Revisa plugins i hooks
Checkout recalcula diverses vegades. Un callback que afegeix dades a cada update_order_review o es registra repetidament fa créixer la memòria.
Desactiva el component implicat a staging i compara pics. Actualitza codi incompatible i elimina hooks duplicats. Un tema per defecte ajuda a localitzar la capa, però la solució final ha de conservar el disseny.
Si només passa amb una passarel·la, compara request i resposta. Alguns SDK carreguen historials o payloads excessius. Actualitza la biblioteca des del plugin propietari, no editis vendor.
Estableix un límit justificat
Si el pic normal és sa però el sostre és insuficient, augmenta’l amb cPanel, Plesk o controls compatibles. Deixa marge per al servidor i workers simultanis.
512 MB per worker pot esgotar RAM amb molts checkouts. Calcula memòria de sistema i MySQL, processos simultanis i pic amb marge. Observa swapping i processos terminats. Recarrega PHP només mitjançant el hosting.
Amb OPcache, confirma la invalidació del desplegament.
Concilia intents fallits
Llista peticions de l’incident i compara ordres amb transaccions. Resol pagats-pendents, duplicats, intents autoritzats sense comanda i ordres absents abans de reobrir.
No canviïs estats en bloc. Afegeix notes privades i coordina amb la passarel·la abans de demanar repetir el pagament.
Verifica amb càrrega realista
Completa compres de convidat i compte amb carretons i passarel·les representatius. Confirma pic sota el llindar, un pagament, estoc i correu.
Repeteix diverses peticions concurrents en un entorn de càrrega controlat i comprova RAM total, temps de resposta i cua de workers, no només el pic d’una sola execució.
El manteniment recurrent ha d’alertar sobre fatals i tendències després de desplegaments. Capacitat i codi eficient importen; una no ha d’ocultar el problema de l’altra.