U opent een pagina en in plaats van uw site verschijnt er één regel grijze tekst: Fatal error: Allowed memory size of 134217728 bytes exhausted. Soms staat hij boven een half opgebouwde pagina, soms is het scherm verder leeg. De melding “allowed memory size exhausted” ziet er alarmerend uit, maar hij betekent iets vrij eenvoudigs: PHP kreeg een emmer van een bepaalde grootte mee en die emmer zat vol voordat het werk af was.

Dit artikel loopt de melding regel voor regel na, laat zien hoe u de ruimte vergroot op de plek waar dat hoort, en behandelt daarna de belangrijkere vraag: waarom had uw site opeens zoveel geheugen nodig?

De regel ontcijferen

Een volledige melding ziet er ongeveer zo uit:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/klant/domains/uwsite.nl/public_html/wp-content/plugins/een-plugin/includes/verwerker.php on line 412

Drie stukken zijn interessant.

  • Het eerste getal is uw limiet in bytes. Deel door 1.048.576 en u heeft megabytes: 134217728 is 128 MB. Komt u 268435456 tegen, dan is dat 256 MB.
  • Het tweede getal is wat er nog bij moest. Staat daar een klein bedrag zoals 20480 bytes, dan liep de emmer al bijna over en was dit slechts de laatste druppel. Staat er iets van tientallen megabytes, dan probeerde een script in één keer iets enorms in te laden.
  • Het pad en het regelnummer wijzen naar de code die als laatste iets vroeg. Let op: dat is niet automatisch de schuldige. Wie als laatste aanschuift bij een lege pan, heeft de pan niet leeggegeten.

Ziet u helemaal geen tekst maar een wit vlak, dan staat de melding waarschijnlijk alleen in het logbestand. Hoe u daarin kijkt, staat in de uitleg over het foutenlog van WordPress.

Eerst de snelle verruiming

Als de site plat ligt, wilt u hem eerst overeind hebben. Er zijn drie plekken waar de limiet kan worden gezet, en ze overrulen elkaar in deze volgorde.

  1. De serverinstelling. Bij veel Nederlandse hostingpakketten staat in het klantenpaneel een instelling voor PHP-geheugen. Dit is de nette plek, want alles daaronder kan de serverwaarde niet overschrijden.
  2. wp-config.php. Voeg boven de regel die zegt dat u niet verder moet bewerken deze regel toe: define( ‘WP_MEMORY_LIMIT’, ‘256M’ ); Wilt u dat ook in het beheerscherm ruimer wordt, dan zet u er define( ‘WP_MAX_MEMORY_LIMIT’, ‘512M’ ); onder.
  3. Een php.ini of .user.ini in de hoofdmap met de regel memory_limit = 256M. Dit werkt alleen als uw host het toestaat; bij sommige pakketten wordt het genegeerd.

Controleer daarna wat er werkelijk actief is. Ga in het beheerscherm naar Gereedschap en dan Sitegezondheid, tabblad Info, onderdeel Server. Daar staat de geheugenlimiet die op dat moment geldt. Ziet u nog steeds 128 MB terwijl u 256 heeft ingevuld, dan zit er een serverplafond boven en moet uw hostingpartij bijspringen.

Wat een verstandige waarde is: 256 MB is voor een normale zakelijke site ruim voldoende. Een webshop met veel producten en koppelingen komt regelmatig op 512 MB uit. Gaat u daar overheen, dan lost u niets meer op; dan verbergt u een probleem.

Waarom hoger zetten geen oplossing is

Geheugen ophogen is een pleister. Een WordPress-site die netjes in elkaar zit, gebruikt voor een gewone pagina zelden meer dan 60 tot 80 MB. Zit u tegen 256 MB aan, dan gebeurt er iets bijzonders, en meestal is dat één van deze vier dingen.

Een importbewerking. Producten, klanten of berichten in bulk inlezen vraagt veel meer dan gewoon browsen. Hier is tijdelijk ophogen prima, mits u het daarna terugzet.

Een plugin die alles tegelijk ophaalt. Klassiek voorbeeld: een overzicht dat álle bestellingen of álle mediabestanden in één keer in het geheugen zet in plaats van in blokken van honderd.

Te veel actieve plugins. Elke plugin laadt bij elke paginaweergave zijn eigen code. Veertig plugins die ieder een paar megabyte pakken, vullen de emmer voordat uw eigen pagina begint.

Een lus die zichzelf blijft voeden. Twee plugins die elkaar aanroepen, of een zoekfunctie die per resultaat opnieuw de database bevraagt. Dit is de variant waarbij het tweede getal in de melding heel klein is.

De oorzaak opsporen zonder gokwerk

Werk dit rustig af, bij voorkeur op een testkopie van uw site.

  1. Noteer wanneer het gebeurt. Alleen op één pagina, alleen in het beheerscherm, alleen tijdens een export? Dat verkleint het zoekgebied enorm.
  2. Zet WP_DEBUG_LOG aan en verzamel een paar meldingen. Komt steeds hetzelfde bestandspad terug, dan heeft u een sterke aanwijzing.
  3. Installeer tijdelijk Query Monitor. Die toont onderaan elke pagina het piekgeheugen en het aantal databasevragen. Springt één pagina van 70 naar 240 MB, dan weet u waar u moet kijken.
  4. Schakel plugins in groepen uit. Eerst de helft, dan de helft van de helft. Zo bent u met vijf of zes stappen bij de veroorzaker, ook als u er dertig heeft.
  5. Controleer op stapeling. Twee cacheplugins, twee beeldoptimalisatietools of twee back-uppakketten naast elkaar zijn een klassieke geheugenvreter.

Een voorbeeld: bij een groothandel uit Twente sloeg de melding alleen toe op het bestellingenoverzicht. De oorzaak was een koppeling met het voorraadsysteem die per bestelling de complete productinformatie ophaalde, ook op een lijstpagina waar alleen het ordernummer werd getoond. Na een aanpassing van de leverancier zakte het piekgeheugen van 250 naar 90 MB en kon de limiet gewoon op 256 blijven staan.

Wanneer u er iemand bij haalt

U kunt de limiet zelf prima verruimen en plugins zelf uitzetten. Blijft de melding terugkomen ondanks 512 MB, of wijst hij naar een bestand in de kern van WordPress zelf, dan is er iets structureel mis en wordt verder ophogen riskant: het geheugen dat u pakt, is geheugen dat andere sites op dezelfde server niet krijgen. Dan is het opsporen en herstellen van dit soort PHP-fouten verstandiger dan zelf doorgraven. Bij WebMaintor beginnen we in zulke gevallen altijd met meten voordat er ook maar iets wordt aangepast.

Verwar deze fout trouwens niet met een tijdslimiet die wordt overschreden; dat is een andere melding met een andere oorzaak. Meer achtergrond over de speelruimte die PHP krijgt, leest u in het artikel over de geheugenlimiet van WordPress.

Uw eerstvolgende actie: kijk in Sitegezondheid welke limiet er nu echt geldt en noteer dat getal. Zonder dat vertrekpunt raadt u bij elke aanpassing of er iets is veranderd.