Diagnosi errore 'Allowed memory size exhausted’

L’errore 'Fatal error: Allowed memory size of X bytes exhausted’ è uno dei più frequenti su WordPress, soprattutto durante import di grandi quantità di dati, generazione PDF o backup. Vediamo come WP Error Monitor lo segnala, come capire chi consuma RAM e quali rimedi applicare.

Anatomia dell’errore

Quando PHP supera il valore di memory_limit definito in php.ini (o sovrascritto da WP_MEMORY_LIMIT), il processo viene terminato. Il messaggio indica i byte richiesti, la quantità già allocata, il file e la riga della allocazione che ha sforato. Quel file non è sempre il colpevole: spesso è solo l’ultima goccia di un consumo cumulativo.

Come capire chi consuma RAM

Usa Query Monitor o New Relic per profilare. In alternativa abilita WPEM_PROFILER=true: WP Error Monitor logga snapshot di memoria ogni 500ms durante la richiesta colpevole, così vedi la crescita nel tempo. Spesso scopri che il problema è un loop che fa get_posts senza paginazione, un'import CSV senza fclose, o un plugin di backup che carica un dump intero in memoria.

Strategie di mitigazione

1) alzare memory_limit (palliativo), 2) paginate query con WP_Query e parametro posts_per_page, 3) usare wpdb->get_results in streaming mode, 4) flush memoria con wp_cache_flush() e unset() variabili grandi, 5) spostare task pesanti in background via WP-Cron o queue (es. Action Scheduler), 6) ottimizzare opcache (opcache.memory_consumption)

Memory leak vs picco isolato

Distinguere memory leak (crescita lenta nel tempo) da picco isolato (singola operazione pesante) è fondamentale per il fix. Il leak emerge dopo ore/giorni di uptime, il picco è immediato. WP Error Monitor con WPEM_PROFILE_MEMORY=true raccoglie campioni di memory_get_usage ogni 100ms durante richieste lunghe: i grafici mostrano se la curva è crescente lineare (leak) o spike (picco). I leak sono tipicamente plugin che non liberano risorse correttamente (mai unset di array grandi, mai fclose di file handle, riferimenti circolari).

Object cache come mitigazione

Object cache via Redis/Memcached riduce drasticamente l’uso di memoria PHP perché le query result vengono cached in memoria condivisa. Per WooCommerce con grandi cataloghi, Redis riduce memoria PHP del 30-50%. Configurazione tipica: Redis su localhost, plugin Redis Object Cache, max memory Redis 256MB con LRU eviction. Importante: la cache può anche mascherare leak, quindi profila prima e dopo per confermare miglioramenti reali.

Profilazione xdebug in dev

Per analisi memory leak deep, xdebug in modalità tracing genera dump completi memoria per richiesta. Setup: xdebug.mode=trace, xdebug.start_with_request=trigger, xdebug.trace_output_dir=/tmp/traces. Riproduci la richiesta colpevole, ottieni file trace con timeline allocazioni. Tool tipo KCacheGrind visualizza i call tree. xdebug ha overhead 10-50x quindi solo in dev. WP Error Monitor profiler è alternativa lightweight (overhead <3%) usabile in staging/prod, ma meno preciso di xdebug. Combinazione efficace: WPEM in prod per identificare quando, xdebug in dev per identificare dove e perché.

Tuning OPcache per ridurre memoria

OPcache mantiene in memoria il bytecode PHP compilato, evitando re-parse ad ogni richiesta. Setup ottimale per WordPress: opcache.memory_consumption=256, opcache.max_accelerated_files=10000, opcache.revalidate_freq=60. Senza OPcache, ogni richiesta PHP riparsa migliaia di file: enorme spreco memoria e CPU. Con OPcache ben configurato, riduzione memoria PHP del 40-60%. Verifica con opcache_get_status(): occupied_memory deve essere stabile, hit_rate sopra 95%, num_cached_scripts coerente con la dimensione del codebase.

Numeri di riferimento per sizing

Per sizing memoria di un sito WordPress in produzione, i nostri numeri di riferimento G Tech sono: blog informativo low-traffic 128MB sufficienti, WooCommerce catalogo medio 256-384MB, WooCommerce alto traffico con plugin marketing 512MB-1GB, multisite enterprise 1GB+ ma con object cache Redis attivo. Memoria oltre 1GB è raro che serva davvero: tipicamente indica memory leak da fixare invece che aumentare arbitrariamente. WP Error Monitor con profiler attivo ti aiuta a distinguere need legittimo da leak che drena risorse senza necessità'.

Procedura passo-passo

1. Filtra WP Error Monitor per 'message contains Allowed memory sizè.
2. Apri l’evento: prendi file/riga e URL chiamato.
3. Se l’URL è admin-ajax o wp-cron, verifica quale action è coinvolta (parametro 'action').
4. Aumenta memoria temporaneamente: aggiungi define('WP_MEMORY_LIMIT', '512M') e define('WP_MAX_MEMORY_LIMIT', '1G') in wp-config.php.
5. Riproduci l’azione e controlla se il problema sparisce o si sposta.
6. Profila la chiamata con WPEM_PROFILER per identificare la funzione esatta.
7. Implementa fix strutturale (paginazione, queue, streaming) e rimetti memory_limit al valore normale.
8. Setta WPEM_PROFILE_MEMORY=true e raccogli dati per 24h.
9. Installa Redis Object Cache se non già presente.

Errori comuni e come risolverli

• Aumento WP_MEMORY_LIMIT senza effetto: Il limite reale è php.ini: modifica memory_limit lato server o usa .user.ini.
• Errore solo in admin: Usa WP_MAX_MEMORY_LIMIT: è il limite dedicato al wp-admin (default 256M).
• Errore casuale: Probabile race condition con cron pesante: sposta il cron in coda Action Scheduler.
• Redis non gestisce eviction: Setta maxmemory-policy allkeys-lru in redis.conf.
• Picchi non riproducibili: Possibile cron pesante in orari specifici: cross-check con WPEM_TRACK_CRON.

Domande frequenti

D: Qual è un valore di memory_limit sensato?
R: 256M è adeguato per la maggior parte dei siti; 512M-1G per WooCommerce con molti plugin.

D: Posso impostare memory_limit per pagina?
R: Sì, con ini_set('memory_limit', '512M') in un mu-plugin se safe_mode disabilitato.

D: WP Error Monitor traccia anche memoria al picco?
R: Sì, cattura memory_get_peak_usage() per ogni evento di severità ERROR o superiore.

D: Posso fare profiling in produzione?
R: Sì, WPEM_PROFILE_MEMORY ha overhead <3%. Usa sampling=10% per ridurre.

D: Quanto tempo serve per identificare un leak?
R: Tipicamente 24-72h di monitoring: il pattern emerge nei grafici.

Hai bisogno di aiuto?

Se vuoi affidare il monitoraggio WordPress al team di G Tech Group, scrivici tramite il modulo di contatto.