Allowed memory size exhausted in WordPress

Je activeert een plugin, upload een mediabestand of draait een Site Health check, en WordPress stopt met een blok rode tekst die er ongeveer zo uitziet:

Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 8192 bytes) in /home/example/public_html/wp-includes/class-wpdb.php on line 2024

Het pad, het regelnummer en de aantallen bytes wisselen, maar de vorm is altijd hetzelfde. PHP vroeg het besturingssysteem om nog een stukje geheugen, het plafond zei nee, en het script crasht midden in het verzoek.

Wat deze fout eigenlijk betekent

PHP hanteert een geheugenplafond per verzoek dat memory_limit heet. Zodra een script één byte meer wil dan dat plafond toestaat, breekt PHP het verzoek af en schrijft er een fatal error bij in de log. Het lange getal in de melding is dat plafond zelf. 41943040 is gewoon 40 * 1024 * 1024, ofwel 40 MB. Het "tried to allocate"-deel vertelt je hoeveel het script extra wilde op het moment dat het werd gekild.

Op een WordPress-site zijn er twee plafonds tegelijk actief, en weten welke van de twee toesluit bepaalt waar je begint:

• De PHP memory_limit in php.ini. Dit is PHP's eigen plafond. De upstream-default is 128M, maar de meeste managed hosts zetten hem op 256M of 512M. Dit is de harde grens. Niets binnen WordPress kan hierboven komen.
• De WordPress-constanten WP_MEMORY_LIMIT en WP_MAX_MEMORY_LIMIT. WordPress leest die uit wp-config.php. Staat er een waarde die lager is dan de php.ini-waarde? Dan roept WordPress ini_set() aan bij boot om PHP naar die nieuwe waarde op te hogen. Staat er een waarde boven de php.ini-grens? Dan mislukt die ini_set() stilletjes en blijf je vastzitten op de php.ini-waarde. Zie de wp-config.php-instellingenreferentie voor de volledige constant-referentie. De defaults, vastgelegd in wp-includes/default-constants.php, zijn 40M voor de front-end (64M voor multisite) en 256M voor de adminomgeving. Die asymmetrie is de reden dat je de fout soms alleen in wp-admin ziet, of juist alleen op de front-end.

Kortom: WordPress heeft zijn eigen knopje, maar de PHP-knop is degene die het plafond echt afdwingt. WP_MEMORY_LIMIT boven de php.ini-waarde zetten doet dus helemaal niks.

Oorzaken op volgorde van waarschijnlijkheid

1. Een uitgedijde plugin- of themastapel die op elk verzoek wordt geladen. Veruit de meest voorkomende oorzaak. Elke actieve plugin wordt op elk verzoek geladen en gestart, ook als hij op die pagina helemaal niks hoeft te doen. Vijftig plugins met slordige bootstrap-code duwen je baseline al ruim over een plafond van 64 MB heen nog voor WordPress echt werk heeft gedaan.
2. Een upload of import waarbij een groot bestand gedecodeerd moet worden. De image handlers in PHP (GD en Imagick) laden het hele plaatje in geheugen om het te resizen. Een JPEG van 6000x4000 kan makkelijk 150 tot 200 MB werkgeheugen nodig hebben, ook al is de uiteindelijke thumbnail piepklein. Op krappe sites vuurt de fout dan ook voorspelbaar af midden in de upload, en de bezoeker ziet meestal een vage HTTP-fout in de mediabibliotheek in plaats van de fatal hierboven.
3. Een zware admin-taak zoals Site Health, een plugin-update of een database-migratie. Die draaien aan de admin-kant, waar WP_MAX_MEMORY_LIMIT geldt. Staat je php.ini-plafond onder 256 MB? Dan mislukt de admin-uplift naar 256 MB die WordPress wil doen stilletjes, en val je voor zware admin-taken terug op de lagere PHP-grens.
4. De site is zijn hostingpakket simpelweg ontgroeid. Een WooCommerce-shop met 30 plugins en een paar duizend producten op een pakket van 128 MB is niet verkeerd ingericht, hij is gewoon te klein behuisd. Je ziet de fout dan vooral onder load, niet tijdens rustige uren.
5. Een runaway loop of geheugenlek in een plugin of custom code. Zeldzaam, maar in de log ziet het er identiek uit. Het verschil merk je zodra je het plafond verhoogt en de crash precies op dat nieuwe plafond weer terugkomt: het script blijft stapelen tot het wéér aanloopt.

Achterhaal welke oorzaak het is

Voordat je wat voor plafond dan ook verhoogt: zoek eerst uit welk plafond je echt raakt. WP_MEMORY_LIMIT verhogen terwijl de echte bottleneck in php.ini zit is verspilde moeite. En op een echt geheugenlek helpt geen enkele ophoging, je schuift het probleem gewoon door.

Lees de hele foutregel. Het pad in de melding vertelt je welk onderdeel op de stack stond toen het geheugen op raakte. Een pad onder wp-content/plugins/woocommerce-product-importer/ wijst naar de importer. Een pad onder wp-admin/includes/image.php wijst naar image-processing (oorzaak 2). Een pad in wp-includes/class-wpdb.php betekent meestal dat PHP binnen een database-call zat toen het geheugen op raakte. Dat zegt niks over de database zelf, maar wel dat er ergens anders in het verzoek een veel grotere loop draait.

Kijk welke kant van de site crasht. Vuurt de fout alleen in wp-admin? Dan loop je tegen WP_MAX_MEMORY_LIMIT aan, bovenop de php.ini-grens. Vuurt de fout op publieke pagina's? Dan is het WP_MEMORY_LIMIT dat toesluit. Dat onderscheid bepaalt of fix 1 of fix 2 hieronder het juiste startpunt is.

Controleer de huidige plafonds. Zet een kort diagnosebestandje in de root van je WordPress-installatie:

<?php
// memory-check.php, na gebruik weer verwijderen
require __DIR__ . '/wp-load.php';
echo 'php.ini memory_limit: ' . ini_get('memory_limit') . PHP_EOL;
echo 'WP_MEMORY_LIMIT: ' . WP_MEMORY_LIMIT . PHP_EOL;
echo 'WP_MAX_MEMORY_LIMIT: ' . WP_MAX_MEMORY_LIMIT . PHP_EOL;
echo 'peakverbruik nu: ' . size_format(memory_get_peak_usage(true)) . PHP_EOL;

Open https://jouwsite.nl/memory-check.php en lees de vier waarden. Verwachte output op een gezonde site: php.ini memory_limit: 256M, WP_MEMORY_LIMIT: 40M, WP_MAX_MEMORY_LIMIT: 256M, en een peakverbruik dat ruim onder al die waarden zit. Staat php.ini memory_limit op 64M of lager? Dan zit de bottleneck bij je host, en fix 1 of 2 gaat je niks opleveren tot die kant eerst omhoog gaat. Verwijder het bestandje direct nadat je het hebt gelezen.

Fix 1: verhoog WP_MEMORY_LIMIT in wp-config.php

Dit is de standaardfix voor foutmeldingen op de front-end, op voorwaarde dat je php.ini-plafond al hoog genoeg staat. Het is één regel, en hij hangt niet af van Apache, nginx of het hostingpaneel.

1. Download wp-config.php via SFTP. Bewaar het origineel als wp-config.php.backup.

2. Open het bestand en zoek de regel /* That's all, stop editing! Happy publishing. */.

3. Voeg direct daarboven toe:

   // Front-end plafond ophogen vanaf de 40M default.
   define( 'WP_MEMORY_LIMIT', '256M' );

4. Bewaar en upload het bestand terug naar de WordPress-root.

De constante moet vóór wp-settings.php worden geladen, en dat is ook de reden waarom hij boven die comment-regel hoort. Alles wat eronder staat is te laat.

Verifieer: laad het diagnosebestandje nog eens. Je weet dat het werkt zodra WP_MEMORY_LIMIT op 256M staat en php.ini memory_limit nog steeds de waarde laat zien die hij al had. Die combinatie is precies wat je wilt. Doe daarna de oorspronkelijke actie opnieuw. Je weet dat de fix standhoudt zodra de taak zonder fatal doorloopt.

Staat er in het diagnosebestand netjes WP_MEMORY_LIMIT: 256M maar crasht de site nog steeds op een lagere waarde? Dan is je php.ini memory_limit het actieve plafond en wordt de WordPress-constante eronder afgekapt. Ga door naar fix 3.

Fix 2: verhoog WP_MAX_MEMORY_LIMIT voor admin-only fouten

Vuurt de fout alleen af in wp-admin (bijvoorbeeld bij Site Health, een plugin-update of een WooCommerce-migratie)? Dan is WP_MEMORY_LIMIT niet de constante die je nodig hebt. De admin-kant draait op WP_MAX_MEMORY_LIMIT, en die staat standaard op 256M. Ophogen werkt hetzelfde als fix 1.

1. Open opnieuw wp-config.php.

2. Voeg boven de "That's all, stop editing"-regel toe:

   // Admin plafond ophogen vanaf de 256M default.
   define( 'WP_MAX_MEMORY_LIMIT', '512M' );

3. Bewaar en upload.

Zet WP_MAX_MEMORY_LIMIT niet blind hoger zonder eerst even naar het php.ini-plafond te kijken. Als je host PHP afkapt op 256 MB, dan heeft WP_MAX_MEMORY_LIMIT op 512M zetten letterlijk geen effect, en blijft de fout doodleuk op 256 MB afvuren.

Verifieer: herlaad het diagnosebestandje. Je weet dat het werkt als WP_MAX_MEMORY_LIMIT nu op 512M staat. Voer daarna de admin-taak opnieuw uit. Je weet dat de fix houdt zodra de taak zonder fatal afrondt. Crasht hij nog steeds op een waarde onder 512 MB? Dan is het php.ini-plafond de echte grens. Door naar fix 3.

Fix 3: verhoog memory_limit via het hostingpaneel

Dit is de fix die de onderliggende php.ini-waarde aanpast die PHP én WordPress lezen. Bij managed hosting is dit het plafond dat al het andere dicteert. Als je paneel je deze knop geeft, is dit meteen de schoonste ingang.

1. Log in op cPanel en open MultiPHP INI Editor (Plesk: PHP Settings, DirectAdmin: PHP Selector, hPanel: PHP Configuration).
2. Kies het domein van de WordPress-site die de fout geeft.
3. Zet het paneel op Editor Mode als die optie er is. Dan zie je memory_limit als vrije waarde in plaats van een dropdown met vaste keuzes.
4. Zet hem van de huidige waarde naar 256M. Ga niet meteen naar 1024M. Een extreem hoog plafond verbergt echte geheugenlekken, het lost ze niet op.
5. Opslaan. De meeste panelen passen de wijziging direct op het volgende verzoek toe, zonder herstart.

Verifieer: laad het diagnosebestandje nog eens. Je weet dat het werkt zodra php.ini memory_limit op 256M staat. Voer daarna de actie die crashte opnieuw uit. Je weet dat de fix houdt zodra hij zonder fatal afrondt.

Heeft je paneel geen knop voor memory_limit, of zit de waarde op slot? Ga dan naar de escalatie-sectie en open een ticket.

Fix 4: verhoog memory_limit via .htaccess (alleen Apache met mod_php)

Deze werkt alléén op Apache met PHP als module (mod_php), en alléén als je host php_value-directives in .htaccess niet heeft dichtgezet. Hij werkt niet op nginx. Hij werkt niet op Apache met PHP-FPM. Op die setups wordt de directive op zijn best stilletjes genegeerd, en in het slechtste geval krijg je er een 500-fout voor terug.

Weet je niet precies welke SAPI je draait? Sla deze methode dan gewoon over en gebruik fix 1 of fix 3. Je breekt niks door .htaccess hiervoor links te laten liggen.

1. Download .htaccess uit de WordPress-root. Bewaar het origineel als .htaccess.backup.

2. Open het bestand en voeg bovenaan, vóór het # BEGIN WordPress-blok, deze regel toe:

   php_value memory_limit 256M

3. Bewaar en upload.

Verifieer: bezoek de homepage van je site. Je weet dat de directive is geaccepteerd zodra de pagina normaal laadt. Je weet dat je host php_value in .htaccess niet ondersteunt zodra je in plaats daarvan een 500 Internal Server Error krijgt. Gebeurt dat? Haal de regel weer weg, zet .htaccess.backup terug en gebruik fix 3 of fix 1.

Laad daarna nog een keer het diagnosebestandje. php.ini memory_limit hoort nu op 256M te staan. Staat hij nog op de oude waarde? Dan wordt de directive stilletjes genegeerd omdat je op PHP-FPM of nginx draait. Door naar fix 3.

Fix 5: verhoog memory_limit via .user.ini of php.ini

Sommige hostingpakketten ondersteunen .user.ini-overrides. Daarmee kun je de PHP memory_limit aanpassen vanuit de WordPress-rootmap, zonder dat je een paneel-optie of servertoegang nodig hebt.

1. Open de bestandsbeheerder in je hostingpaneel en navigeer naar de WordPress-root (dezelfde map als wp-config.php).
2. Maak een nieuw bestand aan met de naam .user.ini.
3. Zet er één regel in: memory_limit = 256M.
4. Bewaar. PHP-FPM leest .user.ini-bestanden standaard elke 300 seconden opnieuw in, dus wacht even tot vijf minuten voor je gaat testen.

Verifieer: herlaad het diagnosebestandje na vijf minuten. Je weet dat het werkt als php.ini memory_limit nu op 256M staat. Voer daarna de actie opnieuw uit die crashte. Je weet dat de fix houdt zodra hij zonder fatal afrondt.

Doet .user.ini na vijf minuten nog steeds niks? Dan heeft je host per-directory overrides uitgezet. Gebruik dan fix 3, of neem contact op met je host om memory_limit voor je te laten verhogen.

Heb je SSH-toegang? Op een VPS of dedicated server waar je PHP zelf beheert, pas je php.ini direct aan. Op Debian/Ubuntu met PHP-FPM staat die meestal op /etc/php/8.3/fpm/php.ini (zie PHP-versie wijzigen in WordPress voor de volledige upgrade-procedure). Op RHEL/Alma is het /etc/php.ini. Zet memory_limit op 256M en herlaad PHP-FPM (systemctl reload php8.3-fpm) of Apache (systemctl reload apache2), afhankelijk van wat je draait.

Wanneer escaleren

Heb je fixes 1 tot en met 5 geprobeerd en blijft de fout terugkomen, of houdt de fix maar even stand en dan valt hij weer om? Verzamel eerst dit setje voor je een ticket opent of iemand anders erop zet:

• De volledige foutregel uit de PHP-errorlog, mét pad en regelnummer. Minstens drie keer, met tijdstempels, zodat het patroon zichtbaar is.
• De vier waarden uit het diagnosebestandje: php.ini memory_limit, WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT en het peakverbruik op een rustig moment.
• Je WordPress-versie (Dashboard: Updates), PHP-versie en SAPI (Tools: Site Health: Info: Server) en de naam van je hostingpakket.
• De lijst plugins die actief zijn als de fout afvuurt, plus welke specifieke actie de trigger is (plugin-activatie, media-upload, Site Health check, cronjob, front-end pagina).
• Of de site single-site of multisite draait. De defaults verschillen.
• De output van de memory-panel van Query Monitor, als je die veilig kunt installeren. Die laat per request zien welke plugin hoeveel bijdraagt, en is de snelste manier om bij oorzaak 1 een naam op tafel te leggen.

Twee redenen om vroeg te escaleren in plaats van het plafond nóg een keer te verhogen. Als de fix houdt tot de volgende piek en dan precies op het nieuwe plafond valt, heb je waarschijnlijk een lek en geen te krap plafond. En als dezelfde site die op 256 MB prima draaide ineens 512 MB nodig heeft voor hetzelfde werk, is er iets veranderd. Dat "iets" wil je vinden voordat het nóg eens verdubbelt.

Hoe je herhaling voorkomt

Het plafond verhogen is een legitieme oplossing voor een eenmalige taak. Het is geen plan voor een site die hem steeds opnieuw raakt. Drie gewoontes maken geheugenfouten zeldzaam:

• Ruim de pluginlijst op. Elke plugin die je weghaalt is geheugen dat je op elk verzoek terugkrijgt. Loop je actieve plugins langs en gooi alles eruit dat zichzelf niet verdient. Query Monitor wijst de grootverbruikers voor je aan als je twijfelt. De meeste WordPress-sites draaien prima met 10 tot 15 actieve plugins, niet met 40 tot 60.
• Draai uploads en imports in batches. Vuurt de fatal af tijdens een grote import of een mediaregenerate? Dan is de taak te groot voor één request, niet de server te klein. Gebruik WP-CLI voor bulkwerk (wp media regenerate, wp import), en verdeel eigen imports in chunks van 100 tot 500 rijen. WP-CLI draait op de php-cli SAPI waar de wall clock feitelijk weg is, en de kleinere chunks drukken bovendien het piekgeheugen per request flink omlaag.
• Stem het hostingpakket af op wat de site doet. Een WooCommerce-shop met 30 plugins vraagt meer geheugen dan een simpele blog. Als het verhogen van het plafond je maar een paar weken koopt voor de volgende crash, is de site het pakket ontgroeid en niet andersom. Upgraden is goedkoper dan een outage.

Zie je in dezelfde workflow ook Maximum execution time of N seconds exceeded langskomen? Dan kijk je vrijwel zeker naar dezelfde runaway taak van twee kanten: hij draait lang genoeg om zowel het geheugenplafond als de wall clock te raken. Valt de fout samen met trage front-end pagina's en een dashboard dat onder load vastloopt? Kijk dan ook even naar PHP workers exhausted: elke vastzittende worker houdt zijn allocatie open terwijl de wachtrij erachter aandikt. En crasht de site halverwege een request op een geheugenfout? Dan ziet een bezoeker meestal niet de ruwe fatal, maar de melding "Er heeft zich een kritieke fout voorgedaan op deze site". Die drie artikelen zijn de logische vervolgstappen naast dit stuk.