Programmazione

WordPress ed il problema “Memory Exhausted Error”

A volte ritornano… ed in questo caso si tratta di un bug viscido e ricorrente su WordPress.

Non è ancora ben chiaro di chi sia la colpa: c’è chi parla di bug di gestione della memoria di PHP, chi invece di bug legato a WordPress.

Fatto sta che di recente, con l’ultimo update (e purtroppo era un update di tutto… WordPress, Apache e PHP) mi sono ritrovato con i siti down, con Apache che probabilmente era in coma o stava dialogando con gli alieni…. non saprei.
Come sempre, verificando nei log, il problema era sempre il classico

Fatal error: Allowed memory size of XXXX bytes exhausted (tried to allocate YYYY bytes) in /miopath/miofile/ on line ZZZ

Google alla mano, ho cercato per una soluzione.
Nel 90% dei casi mi sono imbattuto in altri blog o forum dove la soluzione era quella meno indicata…

La memoria non basta? Allora aumentala da PHP o da WordPress con la direttiva define( 'WP_MEMORY_LIMIT', '256M' );

La soluzione non va bene.

  1. quella non è memoria allocata globalmente, ma per singola esecuzione
  2. come diretta conseguenza, se lo script ha un memory leak da qualche parte, prima o poi ti ritroverai nella stessa situazione
  3. ma ancora peggio, potresti anche aver fatto fuori tutta la RAM del server… con conseguenze disastrose

A dirla tutta, ci ho anche provato, portando la memoria di PHP a 2GB… ma tempo mezz’ora di attività su questo sito, ero di nuovo con tutto down.

A riprova che non ha senso. I 256MB che molti consigliano bastano e avanzano. Se proprio volete esagerare, mettete nel php.ini

memory_limit = 512M

Ma non di più, a meno che qualche applicazione specifica richieda un valore maggiore.

Ma tornando al problema, dopo lungo peregrinare, ho trovato un sito dove indicano che la causa è dentro al file

wp-includes/functions.php

e più precisamente qui:

function wp_is_stream( $path ) {

$wrappers = stream_get_wrappers();

$wrappers_re = ‘(‘ . join(‘|’, $wrappers) . ‘)’;

return preg_match( “!^$wrappers_re://!”, $path ) === 1;

}

In rosso la linea incriminata.

La cosa curiosa è che il bug effettivamente esisteva, ma è stato corretto anni fa… eppure ancora oggi il problema si presenta (c’è chi dice solo su Windows, ma ho letto anche di utenti su Linux).

Ora, la funzione PHP richiamata non ha nulla di anomalo… restituisce un array con gli stream disponibili sul server. Non credo abbia un memory leak.
E quella funzione viene usata in due/tre punti dentro a wordpress.
Tutto sta a quello che combina (ammetto di non avere indagato).

Per risolvere temporaneamente il problema (al primo aggiornamento di WordPress dovremo riapplicare la fix) suggeriscono di cambiare la riga sopra evidenziata con l’array degli stream rilevati.

Ad esempio:

function wp_is_stream( $path ) {

$wrappers = array(‘https’, ‘ftps’, ‘compress.zlib’, ‘compress.bzip2’, ‘php’, ‘file’, ‘glob’, ‘data’, ‘http’, ‘ftp’, ‘phar’, ‘zip’);

$wrappers_re = ‘(‘ . join(‘|’, $wrappers) . ‘)’;

return preg_match( “!^$wrappers_re://!”, $path ) === 1;

}

 

Per ottenere l’array, basterà creare una pagina PHP sul sito con un semplice

<?php
print_r(stream_get_wrappers());
?>

 

A quel punto si prendono i valori e li si inseriscono nel codice di WordPress.

Per ora sono 2 giorni che non riscontro anomalie, per cui, se anche tu hai riscontrato questo problema, prova la “mia” soluzione.

Se vuoi leggere il thread dove ho scoperto questa fix, eccoti il link: https://wordpress.org/support/topic/wp_is_stream-crashing-the-server/

 

Lascia una risposta

tredici − 9 =

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.