Contact
← Terug naar kennisbank HOSTING

Allowed memory size of X bytes exhausted — uitgelegd en opgelost

Site valt om met een witte pagina, en in je error_log staat: Fatal error: Allowed memory size of 134217728 bytes exhausted. Reflex: PHP-geheugen verhogen. Maar in een derde van de gevallen lost dat niets op — dan is de fout het symptoom van slecht functionerende code. Deze gids legt uit wat de melding betekent, hoe je 'm verhoogt per CMS en control panel, én wanneer hoger zetten alleen het probleem verschuift.

14 min lezen · Laatst gecheckt:

De fout in z'n volle vorm ziet er zo uit:

Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes) in /home/site/wp-includes/post.php on line 2342

Drie dingen om hieruit te lezen voordat je ook maar iets verandert:

  • Het toegestane geheugen: 134217728 bytes = 128 MB. (Tabel verderop voor het omrekenen)
  • De grootte van de allocatie die faalde: 20480 bytes = 20 KB. Een kleine allocatie betekent dat het script al bijna 128 MB gebruikt — een groot probleem dus, niet één enkele dikke operatie
  • Het bestand en regelnummer: wp-includes/post.php regel 2342. Dat is wáár de allocatie crashte, niet noodzakelijk wáár de oorzaak zit

Bytes naar megabytes — handige tabel

De meldingen variëren in cijfers. Dit is wat je in de praktijk tegenkomt:

  • 33554432 bytes = 32 MB — krap, oude default
  • 67108864 bytes = 64 MB — krap voor moderne CMS
  • 134217728 bytes = 128 MB — gangbaar minimum
  • 268435456 bytes = 256 MB — comfortabel voor de meeste sites
  • 536870912 bytes = 512 MB — voor grote WooCommerce/Drupal-sites
  • 1073741824 bytes = 1 GB — bijzonder hoog, vaak teken dat er iets anders mis is

Wat is PHP memory_limit eigenlijk?

Het is een instelling die zegt: één PHP-script (één pageload) mag maximaal X megabyte geheugen gebruiken. Niet voor de hele site, niet voor alle bezoekers samen — per request. Als jouw homepage 50 bezoekers tegelijk heeft en de limiet is 256 MB per request, dan mag PHP in theorie 50 × 256 MB = 12,8 GB tegelijk benutten. Vandaar dat hosters voorzichtig zijn met de limiet hoog zetten.

De default in PHP zelf is 128M. Hosters kunnen 'm verlagen (typisch 64M op shared hosting van het zuinige soort) of verhogen. CMS-instellingen kunnen 'm verder beperken via een eigen layer.

Stap 1: voor je iets verhoogt — diagnose

Als je alleen de limiet verhoogt en nooit kijkt naar wat er gebeurt, mis je 30% van de gevallen waarin meer geheugen niet helpt. Drie vragen om eerst te beantwoorden:

1. Op welke pagina/actie verschijnt de fout?

Belangrijk verschil:

  • Specifieke pagina/admin-actie (export, image-upload, plugin-installatie) → vaak een terechte piek waar je geheugen voor nodig hebt
  • Willekeurige pagina's, bijna elke pageload → er zit waarschijnlijk een memory leak ergens, en hoger zetten lost het niet duurzaam op
  • Pas verschenen na een update of plugin-installatie → de update is de oorzaak, niet de limiet

2. Hoeveel geheugen gebruikt de site écht?

Een snelle test: maak een testpagina (of voeg toe aan je theme):

// Aan het einde van een pagina-script
echo 'Peak: ' . round(memory_get_peak_usage(true) / 1024 / 1024, 2) . ' MB';

Een normale WordPress-frontend pagina zit op 30-60 MB. Een complexe WooCommerce-checkout op 80-150 MB. Een Drupal-pagina met views op 60-120 MB. Zit jouw site al op 200+ MB voor een gewone pagina, dan is er iets mis dat je niet met "verhoog naar 512 MB" oplost.

3. Wat staat er in het volledige error_log?

Niet alleen de laatste regel kijken. Vaak staat er boven de fatal-error een trail van waarschuwingen die de oorzaak verraden — denk aan een plugin die rare queries doet, een loop die te ver gaat, of een image-functie die op een te groot bestand werkt.

Stap 2: PHP memory_limit verhogen — de methodes

Als je vastgesteld hebt dat een verhoging gerechtvaardigd is, zijn dit de plekken waar je 'm kunt verhogen — in volgorde van wat het eerste probeert te wijzigen:

WordPress: wp-config.php

// Boven de regel "/* That's all, stop editing! */"
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M'); // voor admin/cron-taken

Werkt alleen als je hoster jou toestaat de limiet te verhogen. Op een hoster met memory_limit = 64M hard ingesteld op PHP-niveau, doet deze constante helemaal niets.

Joomla: configuration.php / .htaccess

Joomla zelf heeft geen memory-instelling — die volgt PHP. Verhoog dus via .htaccess of php.ini (zie onder).

Drupal: settings.php

// In sites/default/settings.php
ini_set('memory_limit', '256M');

Plus eventueel in .htaccess als ini_set niet werkt op jouw hoster.

OpenCart: index.php / php.ini

OpenCart heeft geen ingebouwde memory-config. Aanpak: .htaccess, php.ini of via control panel.

Universeel: .htaccess (Apache, vaak shared hosting)

php_value memory_limit 256M

Werkt alleen als de hoster php_value-directives toestaat (vaak met mod_php-stack). Zo niet, krijg je een 500-error en moet je deze regel weer weghalen. Zie ook .htaccess uitgelegd.

Universeel: php.ini of .user.ini

Op moderne hosters (PHP-FPM-stack) is dit de juiste plek. Maak een bestand .user.ini in je webroot (of php.ini in cPanel/Plesk):

memory_limit = 256M

Effect kan 5 minuten duren omdat PHP .user.ini niet bij elke request herleest. Plesk en cPanel hebben vaak een directere route.

Plesk

Domains → kies domein → PHP Settings → bij "memory_limit" een hogere waarde invullen, of "custom value". Direct actief.

cPanel

Software → MultiPHP INI Editor → kies domein → memory_limit aanpassen → Apply. Of via PHP Selector als jouw hosting CloudLinux gebruikt.

DirectAdmin

Domain Setup → klik domein → PHP Selector / Custom php.ini → memory_limit verhogen.

In code, alleen voor één script (uitzondering)

ini_set('memory_limit', '512M');

Plaats helemaal bovenaan een specifiek script (bijvoorbeeld een import-cronjob). Werkt alleen als je hoster ini_set('memory_limit', ...) niet geblokkeerd heeft via disable_functions.

Stap 3: controleren of de wijziging is doorgekomen

Maak in je webroot een bestand info.php:

<?php phpinfo(); ?>

Bezoek https://jouwsite.nl/info.php, zoek op "memory_limit". Je ziet "Local Value" en "Master Value":

  • Master Value = hosting-instelling op PHP-niveau
  • Local Value = wat jouw site daadwerkelijk gebruikt (na .htaccess, .user.ini en ini_set())

Local Value is wat telt. Werkt jouw verhoging niet door, dan blokkeert je hosting hem op een hoger niveau — neem contact op met support.

Belangrijk: verwijder info.php direct na deze check. Die pagina lekt versie-info, paden en config waar bots actief op scannen.

Wanneer is het géén oplossing om gewoon te verhogen?

Dit is de helft waar dit artikel echt over gaat. Vijf situaties waarin verhogen alleen het probleem doorschuift:

1. Memory leak in een plugin of module

Symptomen: site werkte een week prima op 128 MB, sinds een plugin-update niet meer. Verhoog je naar 256 MB, dan crasht 'ie binnen een paar dagen weer. Verhoog je naar 512 MB, dan crasht 'ie binnen een week.

Diagnose: deactiveer plugins één voor één (op staging of via WP-CLI wp plugin deactivate --all), reactiveer een voor een, kijk wanneer de fout terugkomt. De boosdoener is meestal een specifieke plugin met een lekkende loop of caching die niet wordt opgeruimd.

2. Een query die alles uit de database in geheugen laadt

Klassiek voorbeeld in WordPress:

// Catastrofaal op een site met 50.000 producten:
$producten = get_posts([
    'post_type' => 'product',
    'posts_per_page' => -1, // ALLES laden
]);
foreach ($producten as $p) { ... }

Dit laadt 50.000 post-objecten in één keer in geheugen. Geen geheugenlimiet gaat dat aankunnen op den duur. De juiste oplossing is batchen (telkens 100 records ophalen, verwerken, volgende batch). Geen verhoging — een code-fix.

Komt veel voor bij: bulk-export-functies, mailinglist-mail-handlers, oude import-scripts, "fix all images"-tools.

3. Image processing op een te groot bestand

Iemand heeft een 6000×4000 pixel foto direct uit een DSLR-camera ge-upload. WordPress probeert thumbnails te genereren met GD, en bij PHP-image-functies geldt: een volledig geladen image kost ongeveer breedte × hoogte × 4 bytes aan geheugen tijdens bewerking.

6000 × 4000 × 4 = 96 MB voor één foto. Plus andere PHP-overhead → boom, op een 128 MB-limiet.

Oplossing: limiteer upload-formaten in je CMS, optimaliseer afbeeldingen vóór upload, of gebruik image-optimization plugins die fysiek kleinere bestanden afdwingen. Verhogen kan tijdelijk helpen, maar het is wachten op de volgende grote upload.

4. Oneindige recursie of loop

Code roept zichzelf aan zonder break-conditie, of bouwt een datastructure op die zichzelf bevat. Geheugen-gebruik klimt rechtlijnig tot het script crasht. Symptoom: error verschijnt altijd op exact dezelfde regel, met een vast patroon.

De stack-trace in je error_log is hier goud waard — die laat zien hoe de code in cirkels draait. Verhoging maakt het script alleen langer, maar niet werkend.

5. Bot- of scraper-aanval

Een bot bestookt een dure pagina (bijvoorbeeld een gefilterde productlijst, of een complete archive-pagina) met honderden requests per minuut. Memory-pieken zijn dan niet één request, maar tientallen tegelijk. Hoger zetten betekent eerder dat je op CPU-limieten of aantal-PHP-workers crasht.

Diagnose: kijk in access_log naar IP-frequentie en User-Agent. Behandelen via fail2ban, Cloudflare-rules of .htaccess-blocklisting.

Specifiek voor WordPress: typische scenario's

Critical error tijdens admin-acties

Pluginbeheer, theme-update, image-uploads — vaak terechte piek. Verhogen tot 256 MB volstaat meestal.

Memory error op WooCommerce-checkout

Vaak teken van een te zware plugin-stack op productpagina's of een caching-probleem. 256-512 MB als tijdelijke fix, daarna echt opruimen.

Crash bij Elementor / page-builders

Bekend probleem: page builders houden veel in geheugen tijdens edit-sessies. Elementor zelf adviseert 256-768 MB tijdens editing. Op de frontend voor bezoekers vaak veel minder nodig, maar admin-WP_MAX_MEMORY_LIMIT moet hoog.

Crash tijdens cron-taken (wp-cron.php)

Verhoog dan ook in CLI-context (bij externe cron):

/usr/bin/php -d memory_limit=512M /home/site/public_html/wp-cron.php

Specifiek voor WooCommerce, Drupal Commerce, Magento

E-commerce sites met enkele duizenden producten en uitgebreide attributen kunnen makkelijk 256-512 MB gebruiken op admin-pagina's. Frontend hoeft minder. Splits dat als je hoster WP_MAX_MEMORY_LIMIT-achtige settings ondersteunt.

Bij Magento 2 staat de officiële minimum op 2 GB voor admin-acties — dat is geen luxe. Onder 1 GB wordt de admin onbruikbaar.

Wat als je hosting weigert te verhogen?

Sommige NL-hosters blokkeren memory_limit hard op 64 of 128 MB op shared hosting. Je opties:

  1. Bel support en vraag of ze 'm voor jouw account willen verhogen — vaak is dat gratis voor zakelijke accounts
  2. Upgrade van shared naar managed/VPS waar je zelf de PHP-config beheert
  3. Verhuis naar een hoster waar 256 MB de standaard is — bij de meeste NL-hosters is dat gewoon de norm voor zakelijke pakketten. Zie website migreren zonder downtime
  4. Optimaliseer de site om binnen de limiet te blijven — kleinere images, minder plugins, slimmer cachen

Bij budget-shared op 64 MB is "geen optimalisatie helpt genoeg" een reëel scenario. Dan is migratie de echte oplossing.

Snelle checklist bij een memory-fout

  1. Lees de hele foutmelding — pad, regelnummer, allocatie-grootte
  2. Check welk script of welke actie de fout uitlokt — admin? frontend? cron? specifieke plugin?
  3. Meet huidig peak-geheugengebruik op een normale pagina
  4. Check je hosting-default via phpinfo()
  5. Verhoog incrementeel (128 → 256 → 512), niet direct naar 1 GB
  6. Test of de wijziging is doorgekomen via Local Value in phpinfo()
  7. Als hoger zetten niet helpt: het probleem is geen limiet, het is code of data — diepere diagnose nodig
  8. Verwijder testbestanden als info.php
Tip: verhoog liever incrementeel. Als 64 MB niet genoeg is, ga naar 128 of 256 — niet direct naar 1 GB. Een hoge limiet maskeert problemen die je beter zo vroeg mogelijk wilt zien. Een crash op 256 MB is informatie; een crash die nooit komt op 1 GB is een tikkende tijdbom.

Wanneer schakel je hulp in?

  • Memory-fout komt willekeurig op verschillende pagina's en blijft terugkomen na elke verhoging
  • Site al op 512 MB+ en nog steeds crashes — er zit zonder twijfel iets structureels mis
  • Je hoster verhoogt de limiet niet en je weet niet of optimalisatie of migratie de juiste route is
  • WooCommerce-checkout of admin-paneel onbruikbaar door memory-errors tijdens betaalmomenten
  • Memory-issue gecombineerd met "Maximum execution time exceeded" — dan zit er waarschijnlijk een query of integratie vast
  • Custom plugin of import-script die gewoon "te veel data wil verwerken" — dat is een batching-probleem, geen geheugen-probleem

"Allowed memory size exhausted" is in 70% van de gevallen één regel in een config-bestand. In de overige 30% is 't een diagnostisch project — en daar gaat tijd in zitten die je vooral aan jezelf bespaart als je niet dagelijks PHP debugt.