Wat betekent Allowed memory size exhausted in WordPress?

Eén PHP-verzoek probeerde meer geheugen te reserveren dan de effectieve memory_limit toestaat. De melding noemt vaak hoeveel bytes al waren toegestaan en hoeveel extra bytes PHP probeerde te reserveren, maar wijst niet automatisch de echte veroorzaker aan.

Wat is het verschil tussen WP_MEMORY_LIMIT en PHP memory_limit?

PHP memory_limit is de effectieve limiet per PHP-script. WP_MEMORY_LIMIT is de hoeveelheid die WordPress voor normale verzoeken probeert aan te vragen. WordPress kan de PHP-limiet alleen verhogen als de server runtimewijzigingen toestaat en de hostinggrens dat accepteert.

Waarvoor is WP_MAX_MEMORY_LIMIT bedoeld?

WordPress gebruikt WP_MAX_MEMORY_LIMIT als hogere aanvraag voor geheugenintensieve beheer-, afbeeldings- en achtergrondtaken. Het is geen garantie dat PHP of je hostingprovider die hoeveelheid toestaat en het hoort de gewone limiet niet onbeperkt te vervangen.

Welke plugin gebruikt te veel geheugen?

De bestandsnaam op de fatale foutregel is alleen het punt waar de laatste allocatie mislukte. Combineer tijdstip, actie en logregels en test verdachte plugins één voor één, bij voorkeur in staging, om de werkelijke verbruiker of combinatie te vinden.

Kan een grote afbeelding een WordPress-geheugenfout veroorzaken?

Ja. Bij beeldbewerking telt vooral het ongecomprimeerde aantal pixels en de verwerking, niet alleen de bestandsgrootte op schijf. Verklein een testafbeelding en controleer of dezelfde bewerking dan wel slaagt voordat je de algemene limiet wijzigt.

Mag ik PHP memory_limit op -1 zetten?

Niet op een publieke WordPress-site. PHP gebruikt -1 voor geen geheugenlimiet, waardoor een fout proces veel servergeheugen kan verbruiken. Kies alleen een begrensde, door de host ondersteunde waarde en herstel die na de diagnose.

Wanneer moet ik de hostingprovider inschakelen voor een memory limit-fout?

Doe dat als de effectieve limiet niet verandert, je geen PHP- of serverlogs hebt, het hostingpakket een harde grens gebruikt, meerdere processen tegelijk uitvallen of de site onder belasting serverbreed geheugen tekortkomt.

WordPress memory limit-fout oplossen (2026)

De melding Allowed memory size exhausted betekent dat één PHP-verzoek meer geheugen wilde gebruiken dan de effectieve memory_limit toestaat. Bevestig eerst de fatale fout in een beschermd log, meet daarna de werkelijk actieve limiet en isoleer de verbruiker voordat je eventueel één begrensde, tijdelijke verhoging test.

Drie geheugeninstellingen die niet hetzelfde zijn

Een WordPress-site kan meerdere waarden tonen. Begrijp eerst welke laag je bekijkt:

PHP memory_limit is de effectieve maximale hoeveelheid geheugen die één PHP-script mag reserveren. PHP beschrijft dit als bescherming tegen scripts die al het servergeheugen opslokken.
WP_MEMORY_LIMIT is de hoeveelheid die WordPress voor normale verzoeken aan de voorkant probeert aan te vragen.
WP_MAX_MEMORY_LIMIT is de hogere aanvraag die WordPress kan gebruiken voor beheer, beeldverwerking, cron en andere geheugenintensieve contexten.

De officiële WordPress-uitleg over PHP-optimalisatie vermeldt standaard 40 MB voor WP_MEMORY_LIMIT op een gewone installatie, 64 MB op Multisite en 256 MB voor WP_MAX_MEMORY_LIMIT. Dit zijn WordPress-standaarden, geen advies voor iedere site en geen garantie dat de server ze toestaat.

WordPress kan alleen via PHP proberen de limiet te verhogen als die instelling tijdens runtime wijzigbaar is. De functie wp_raise_memory_limit() kan mislukken en verlaagt een al hogere limiet niet. De waarde in wp-config.php, het hostingpaneel en Site Health kunnen daarom verschillen.

Controleer of het echt een geheugentekort is

Een geheugenfout bevat meestal tekst als:

Allowed memory size of ... bytes exhausted

Dat is iets anders dan Maximum execution time exceeded, een uploadlimiet, volle schijfruimte of een algemene 500-status zonder fatale geheugenregel. Gebruik bij een tijdslimiet de aparte max execution time-handleiding. Zie je alleen een serverstatus, begin dan bij WordPress 500 Internal Server Error.

De bestandsnaam aan het eind van de fatale regel is het punt waar PHP geen extra geheugen meer kreeg. Dat bestand is niet automatisch de oorzaak. Een plugin kan eerder een grote dataset hebben opgebouwd, waarna WordPress-core bij een kleine volgende allocatie faalt.

Bereid back-up en rollback voor

Maak een database-export en een bestandenback-up voordat je wp-config.php, PHP-instellingen, plugins of thema's wijzigt. Gebruik de officiële WordPress-back-upinstructies en controleer of je weet hoe je de kopie herstelt.

Leg daarnaast vast:

de exacte handeling die faalt;
het tijdstip en de volledige fatale foutregel, opgeschoond van gevoelige gegevens;
de huidige effectieve PHP-limiet;
aanwezige WP_MEMORY_LIMIT- en WP_MAX_MEMORY_LIMIT-regels;
de laatste plugin-, thema-, PHP- of importwijziging.

Wijzig één laag, herhaal dezelfde handeling en zet de oude waarde terug als het resultaat niet verbetert. Toon foutdetails nooit op productie en log geen formulierinhoud, tokens, cookies of persoonsgegevens.

Stap voor stap de WordPress-geheugenfout oplossen

1. Bepaal welke route of taak faalt

Controleer of de fout optreedt op de voorkant, in /wp-admin/, bij een upload, import, back-up, update of geplande taak. Test niet meteen met een andere handeling. Een beheerupdate kan WP_MAX_MEMORY_LIMIT proberen te gebruiken, terwijl een gewone pagina onder WP_MEMORY_LIMIT draait.

Noteer ook de omvang van de invoer: aantal importregels, afbeeldingsafmetingen, exportperiode of aantal geselecteerde items. Werkt een kleine test wel en een grote niet, dan is de taakomvang relevant. Dat betekent nog niet dat alleen meer geheugen de juiste permanente oplossing is.

2. Lees een beschermd PHP- of serverlog

Controleer eerst de PHP-errorlog van je hostingprovider rond het genoteerde tijdstip. Als WordPress ver genoeg opstart, kun je kort de officiële WordPress-debuglogging gebruiken met logging aan en WP_DEBUG_DISPLAY op false.

Een productieconfiguratie voor tijdelijke diagnose houdt fouten buiten de pagina:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Bescherm debug.log tegen publieke toegang, deel alleen noodzakelijke opgeschoonde regels en verwijder of archiveer het bestand na de test. WordPress-logging vangt niet iedere vroege PHP- of serverfout, dus een leeg log sluit een geheugenprobleem niet uit.

3. Meet de effectieve PHP memory_limit

Open Gereedschap > Sitediagnose > Informatie > Server als het beheergedeelte werkt en noteer de PHP-geheugenlimiet. Vergelijk die met het hostingpaneel en met een eventuele host-specifieke PHP-configuratie. Gebruik geen publiek bereikbaar phpinfo()-bestand, want dat kan serverinformatie lekken.

Controleer na iedere limietwijziging opnieuw de effectieve waarde in dezelfde PHP-context. Een CLI-proces, cronproces en webverzoek kunnen verschillende configuratiebestanden of runtimes gebruiken. Een gewijzigd veld in het paneel bewijst pas iets als het getroffen verzoek de nieuwe waarde werkelijk ziet.

4. Controleer WordPress-constanten en hun plaats

Download wp-config.php en bewaar een ongewijzigde kopie. Zoek naar dubbele definities van WP_MEMORY_LIMIT en WP_MAX_MEMORY_LIMIT. De regels moeten vóór het laden van wp-settings.php staan.

De officiële wp-config.php-documentatie legt uit dat WordPress alleen probeert te verhogen wanneer de huidige PHP-waarde lager is en de host dat toestaat. Een tijdelijke, begrensde test kan er zo uitzien:

define( 'WP_MEMORY_LIMIT', '128M' );

Dit is een voorbeeld, geen universele doelwaarde. Kies alleen de eerstvolgende eindige waarde die bij de huidige limiet, taak en hostingcapaciteit past. Verander WP_MAX_MEMORY_LIMIT alleen als juist een beheer-, afbeeldings- of achtergrondtaak faalt en je die context hebt bevestigd.

Upload de aangepaste kopie, controleer de effectieve limiet en herhaal exact één foutgevende handeling. Verandert de effectieve waarde niet, zet dan de oude wp-config.php terug en vraag de host welke PHP-laag leidend is.

5. Wijzig zo nodig de PHP-laag via de host

PHP definieert memory_limit als de maximale geheugenallocatie per script. De officiële PHP-handleiding vermeldt dat -1 de limiet volledig uitschakelt. Gebruik -1 niet op een publieke WordPress-site.

Pas de PHP-laag alleen aan via de methode die jouw host documenteert, bijvoorbeeld het hostingpaneel of een beheerde PHP-instelling. Voeg niet tegelijk waarden toe aan php.ini, .user.ini, .htaccess en wp-config.php. Niet iedere serverinterface leest dezelfde bestanden en een ongeldige .htaccess-richtlijn kan een 500-fout veroorzaken.

Kies een begrensde waarde die binnen de accountcapaciteit past. Controleer daarna de effectieve waarde, voer één test uit en herstel de oude waarde als de fatale fout ongewijzigd terugkomt.

6. Isoleer de plugin of integratie

Als de log of tijdlijn naar een pluginupdate, import, back-up of rapport wijst, schakel dan eerst die ene plugin uit of draai de wijziging terug. Test bij voorkeur in staging met een kopie van dezelfde invoer.

Kun je niet inloggen, hernoem via SFTP alleen de verdachte pluginmap. Werkt de site niet beter, zet de originele naam direct terug. Wanneer geen kandidaat bekend is, kun je de normale plugins tijdelijk gezamenlijk uitschakelen door wp-content/plugins te hernoemen en daarna één voor één terug te brengen.

Let op dat de laatste genoemde bestandsregel niet per se de veroorzaker is. Bevestig met dezelfde handeling, dezelfde invoer en een duidelijk verschil in piekverbruik of resultaat.

7. Controleer thema en maatwerkcode

Treedt de fout alleen op bij één template of na een themawijziging, test dan in staging met een geïnstalleerd standaardthema. Herstel de oorspronkelijke toestand als het probleem blijft. Pas niet rechtstreeks WordPress-core aan.

Bekijk in maatwerkcode vooral onbegrensde lussen, arrays die steeds groter worden, het in één keer laden van alle berichten, grote API-responsen en recursieve callbacks. Verwerk grote verzamelingen in begrensde delen en geef tijdelijke objecten vrij wanneer ze niet meer nodig zijn. Laat een ontwikkelaar meten in plaats van op gevoel code te verwijderen.

8. Verklein uploads, imports en afbeeldingswerk

Een gecomprimeerde afbeelding kan op schijf klein zijn maar tijdens decoderen en schalen veel werkgeheugen vragen. Test met kleinere pixelafmetingen en één bestand. Als dat werkt, stel dan veilige bronafmetingen vast in plaats van de serverlimiet voor iedere bezoeker te vergroten.

Verdeel grote imports en exports in batches. Vraag alleen benodigde velden op, beperk perioden en voorkom dat dezelfde dataset meerdere keren tegelijk in geheugen staat. Start niet meerdere zware taken parallel terwijl je een limietprobleem onderzoekt.

Controleer bij geplande taken of dezelfde job dubbel wordt gestart of blijft hangen. Een hogere limiet maakt een oneindige lus niet correct, maar laat die alleen langer of zwaarder draaien.

9. Controleer serverbreed geheugen en gelijktijdigheid

memory_limit geldt per PHP-script, niet als reservering voor de hele server. Veel gelijktijdige processen die ieder hun limiet naderen kunnen samen de account- of servercapaciteit overschrijden. Dan kan de provider processen beëindigen voordat één script zijn PHP-limiet bereikt.

Vraag de host om geheugengebruik, proceslimieten en beëindigde workers rond het exacte tijdstip te controleren. Deel de taak, route en tijd, maar geen inloggegevens of volledige logs. Een serverbreed capaciteitsprobleem los je niet betrouwbaar op met alleen WP_MEMORY_LIMIT.

10. Bevestig de oorzaak en draai de tijdelijke verhoging terug

Herhaal na de reparatie de oorspronkelijke handeling met dezelfde invoer en controleer de logs. Test ook startpagina, beheer, geplande taken en relevante formulieren. Verhoogde capaciteit zonder herhaalbare fout is nog geen bewezen oplossing.

Zet de tijdelijke limiet terug naar de afgesproken productie-instelling zodra de verbruiker is hersteld of begrensd. Verwijder debugregels, houd WP_DEBUG_DISPLAY uit en ruim gevoelige logs op. Noteer oorzaak, piekactie, oude en nieuwe effectieve waarde en rollback.

Geen vaste limiet garandeert dat de fout niet terugkomt. Nieuwe plugins, grotere imports en meer gelijktijdige processen kunnen het profiel veranderen, dus bewaak vooral de veroorzakende taak.

Veelgemaakte fouten

WP_MEMORY_LIMIT gelijkstellen aan de PHP-limiet. WordPress doet een verzoek, maar de effectieve serverinstelling kan anders zijn.
Alleen de laatste bestandsnaam uit de fout aanwijzen. Daar mislukte de allocatie, maar eerder geladen code kan het geheugen hebben verbruikt.
memory_limit op -1 zetten. Daarmee verdwijnt een belangrijke begrenzing voor foutieve processen.
De limiet in meerdere configuratiebestanden tegelijk wijzigen. Dan is onduidelijk welke PHP-laag werkelijk geldt.
Een onbeperkt grote import opnieuw starten. Verklein de invoer en voorkom parallelle zware taken.
Alle plugins tegelijk verwijderen. Schakel gecontroleerd uit en behoud instellingen en rollback.
Een kleine bestandsgrootte verwarren met weinig beeldgeheugen. Pixelafmetingen en bewerkingen bepalen veel van het werkverbruik.
Debugfouten aan bezoekers tonen. Houd WP_DEBUG_DISPLAY uit op productie en bescherm logs.
De hogere limiet permanent laten staan zonder oorzaakanalyse. Een lek, lus of onbegrensde query kan dan later zwaarder terugkomen.

Wanneer je beter stopt

Stop als de effectieve waarde niet reageert op een gedocumenteerde wijziging, de site serverbreed processen verliest, je geen herstelbare back-up hebt of een productie-import actuele gegevens kan overschrijven. Laat hosting de PHP-configuratie en accountcapaciteit controleren en laat een ontwikkelaar de specifieke taak meten.

Geef tijdstip, route, handeling, invoeromvang, effectieve limiet en opgeschoonde fatale regel door. Deel geen tokens, cookies, persoonsgegevens of volledige configuratie. Bekijk voor andere PHP-storingen de kritieke WordPress-fout, het witte scherm of ga terug naar de WordPress-hub.

Wil je dat iemand het geheugenverbruik en de veilige herstelroute gecontroleerd onderzoekt, vraag een offerte aan via WhatsApp, mail naar w.bouwmeester@bouwmeesterconsultancy.nl of bel 0628963636.