"Allowed Memory Size Exhausted" oplossen in WordPress

Als je site Fatal error: Allowed memory size of 268435456 bytes exhausted toont, voeg dan deze regel toe aan wp-config.php, boven de comment /* That's all, stop editing! */: define( 'WP_MEMORY_LIMIT', '256M' );. Daarmee zijn de meeste sites binnen een minuut weer online. Maar lees de rest van deze pagina voordat je verder gaat, want het verhogen van de limiet is een diagnose, geen oplossing. Als de crash terugkomt bij een hoger getal, dan is het echte probleem code die zonder grens geheugen opslokt, en een hoger plafond geeft die code alleen maar meer touw om zichzelf mee op te hangen.

Wat de foutmelding werkelijk betekent

PHP houdt bij hoeveel geheugen elke request heeft gereserveerd. Wanneer één request meer probeert te reserveren dan de memory_limit uit php.ini (of overschreven door WordPress), kapt PHP de request onmiddellijk af met een kritieke fout en print het aantal bytes waarbij het strandde. 268435456 bytes is 256M. 134217728 is 128M. 536870912 is 512M. Het getal na “tried to allocate” vertelt je de omvang van de laatste druppel, niet de omvang van het probleem.

WordPress legt bovenop de PHP-limieten zijn eigen limieten. WP_MEMORY_LIMIT (standaard 40M, of de PHP-limiet als die hoger is) bepaalt de front-end. WP_MAX_MEMORY_LIMIT (standaard 256M) bepaalt bewerkingen aan de beheerkant, zoals de mediabibliotheek en plugin-updates, die terecht meer nodig hebben. WordPress roept bij het laden ini_set('memory_limit', ...) aan op basis van deze constanten, maar alleen als je host ini_set toestaat, en alleen tot de harde bovengrens die je host instelt. Dat laatste is de reden waarom het aanpassen van wp-config.php soms niets lijkt te doen.

Los het op, op volgorde

1. Verhoog de WordPress-limiet in wp-config.php. Dit is het eerste wat je probeert, omdat het omkeerbaar is en verder niets aanraakt.

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Als je niet zeker weet waar deze regels moeten komen, of je wilt meteen de andere gangbare constanten correct instellen, dan schrijft onze wp-config generator een net blok dat je kunt plakken. De plaatsing is belangrijk: alles onder de “stop editing”-regel wordt genegeerd.

2. Als dat niets doet, begrenst je host PHP. Verhoog memory_limit op PHP-niveau. In php.ini:

memory_limit = 256M

Op veel shared hosts kun je php.ini niet rechtstreeks aanpassen. Probeer dan een .user.ini-bestand in je webroot, of stel het in via .htaccess op een Apache/mod_php-setup:

php_value memory_limit 256M

Let op: php_value in .htaccess geeft een 500-fout op nginx of op PHP-FPM-setups, omdat het een Apache/mod_php-directive is. Krijg je een 500 nadat je het hebt toegevoegd, dan is dat de reden: verwijder het en gebruik .user.ini.

3. Controleer de waarde die daadwerkelijk actief is. Vertrouw niet op wat je hebt aangepast; vertrouw op wat PHP rapporteert. Zet een bestandje van één regel in je webroot:

<?php echo ini_get('memory_limit');

Laad het in een browser, lees de waarde uit en verwijder het bestand daarna. Als er nog steeds 128M staat nadat je 256M hebt ingesteld, dan overschrijft je host je en moet je contact met ze opnemen of hun instelling in het controlepaneel gebruiken.

Het deel dat de meeste handleidingen overslaan

Het verhogen van de limiet is diagnose. Zo lees je het resultaat.

Als je 256M instelt en de site blijft bij normaal verkeer overeind, dan had je een terecht plafond dat te laag stond. Dit komt vaak voor bij sites met grote mediabibliotheken, WooCommerce of paginabouwers. Je bent klaar.

Als je 256M instelt en het crasht opnieuw, en daarna 512M en het crasht wéér, stop dan met verhogen. Een normale WordPress-request heeft geen 512M nodig. Wanneer het geheugengebruik zonder plafond blijft oplopen, loopt of stapelt er iets: een plugin die een hele databasetabel in een array laadt, een add_action die zichzelf recursief triggert, een importroutine die alle rijen tegelijk in het geheugen houdt, of twee plugins die binnen dezelfde hook met elkaar vechten. Het verhogen van de limiet lost een ongebonden lus niet op; het verschuift de crash alleen een paar seconden en maakt hem lastiger te reproduceren.

Om de boosdoener te vinden, deactiveer je alle plugins en schakel je over op een standaardthema zoals Twenty Twenty-Four. Als de foutmelding stopt, activeer je ze één voor één opnieuw tot hij terugkomt. Zet de debug-log aan om te achterhalen waar het strandt:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

De kritieke regel in wp-content/debug.log noemt het bestand en regelnummer dat het laatste blok reserveerde. Dat is meestal de lus, of één functieaanroep daarvandaan.

Wat je niet moet doen

Zet WP_MEMORY_LIMIT niet op -1 of 1024M en vergeet het dan. Onbeperkt geheugen lost geen lek op; het laat een op hol geslagen request de hele server opeten, wat elke andere site op dezelfde machine kan platleggen en je een telefoontje van je host oplevert. Een plafond is een veiligheidsmaatregel. Houd er één.

Plak ini_set('memory_limit', '512M') niet in functions.php als primaire oplossing. Het draait bij sommige fouten te laat: als de crash optreedt tijdens het laden van de WordPress-core, voordat de functions.php van je thema wordt uitgevoerd, draait de regel nooit. wp-config.php laadt eerder en is de juiste plek.

Ga er niet van uit dat het een hostingprobleem is en upgrade je pakket niet meteen. Soms is de hosting echt te krap bemeten. Vaak volgt precies dezelfde crash je naar het grotere pakket, omdat de oorzaak meeverhuist in je plugins. Sluit eerst de lus uit; dat is gratis.

Verhoog memory_limit niet om een max_execution_time-fout op te lossen. Dit zijn verschillende limieten met verschillende meldingen. Geheugenuitputting zegt “Allowed memory size … exhausted.” Een time-out zegt “Maximum execution time … exceeded.” De verkeerde verhogen kost je een middag.

Nog steeds vast?

Als je hebt bevestigd dat de actieve limiet werkelijk 256M of hoger is, je hebt getest met alle plugins uit en een standaardthema, en het put nog steeds het geheugen uit, dan heb je een echt lek dat het waard is om in de debug-log na te jagen, geen plafond dat het waard is om te verhogen. Leg de kritieke regel vast, noteer naar welke plugin-map hij verwijst, en dat is je bugrapport. Zet eerst je basisconstanten in wp-config.php goed met de wp-config generator, zodat je zeker weet dat de limieten staan waar je denkt dat ze staan, en ga daarna de log lezen.