OutOfMemoryError på din Minecraft server: sådan finder du årsagen

Først: hvilken slags hukommelsesfejl er det?

Der er fire helt forskellige ting, som alle bliver kaldt "serveren løb tør for hukommelse" - og de har modsatrettede løsninger. At bestemme hvilken du har, er hele arbejdet.

Hvad du ser	Hvad det er	Hvilken vej skal du?
Java-fejl med OutOfMemoryError i logs/latest.log	Heapen er fuld	Giv mere hukommelse, eller find lækagen
Loggen stopper midt i en linje, panelet siger Killed eller exit code 137	Systemet dræbte serveren	Giv mindre til Java
Serveren nåede aldrig Starting minecraft server version	Den kunne ikke starte op med den hukommelse	Sænk -Xmx
Watchdog-besked om et langt tick	Ikke en hukommelsesfejl	Det er et ydelsesproblem

Den vigtigste fælde i hele guiden: ved exit code 137 er den instinktive reaktion - at give Java mere RAM - præcis det forkerte, og det får fejlen til at komme hurtigere.

---

java.lang.OutOfMemoryError: Java heap space

Fylder typisk sådan i loggen:

Exception in thread "Server thread" java.lang.OutOfMemoryError: Java heap space

Hvad det betyder: den hukommelse, du gav Java med -Xmx, er reelt fyldt med data, der stadig er i brug. Enten er tallet for lavt til det, serveren laver, eller også holder noget fast i data, der burde være ryddet væk.

Serveren dør sjældent rent af den her. Den kaster fejlen, TPS falder mod nul, og processen humper videre. Rigtig mange "min server er frosset, men står stadig online"-sager er en server efter en heap space-fejl.

---

java.lang.OutOfMemoryError: GC overhead limit exceeded

Hvad det betyder: Java brugte mere end 98% af tiden på at rydde op i hukommelsen og fik under 2% fri hver gang - fem gange i træk. Det er reelt den samme situation som Java heap space, bare opdaget lidt tidligere.

For spillerne har det i minutterne op til føltes som voldsom lag.

Samme diagnose og samme løsning som ovenfor.

Der findes en Java-indstilling, der slår kontrollen fra. Brug den ikke. Den fjerner ikke problemet - den bytter en hurtig fejl ud med en server, der kører videre på nul TPS i det uendelige.

---

java.lang.OutOfMemoryError: Metaspace

Hvad det betyder: det her handler ikke om -Xmx. Metaspace er der, hvor Java gemmer selve koden fra dine plugins og mods, og den ligger uden for heapen.

De to årsager:

1. Du genindlæser plugins. Hver gang du kører /reload eller bruger et plugin-manager-plugin, indlæses al koden på ny. Bliver den gamle udgave ikke ryddet væk - og det bliver den tit ikke - vokser Metaspace for hver eneste genindlæsning, indtil serveren dør. Det er den klart hyppigste årsag.
2. Et meget stort modpack med tusindvis af klasser, kombineret med et loft sat af kontrolpanelet.

Modsat af hvad man tror: her kan det hjælpe at sænke -Xmx. Metaspace ligger uden for heapen, så giver du heapen mindre plads, bliver der mere tilbage til Metaspace.

Løsningen er adfærd, ikke indstillinger: brug /reload til konfigurationsændringer, og genstart når du skifter et plugin ud.

---

Could not reserve enough space for object heap

Error occurred during initialization of VM
Could not reserve enough space for object heap
Error: Could not create the Java Virtual Machine.

Hvad det betyder: Java kunne slet ikke få fat i den hukommelse, du bad om. Det her sker inden serveren starter - der er ingen OutOfMemoryError, og der bliver ikke skrevet noget i logs/latest.log overhovedet.

Kendetegnet: serveren når aldrig frem til linjen Starting minecraft server version....

Årsager:

1. -Xmx er større end den pakke, du har. Den klart hyppigste.
2. Der står to forskellige -Xmx i opstartslinjen
3. Enheden er skrevet forkert - det hedder -Xmx4G, ikke -Xmx4GB

---

Killed og exit code 137

I panelet ser det typisk sådan ud:

Killed

eller

Exit code: 137
Out of memory: true

Hvad det betyder: det er ikke Java, der gav op - det er systemet, der slog serveren ihjel, fordi hele processen fyldte mere end din pakke tillader. 137 betyder "dræbt udefra".

Sådan kender du forskel:

	Java-fejl (OutOfMemoryError)	Systemet dræbte den (137)
Hvem besluttede det	Java, fordi heapen var fuld	Systemet, fordi hele processen var for stor
I loggen	Java-fejl med stack trace	Ingenting - loggen stopper midt i en linje
Nåede den at gemme?	Som regel delvist	Nej - risiko for beskadigede chunks
Løsningen	Giv mere, eller find lækagen	Giv Java mindre

Serveren nåede ikke at gemme. Tjek din verden, og overvej at gendanne fra backup, hvis noget ser forkert ud.

Løsningen: sænk -Xmx med 1-2 GB, eller skift til en større pakke. Ikke det modsatte.

---

Watchdog-beskeden er ikke en hukommelsesfejl

På Paper ser den sådan ud:

The server has stopped responding! This is (probably) not a Paper bug.

På vanilla:

A single server tick took 60.00 seconds (should be max 0.05)
Considering it to be crashed, server will forcibly shutdown.

Watchdoggen måler tid, ikke hukommelse. Den udløses, når ét tick tager for lang tid - en langsom databaseforespørgsel, en stor WorldEdit-operation, chunk-generering.

Men der er en sammenhæng, du skal kende: en næsten fuld heap giver konstante oprydningspauser, som stopper tick, som udløser watchdoggen. Se derfor altid opad i loggen. Står der en OutOfMemoryError over watchdog-beskeden, er hukommelsen den egentlige historie. Står der et plugin i thread dumpet, er det et ægte ydelsesproblem.

---

Hvor meget må du give Java?

To regler, og den anden overtrædes hele tiden.

1. Sæt -Xms og -Xmx til det samme tal. En heap, der vokser undervejs, giver pauser hver gang den udvides. Serveren når alligevel op på maks inden for få minutter, så der er intet at spare.

2. Giv aldrig Java hele din pakke. -Xmx styrer kun heapen. Uden for den bruger Java også hukommelse til plugin-kode, tråde, netværksbuffere og selve oprydningen - og alt det skal også være inden for din pakkes grænse.

En brugbar tommelfingerregel er at lade omkring 15% eller mindst 1 GB stå frit:

Din pakke	Sæt -Xmx til
2 GB	1500M
4 GB	3G
6 GB	5G
8 GB	6500M
12 GB	10G
16 GB	13G

Bivirkning, du skal kende: med -Xms og -Xmx ens fylder serveren hele beløbet med det samme. Panelets hukommelsesgraf står derfor på næsten 100% hele tiden. Det er normalt og ikke en lækage.

Aikar's flags er den anbefalede opsætning af Javas hukommelsesoprydning til Minecraft. Den aktuelle streng ligger på docs.papermc.io/paper/aikars-flags.

Aikar's flags løser ikke en OOM. De ændrer hvordan der ryddes op, ikke hvor meget hukommelse der findes. Har du for lidt RAM, hjælper de ingenting.

---

Er det for lidt RAM, eller er det en lækage?

Kig ikke på toppen af kurven - den ligger altid tæt på -Xmx. Kig på, hvor langt ned den falder efter en oprydning:

	For lidt RAM	En lækage
Bunden af kurven	Flad - falder ned til samme niveau hver gang	Stiger - lidt højere for hver gang
Hvornår sker det	Når der er mange spillere, eller under pregen	Efter mange timers oppetid, ofte om natten uden spillere
Hjælper en genstart?	Kun til belastningen kommer igen	Ja - i lige mange timer hver gang

"En genstart fikser det i cirka lige mange timer hver gang" er det stærkeste tegn på en lækage.

Mål det med spark, som er indbygget i Paper fra 1.21:

/spark health
/spark gc
/spark heapsummary --run-gc-before

• /spark gc viser, hvor ofte og hvor længe der ryddes op. Konstante oprydninger i træk betyder, at heapen er mættet.
• /spark heapsummary --run-gc-before viser, hvad der rent faktisk fylder.

--run-gc-before er ikke valgfri. Uden den kommer skrald, der bare ikke er ryddet væk endnu, med i opgørelsen - og så ligner alting en lækage. Tag to målinger med en times mellemrum og sammenlign: det, der er vokset, er din synder.

---

De typiske årsager på en Minecraft-server

1. For mange indlæste chunks. Den hyppigste enkeltårsag. En kørende pregenerering indlæser chunks hurtigere, end de kan ryddes væk - og det er derfor, servere ofte dør om natten uden en eneste spiller online.
2. Ophobede entities og genstande. Mobfarme og bunker af droppede items. En enkelt AFK-farm kan holde titusindvis af entities i live.
3. For høj view-distance. Hukommelsen stiger omtrent med kvadratet: fra 10 til 16 er ikke 60% mere, men cirka 2,5 gange så meget.
4. Et plugin med en lækage. Typisk kort- og render-plugins under en fuld render, eller plugins der gemmer data per spiller uden nogensinde at rydde op.
5. Store modpacks. 200+ mods kræver reelt 6-10 GB og kan ikke skrues ned til 2.
6. For mange verdener indlæst. Hver verden holder sine spawn-chunks i hukommelsen permanent, uanset om nogen er derinde. At aflaste ubrugte verdener er ofte den letteste gevinst overhovedet.

---

Java-version

En forkert Java-version giver ikke en hukommelsesfejl - den giver UnsupportedClassVersionError. Men tjek den alligevel, mens du er i gang:

Minecraft-version	Java
1.17 - 1.19	Java 17
1.20 - 1.21.11	Java 21
26.1 og nyere	Java 25

Bemærk at Minecraft skiftede til et årstalsbaseret versionsnummer i 2026. 26.1 er nyere end 1.21, selv om tallet ser mindre ud.

---

Sådan gør du, i rækkefølge

1. Bestem hvilken slags fejl det er ud fra tabellen øverst. Alt andet afhænger af det.
2. Tjek at fordelingen er fornuftig. Er -Xms lig -Xmx, og er der mindst 1 GB luft under pakkens loft? Cirka halvdelen af alle sager slutter her.
3. Mål i stedet for at gætte. /spark health og /spark gc.
4. Afgør lækage eller kapacitet med bundlinje-testen ovenfor.
5. Er det kapacitet: skær ned først. Sænk view-distance og simulation-distance, stop pregenerering, aflast ubrugte verdener, stram mob-grænserne. Køb først mere RAM bagefter.
6. Er det en lækage: find pluginnet med to heapsummary-målinger, og fjern eller opdatér det. Hold op med at bruge /reload.
7. Slå diagnostik til til næste gang med -XX:+HeapDumpOnOutOfMemoryError, så du har noget at kigge på.

---

Det skal du ikke gøre

• Giv ikke Java hele din pakke. Det er den direkte vej til exit code 137.
• Hæv ikke -Xmx ved exit code 137. Det gør fejlen hyppigere, ikke sjældnere.
• Slå ikke watchdoggen fra med max-tick-time=-1. Du skjuler symptomet og får en server, der hænger i stedet for at genstarte.
• Tro ikke at Aikar's flags giver mere hukommelse. De giver jævnere tick, ikke mere plads.
• Brug ikke /reload når du skifter plugins. Det er den direkte årsag til Metaspace-fejl.

Kan du ikke tyde din spark-rapport eller din log? Send os linket eller logs/latest.log i en ticket - vi kigger med.