Errori di memoria e di tempo di esecuzione in PrestaShop: memory_limit e compagnia

Avvii un'importazione di prodotti e a metà si ferma con una pagina bianca. Un'attività pianificata che sincronizza lo stock non finisce da settimane. L'esportazione degli ordini funziona con un mese ma non con un anno. Nel log degli errori compaiono messaggi come Allowed memory size of ... bytes exhausted o Maximum execution time of ... seconds exceeded.

Sono i due limiti più comuni di PHP, e ce ne sono più di quanto sembri. Vediamo quali sono, dove si configurano e quando ha senso alzarli.

I limiti in gioco

memory_limit

La memoria massima che un processo PHP può usare. Se la richiesta la supera, PHP la interrompe con un errore fatale: Allowed memory size exhausted. Nel negozio si vede come una pagina bianca o un errore 500.

max_execution_time

Il tempo massimo, in secondi, per cui uno script può restare in esecuzione. Superato questo tempo, PHP lo ferma: Maximum execution time exceeded. Attenzione: su Linux questo contatore non include il tempo che lo script passa ad aspettare il database o un'API esterna, ma solo il tempo di esecuzione vero e proprio.

Quelli al di fuori di PHP

Anche se PHP non l'ha interrotta, la richiesta può morire prima per un'altra via:

• Il gestore dei processi PHP (PHP-FPM) ha un proprio tempo massimo per richiesta.
• Il server web o il proxy (Apache, Nginx, un bilanciatore o una CDN) chiudono la connessione se non ricevono risposta entro un certo tempo. Il cliente vede un errore 502 o 504, mentre lo script magari continua a girare dietro le quinte.
• Il database può chiudere le connessioni inattive o le query troppo lunghe.
• max_input_vars, che non riguarda la memoria né il tempo ma dà sintomi simili: limita quanti campi accetta un modulo. Una scheda prodotto con molte combinazioni o una schermata di traduzioni può salvare solo una parte dei dati senza mostrare alcun errore visibile.

Dove si configurano

Dipende dall'hosting:

• Nel pannello dell'hosting, nella sezione di configurazione di PHP: è il caso più comune.
• In un file php.ini o .user.ini nella radice del sito, se l'hosting lo consente.
• Nella configurazione del server, se hai un VPS o un server dedicato.

Per sapere quali valori ha davvero il negozio, non fidarti di quello che dice il pannello: verificalo nelle informazioni del server nel back office (Parametri avanzati → Informazioni) o con una pagina temporanea che mostri la configurazione di PHP, e cancellala dopo.

Dove compaiono in PrestaShop

• Importazioni CSV grandi, soprattutto con immagini scaricate da un URL durante l'importazione.
• Rigenerazione delle miniature in cataloghi con molte foto o foto molto grandi.
• Attività pianificate di moduli che si sincronizzano con un ERP, un fornitore o un marketplace.
• Esportazioni di ordini, clienti o prodotti di periodi lunghi.
• Generazione di PDF con molte fatture insieme.
• Svuotare la cache o ricompilare il container di Symfony in PrestaShop 8 e 9, che richiede parecchia memoria tutta in una volta.
• Pagine specifiche: una categoria con migliaia di prodotti senza paginazione, un prodotto con centinaia di combinazioni, una scheda ordine con molte righe.

Quando alzare il limite e quando no

Alzare memory_limit o max_execution_time è ragionevole quando il processo è legittimamente grande e occasionale: un'importazione iniziale, una migrazione, una rigenerazione completa. PrestaShop richiede di per sé un minimo di memoria generoso, e molti hosting arrivano con valori inferiori a quelli di cui il negozio ha bisogno.

Ma se ogni volta ne serve di più, il problema è un altro:

• Un processo che carica tutto in memoria (tutti i prodotti, tutti gli ordini) invece di lavorare a lotti. Con il catalogo di oggi ci sta; con quello dell'anno prossimo, no.
• Un ciclo che non finisce o che elabora sempre la stessa cosa, per un errore del modulo.
• Query senza indice su tabelle cresciute, che richiedono sempre più tempo.
• Chiamate lente ad API esterne all'interno dello stesso processo, una per prodotto.

Se un limite enorme «sistema» una pagina normale del negozio, come una categoria o una scheda, non è sistemata: quella pagina consuma risorse che non dovrebbe, e sotto traffico manderà giù il server.

Come diagnosticarlo

1. Leggi il messaggio completo nel log degli errori di PHP: indica il file e la riga in cui si è esaurita la memoria o il tempo. A volte è la riga di un modulo specifico; altre, una funzione del core chiamata da un modulo.
2. Distingui web e terminale: il guasto si verifica richiamando un URL o avviando uno script da console? Ognuno ha i suoi limiti.
3. Guarda il codice di risposta: un 500 di solito è PHP; un 502 o 504, il server web o il proxy stanco di aspettare.
4. Riproducilo su una copia, attivando la modalità di debug di PrestaShop, che mostra l'errore a schermo invece di una pagina bianca.
5. Verifica se cresce con i dati: se fallisce con un anno e non con un mese, il processo non lavora a lotti.

Buone pratiche per i processi lunghi

• Avvia le attività pesanti da terminale, non richiamando un URL, ogni volta che il modulo lo consente.
• Dividi le importazioni grandi in file più piccoli.
• Pianifica le attività pesanti fuori dalle ore di traffico ed evita che due coincidano.
• Usa moduli che lavorino a lotti e riprendano da dove si erano fermati se vengono interrotti.
• Mantieni aggiornati PrestaShop, PHP e moduli: le versioni moderne di PHP consumano meno memoria e sono più veloci con lo stesso codice.

Come risolverlo in PrestaShop

RKR Sentinel ti avvisa su Telegram quando il negozio dà errori di memoria esaurita, tempi scaduti, errori fatali o risposte 500, con il messaggio, il file e la riga, un estratto del codice, lo stack trace, l'URL e le versioni, senza dover attivare la modalità di debug in produzione. Ogni errore viene raggruppato per impronta, così le ripetizioni non ti riempiono la chat. Se il problema è in un processo da rifare perché lavori a lotti, o in limiti del server che non sai dove si configurano, con un pacchetto di ore di assistenza di Rekire lo diagnostichiamo su una copia e lo correggiamo.