Allowed memory size exhausted i WordPress

Kort svar: Fejlen betyder, at én PHP-request forsøgte at bruge mere hukommelse end dens effektive loft. Gem den fulde fatal-linje: tilladte bytes, ekstra bytes, fil, linje og tidspunkt. Se om requesten er frontend, admin, cron eller CLI, og find den handling, der vokser. Et moderat højere loft kan bruges som kontrolleret test, men løser ikke en memory leak, uendelig loop eller for stor batch.

Fagligt gennemgået: 28. august 2026

Kontrolgrundlag: WordPress 7.1, PHP 8.4.23 og Chrome 151 på isoleret staging. Et afgrænset memory-pressure-scenarie er målt med Hostious Article Lab 1.4.1 uden vedvarende ændringer; reelle grænser skal aflæses i den runtime, der fejler.

En typisk loglinje begynder med Allowed memory size of ... bytes exhausted. Den fortæller både loftet og den allokering, der fejlede. Filen på linjen er stedet, hvor PHP ikke kunne få mere hukommelse – ikke altid den komponent, der forbrugte det hele.

Før du ændrer noget: Tag backup af wp-config.php og den relevante PHP-konfiguration. Notér nuværende grænser. Sæt aldrig memory_limit = -1 på et live-site for at få testen igennem.

1. Gem den præcise fejl og request

Notér:

• hele fatal-linjen;
• URL/kommando og tidspunkt;
• om det er frontend, wp-admin, REST, cron eller WP-CLI;
• hvilken handling der kørte: import, backup, billedbehandling, builder, rapport eller opdatering;
• om fejlen gentager sig ved samme inputstørrelse.

Læs tallene uden at gætte

I en fatal-linje som Allowed memory size of A bytes exhausted (tried to allocate B bytes) er A requestens effektive loft, mens B kun er den næste allokering, der mislykkedes. B fortæller ikke requestens samlede forbrug, og filen/linjen er ikke automatisk synderen. Omregn A til MiB ved at dividere med 1.048.576, og sammenlign med den målte runtimeværdi.

Gem også den nærmeste request-identifikator eller jobreference. To memory-fejl på samme sekund kan stamme fra forskellige workers: en frontendrequest, billedgenerering og en køopgave kræver hver sin reproduktion. Hvis logformatet ikke har request-ID, kan URL, cron-hook, CLI-kommando eller inputfil bruges som afgrænsning uden at gemme persondata.

2. Find det effektive loft i den rigtige runtime

WordPress har WP_MEMORY_LIMIT til almindelige requests og WP_MAX_MEMORY_LIMIT til visse adminopgaver. PHP har sit eget memory_limit, og hosting/container kan have et yderligere loft. Den laveste ufravigelige begrænsning vinder i praksis.

Se Værktøjer → Webstedssundhed → Info → Server/WordPress constants eller hostingens PHP-info. Kontrollér også den runtime, der fejler: web-FPM, cron og CLI kan læse forskellige konfigurationsfiler.

Skriv værdierne ned før ændring. En konstant i wp-config.php er ikke bevis for, at PHP accepterede værdien.

3. Lav en kontrolleret, midlertidig hævning

Kun hvis den nuværende grænse er lav i forhold til en legitim, afgrænset opgave, kan du teste et moderat højere loft:

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

Tallene er eksempler, ikke anbefalede standarder. Vælg ud fra nuværende loft, hostingens kapacitet, requesttype og den målte opgave. Placér konstanterne før WordPress indlæser wp-settings.php, og undgå dubletter.

Gentag præcis samme handling én gang. Hvis den nu lykkes, har du vist, at loftet var en del af problemet – ikke nødvendigvis at årsagen er sund. Mål om forbruget ligger stabilt under det nye loft.

4. Find hvad der bruger hukommelsen

Arbejd på staging og gør input mindre:

1. Halvér import-/batchstørrelsen.
2. Deaktivér kun den mistænkte funktion eller plugin i Troubleshooting Mode.
3. Gentag med samme datasæt.
4. Sammenlign peak memory og tidspunkt.
5. Fortsæt, til én komponent eller datastørrelse forklarer springet.

Typiske dokumenterbare mønstre er meget store billedfiler, hele datasæt indlæst i arrays, rekursion, gentagne queries, builderdata eller plugins, der behandler alle poster i én request. Løsningen er ofte chunking/paginering, lavere billeddimensioner eller rettet kode – ikke kun mere RAM.

Filen i fatal-linjen kan være wpdb, billedbibliotek eller core, selv om en tredjepart kaldte den i en løkke. Brug call stack/profilering til at finde den kaldende funktion.

5. Skel mellem WordPress og serverkapacitet

Hvis flere PHP-workers hver kan bruge et højt loft, kan et stort memory_limit gøre hele serveren ustabil. Sammenhold derfor:

• memory pr. request;
• antal samtidige workers;
• containerens/RAM-pakkens faktiske loft;
• swap/OOM-events;
• andre jobs på samme tidspunkt.

Et enkelt requestloft på 512 MB er ikke gratis, hvis ti workers kan ramme det samtidig. Få hosting til at vurdere poolen, hvis en legitim arbejdsgang kræver en stor permanent grænse.

6. Kontroller at fejlen ikke blot flytter sig

Efter en hævning skal du se efter:

• ny memory-fejl ved et højere byteantal;
• timeout i stedet for memory error;
• 502/503 eller worker-kill;
• meget længere response;
• en batch, der stadig ikke afsluttes.

Hvis fejlen flytter sig, ruller du grænsen tilbage og retter jobdesignet eller komponenten. Mere hukommelse skjuler ellers problemet til næste større datasæt.

Mål vækst – ikke kun bestået eller fejlet

En god stagingtest bruger mindst tre kendte inputstørrelser. For en import kan det være 50, 100 og 200 rækker; for billeder tre kendte pixelstørrelser; for en rapport et stigende antal poster. Registrér peak memory og køretid i samme runtime.

Hvis memory vokser omtrent proportionalt med input, er batching eller streaming normalt den robuste løsning. Hvis forbruget accelererer, eller samme input bruger mere ved hver gentagelse, skal du lede efter akkumulerede objekter, caches, rekursion eller en loop. Hvis et lille input allerede ligger tæt på loftet, er plugin-/temabaseline, autoloadede data og fast request-overhead mere relevant.

Mål med samme værktøj i alle runder. Site Health viser konfiguration, ikke nødvendigvis requestens peak. Et profileringsplugin kan selv påvirke memory, så notér profilerens version og lav også en kontrolrunde uden profiler, hvis forskellen er lille.

Beslutning efter den midlertidige hævning

• Samme job lykkes med stabil peak og god margin: vurder om loftet var urimeligt lavt for den legitime opgave, og dokumentér kapaciteten på workerniveau.
• Fejlen kommer igen ved højere A-værdi: rul tilbage og ret væksten; loftet har kun flyttet grænsen.
• Memory-fejlen bliver til timeout/502: requesten er stadig for tung eller langsom; højere memory er ikke en løsning.
• Kun webrequest fejler, mens CLI lykkes: sammenlign ini-fil, timeout, bruger og miljø; resultaterne er ikke direkte udskiftelige.
• Kun én plugin-/temakombination fejler: brug den reproducerbare konflikttest og lever call stack til ejeren.

Kontrolleret før/efter-test

Tag udgangspunkt i det samme datasæt og samme requesttype. Før ændringen registreres effektivt loft, peak, køretid og fatal-linje. Efter en kode-/batchrettelse køres først den tidligere fejlende størrelse og derefter én realistisk større kontrol. Slutresultatet skal ikke blot “virke”; peak skal have en forklarlig og sikker margin, og køretiden må ikke være flyttet over platformens timeout.

Når løsningen er batching, skal du også verificere fuldstændighed: antal behandlede poster, fejlede poster, dubletter og et checksum-/tællepunkt før og efter. En batch, der holder memory nede ved at springe data over, har ikke bestået.

Test til sidst parallelitet i et afgrænset miljø. To samtidige legitime jobs må ikke presse workerpoolen over containerens loft. Start ikke en ukontrolleret belastningstest; brug den normale maksimale samtidighed, som arbejdsgangen faktisk tillader, og følg RAM/OOM-events.

Verifikation

• Den oprindelige handling gennemføres med samme input.
• Peak memory er målt og har en rimelig margin til loftet.
• Ingen ny fatal/timeout/worker-kill opstår.
• Frontend, admin og relevante baggrundsjobs virker.
• Efter genstart eller ny PHP-worker er den forventede konfiguration stadig aktiv.

Rollback

Gendan wp-config.php/PHP-konfiguration fra backup, fjern dublerede konstanter, og genstart kun den relevante PHP-pool, hvis platformen kræver det. Hvis du reducerede batch eller deaktiverede en komponent, genskab den oprindelige tilstand på staging og behold den dokumenterede produktionsløsning.

Hvornår skal hosting eller udvikler hjælpe?

Skal loftet hæves vedvarende, for at helt almindelig drift kan køre, er hostingpakken for lille til sitet. Sammenlign planerne og se, hvad der følger med på hvert niveau.

Hosting skal hjælpe, når PHP ikke accepterer grænsen, FPM-adminværdier styrer den, eller RAM/OOM/workerpool er problemet. Udvikleren skal have fatal-linje, reproducerbar request, inputstørrelse og memoryprofil. Hostious WordPress-support kan hjælpe med begge lag.

Sådan dokumenterer du memory-fejlen

Saml tallene fra den samme runtime og den samme reproducerbare handling:

1. Anonymiseret fatal-linje med tilladte bytes, fil/linje og timestamp.
2. Site Health/PHP-info med effektiv memorygrænse.
3. Kontrolleret før/efter for samme batchstørrelse.
4. Graf med peak memory og workerantal i testvinduet.

Gem fatal-linjen, den effektive konfiguration i samme runtime og peak-forbruget fra eftertesten. Fjern absolutte kundestier.

Ofte stillede spørgsmål om memory-fejlen

Skal jeg bare hæve memory limit, når fejlen opstår?

Ikke som første skridt. Fejlen fortæller, HVILKEN fil der brugte hukommelsen op – find den handling først. Et højere loft uden diagnose skjuler ofte et plugin, der lækker hukommelse.

Hvor meget memory bør WordPress have?

256 MB er en fornuftig ramme for de fleste sites med WooCommerce; 512 MB til tunge imports. Definer WP_MEMORY_LIMIT i wp-config.php – og husk at serverens PHP-limit skal være mindst lige så høj.

Hvorfor kommer fejlen kun ved imports eller backups?

Fordi netop de jobs behandler mange data i én request. Kør store opgaver i mindre bidder, via WP-CLI eller på tidspunkter med lav trafik – så undgår du at presse frontend samtidig.

Læs også

• Hub: WordPress fejl og fejlfinding
• Kritisk fejl i WordPress
• Hvid skærm i WordPress
• 502 Bad Gateway
• Plugin- eller temakonflikt