Memory_limit alzato ma il sito resta lento: PHP-FPM, query e plugin da controllare

Alzare memory_limit in php.ini o nel file .user.ini fa sparire il messaggio "Allowed memory size exhausted". Non fa sparire la lentezza, se la causa non era davvero la memoria ma un collo di bottiglia a monte. Prima di toccare ancora quel valore, conviene guardare tre punti: i processi PHP-FPM, le query del database, i plugin.

PHP-FPM: i processi sono il limite, non la memoria

Ogni processo PHP-FPM occupa RAM per tutta la durata della richiesta. Se il numero massimo di processi (pm.max_children) è troppo basso rispetto al traffico, le richieste in eccesso aspettano in coda invece di essere servite: il sito sembra lento anche se la CPU non è satura.

Per vederlo, va attivata la pagina di stato di FPM impostando pm.status_path nel pool di configurazione. Il file di stato fornisce informazioni sulla configurazione e il contenuto della pagina di stato di FPM. I campi da guardare sono: "listen queue" (richieste in attesa di un processo libero), "max children reached" (se il tetto massimo è mai stato raggiunto) e "memory peak" (il picco di memoria usato dal pool). Se "listen queue" non è zero o "max children reached" vale 1, il numero di processi è il vero collo di bottiglia, non il valore di memory_limit.

Per calcolare quanti processi la macchina può reggere, la formula di base è:

pm.max_children = RAM disponibile per PHP / RAM media per processo

La RAM media per processo si misura con ps -ylC php-fpm --sort:rss guardando la colonna RSS. Su un server con 4 GB di RAM e un processo medio da 70 MB il calcolo dà circa 57, da arrotondare a un valore prudente di 55-60. Il numero va scritto in /etc/php/[versione]/fpm/pool.d/www.conf e richiede un riavvio di PHP-FPM per entrare in vigore.

Query lente: il database che non si vede

Un sito può restare lento anche con processi PHP-FPM liberi, se ogni richiesta aspetta il database. Lo strumento per scoprirlo è lo slow query log di MySQL/MariaDB, spento di default. Si attiva a runtime con:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log';

Il valore di soglia di default logga solo query sopra i 10 secondi, troppo permissivo per un sito web: abbassarlo a 1 secondo o anche a 0,5 secondi intercetta query che rallentano la pagina senza mai arrivare a un timeout visibile. Per renderlo permanente dopo un riavvio del database, le stesse direttive vanno scritte nel file di configurazione, tipicamente /etc/mysql/my.cnf o /etc/mysql/mysql.conf.d/mysqld.cnf. Il file generato si legge con mysqldumpslow o, su installazioni con Percona Toolkit, con pt-query-digest.

Il plugin che non genera errori ma consuma memoria

L'ultimo sospetto è un plugin che resta sotto la soglia di memory_limit ma la usa quasi tutta, rallentando ogni richiesta senza mai far scattare l'errore fatale. Per individuarlo su WordPress lo strumento di riferimento è Query Monitor, che aggiunge un pannello nella barra di amministrazione e permette di determinare quali plugin generano query duplicate o lente e quanto PHP e memoria consuma ogni componente della pagina.

Un avvertimento della stessa pagina ufficiale del plugin: su pagine con centinaia di query, Query Monitor currently uses more memory than I would like it to, per via della stack trace registrata per ogni query. Su siti già al limite della memoria conviene quindi usarlo per una diagnosi mirata e disattivarlo subito dopo, non lasciarlo attivo in produzione.

In sintesi

Se dopo aver alzato memory_limit il sito è ancora lento, l'ordine di controllo utile è: prima la coda di PHP-FPM (pm.status_path), poi lo slow query log del database, infine Query Monitor per isolare il plugin responsabile. Il valore di memory_limit da solo non dice nulla sul tempo di risposta: dice solo se una richiesta è arrivata o no a esaurire la memoria assegnata.