Minecraft-server lagt: oorzaken vinden en verhelpen

"De server lagt" is de meest voorkomende melding in het ticketsysteem van elke gameserverbeheerder en tegelijk de minst bruikbare. Achter die ene zin gaan minstens drie totaal verschillende technische problemen schuil die niets met elkaar te maken hebben en die u ook met totaal verschillende middelen verhelpt. Wie hier gokt in plaats van meet, draait wekenlang aan view-distance en Java-flags, terwijl de echte oorzaak een kapotte hopperketen in de kelder van een speler is.

Dit artikel loopt de route af in de volgorde waarin die werkt: eerst het onderscheid, dan de meting, dan de oorzaak, dan de maatregel. En aan het eind de vraag die de meeste handleidingen overslaan, namelijk waaraan u eigenlijk merkt dat het probleem echt verholpen is.

Twee foutbeelden die identiek aanvoelen

Er bestaan twee fundamenteel verschillende soorten lag, plus een derde geval dat helemaal niets met de server te maken heeft.

Serverlag betekent: de server haalt zijn 20 rekenstappen per seconde niet meer. De wereld zelf loopt trager. Mobs staan stil of schokken, ovens doen er langer over, afgebroken blokken verschijnen weer en wapenrekken zweven met vertraging.

Netwerklag betekent: de server rekent foutloos, maar de pakketten tussen speler en server doen er te lang over of raken onderweg kwijt. De speler wordt tijdens het lopen teruggetrokken (rubberbanding), klappen missen, de chat komt met vertraging binnen, maar de mobs in de omgeving bewegen volkomen vloeiend.

Clientlag is het derde geval: te weinig beelden per seconde op de computer van de speler, meestal door shaders, een hoge kijkafstand in de client of te weinig toegewezen werkgeheugen. Dat is op de server onzichtbaar en daar dus ook niet te verhelpen.

De ene regel die bijna altijd klopt: treft het iedereen tegelijk, dan is het de server. Treft het losse spelers, dan is het de verbinding. Eén uitzondering doorbreekt die regel: een volledig overbelaste server bevestigt ook netwerkpakketten te laat en veroorzaakt daardoor extra hoge pings. Meet daarom altijd allebei.

De eerste test duurt 60 seconden

Maak via SSH verbinding met de server en open de serverconsole. Draait de service nog niet netjes op de achtergrond, dan helpt het artikel Minecraft-server automatisch starten u verder.

Op Paper, Purpur en Folia vanaf 1.21 zit de profiler Spark al in de server, u hoeft dus niets te installeren. In het spel of in de console:

spark tps
spark health --memory --network

De uitvoer van spark tps toont vier tijdvensters (5 seconden, 1, 5 en 15 minuten) en daarnaast de tickduur als minimum, mediaan, 95e percentiel en maximum.

Op kaal vanilla zonder plug-ins bestaat /tick query. Dat commando geeft de streefwaarde en de gemiddelde ticktijd. Daarnaast toont F3 samen met 2 voor operators een tickgrafiek.

Vaak verraadt de console het probleem al uit zichzelf. Op precies deze regels zoeken lezers meestal:

[Server thread/WARN]: Can't keep up! Is the server overloaded? Running 2123ms or 42 ticks behind
[Server thread/WARN]: Can't keep up! Did the system time change, or is the server overloaded? Running 2340ms behind

Die melding betekent simpelweg dat de server over één rekenstap veel langer deed dan de toegestane 50 milliseconden en dus ticks moet overslaan. Eén losse melding na een herstart of tijdens wereldgeneratie is normaal. Om de paar minuten een melding is een echt probleem.

Controleer parallel daaraan de systeemkant. mpstat hoort op geen enkel getest systeem bij de standaardinstallatie, het komt uit het pakket sysstat en moet u eenmalig apart installeren:

apt-get install -y sysstat procps
uptime
free -h
mpstat 1 3

Op AlmaLinux, Rocky Linux en Oracle Linux luidt de eerste regel dnf -y install sysstat procps-ng iproute. Daar heet het pakket met free, uptime, top en vmstat niet procps, maar procps-ng.

In de uitvoer van mpstat is vooral de kolom %steal interessant. Waarden die blijvend boven 5 procent liggen, betekenen dat de virtuele machine wacht op CPU-tijd die een andere gast bezet houdt. Dan is het geen Minecraft-probleem, maar een capaciteitsprobleem van de onderliggende hardware.

Eén kanttekening bij deze drie commando's: op een eigen server of VPS tonen ze precies wat u wilt weten. Draait uw server daarentegen in een container, bijvoorbeeld in een gamepanel als Pterodactyl, dan melden free, uptime, vmstat en mpstat de waarden van het hostsysteem en niet die van uw eigen instantie. U ziet dan de belasting en het geheugen van anderen. Vertrouw in dat geval op de weergave van het panel en op spark health.

TPS en MSPT goed lezen

Een Minecraft-server rekent 20 ticks per seconde, elke tick heeft dus een budget van 50 milliseconden. MSPT (milliseconden per tick) is de meest veelzeggende waarde, want die toont problemen nog voordat de TPS beginnen te dalen. Een server met 20,0 TPS en 46 ms MSPT draait op het absolute maximum en klapt om zodra de volgende speler een nieuw gebied betreedt.

• MSPT onder 30 ms: gezond, er is reserve.
• MSPT 30 tot 45 ms: krap, maar speelbaar. Nu ingrijpen.
• MSPT boven 50 ms: de TPS dalen onvermijdelijk, spelers merken het.

Belangrijker dan het gemiddelde is de verdeling. Een mediaan van 18 ms bij een maximum van 900 ms betekent spikes: losse dure gebeurtenissen zoals het automatisch opslaan, chunkgeneratie of een plug-in die elke minuut een taak start. Een mediaan van 60 ms wijst daarentegen op permanente belasting, dus op te veel inhoud die getickt moet worden voor de aanwezige rekenkracht. De maatregelen daartegen verschillen volledig.

Een punt dat hardwareadviseurs graag overslaan: de hoofdtick van Minecraft draait in één enkele thread. Het laden van chunks en het netwerk zijn naar andere threads verplaatst, de eigenlijke wereldsimulatie niet. Een server met 32 kernen en zwakke prestaties per kern is voor Minecraft trager dan een server met 8 snelle kernen. Meer kernen helpen pas wanneer er meerdere serverinstanties op draaien.

Spark: van vermoeden naar bewijs

Timings, jarenlang het standaardgereedschap, staat bij Paper sinds de 1.21-reeks in een lege modus en levert geen bruikbare gegevens meer. Wie vandaag nog Timings-links deelt, meet niets. De opvolger heet Spark en zit ingebouwd in Paper. Voor Fabric, Forge en NeoForge bestaat Spark als mod, voor Velocity en BungeeCord als aparte variant.

De doorslaggevende werkwijze: profileer terwijl het probleem zich voordoet. Een profiel van een lege server om drie uur 's nachts is waardeloos.

spark profiler start --timeout 300
spark profiler stop

Bij spikes die maar af en toe optreden, filtert u gericht de slechte ticks eruit:

spark profiler start --only-ticks-over 60 --timeout 600

Daarmee worden alleen ticks vastgelegd die langer dan 60 milliseconden duurden. Precies die ticks voelen spelers. De rest wordt genegeerd en vertroebelt het beeld niet.

Bij het lezen van de flame graph maken beginners bijna altijd dezelfde fout: ze kijken naar de diepste vertakking. Juist is de blik op de breedte van de balken direct onder de servertick. Een balk van 3 procent is irrelevant, ook al gaat die honderd niveaus diep. Vuistregel: één plug-in met meer dan 15 procent aandeel in de ticktijd is een kandidaat. Zeer brede balken rond blokentiteiten wijzen op redstone en hoppers, brede balken rond het laden van chunks op wereldgeneratie.

Een opmerking over vertrouwelijkheid: het geüploade rapport is via zijn link openbaar op te vragen en bevat systeeminformatie, paden, startparameters en de volledige lijst met plug-ins. Geef die link alleen aan mensen aan wie u deze gegevens zou toevertrouwen. Met --save-to-file blijft het profiel lokaal.

De gebruikelijke veroorzakers

Redstone en farms

Hoppers zijn veruit de duurste blokken in het spel, omdat elke hopper bij elke tick controleert of er iets bovenop ligt. Een sorteerinstallatie met 400 hoppers kost meer rekentijd dan honderd mobs. Daar komen observerklokken bij, die ook blijven lopen als er niemand in de buurt is, zolang de chunk maar wordt gesimuleerd. Besteedt Spark opvallend veel tijd aan blokentiteiten, zoek dan precies naar zulke installaties.

Entiteiten

Op Paper somt /paper entity list de entiteiten per wereld en per type op, inclusief chunkcoördinaten. Dat is de snelste route naar het probleemgebied. Typische vondsten: een paar duizend itemstapels in een mobfarm, een fokstal met 300 koeien, een vergeten gebied vol afgeschoten pijlen.

Zinvolle maatregelen in spigot.yml: verlaag de entity-activation-range voor dieren en monsters (bijvoorbeeld dieren van 32 naar 16, monsters van 32 naar 24) en verhoog de merge-radius voor items en ervaringsbollen licht, zodat er minder losse objecten bestaan. In paper-world-defaults.yml begrenst entity-per-chunk-save-limit hoeveel objecten van één type er per chunk worden opgeslagen.

Chunks laden

Een speler met een elytra of op een snel paard dwingt de server voortdurend nieuw terrein te genereren. Wereldgeneratie is veruit de duurste losse bewerking. Hetzelfde gebeurt zodra iemand voor het eerst de Nether betreedt of nadat u de worldborder hebt vergroot. De oplossing is geen configuratiewaarde, maar voorgeneratie, en die is belangrijk genoeg voor een eigen hoofdstuk verderop.

Plug-ins

Wijst Spark een plug-in aan, dan is de zaak duidelijk. Zo niet, dan helpt alleen halveren: schakel de helft van de plug-ins uit, meet opnieuw en halveer afhankelijk van het resultaat verder binnen de belaste helft. Bij 32 plug-ins zijn dat vijf herstarts in plaats van 32. Maak vooraf beslist een back-up, want plug-ins die wereldgegevens schrijven, kunnen bij verwijdering inhoud achterlaten die zonder die plug-in niet meer werkt.

Chunks voorgenereren voordat spelers erop lopen

Dit is de effectiefste losse maatregel uit dit hele artikel, en juist deze wordt het vaakst over het hoofd gezien. De reden ligt in de manier waarop Minecraft werkt: een al gegenereerde chunk van de schijf laden kost bijna niets. Een nieuwe chunk genereren betekent daarentegen hoogtekaart, biomen, ertsverdeling, grotten, structuren en lichtberekening, en een groot deel daarvan draait in de hoofdthread. Precies daar waar ook die 20 ticks per seconde moeten ontstaan.

Daarom treedt lag typisch op wanneer iemand met een elytra wegvliegt of een spoorlijn het niets in bouwt: de server genereert wereld terwijl hij tegelijk het spel moet doorrekenen. Wie de wereld één keer vooraf tot aan de wereldgrens genereert, verandert dure rekenarbeid in goedkoop lezen van de schijf.

Chunky, het aangewezen gereedschap

Chunky is tegenwoordig de gangbare voorgenerator en draait als plug-in op Paper, Spigot en Purpur en als mod op Fabric en Forge. Het verloop is op alle platformen hetzelfde:

/chunky world world
/chunky center 0 0
/chunky radius 5000
/chunky start

De radius staat in blokken en moet passen bij de wereldgrens. Voortgang en geschatte resterende tijd meldt Chunky uit zichzelf; met /chunky pause en /chunky continue pauzeert en hervat u de run op elk gewenst moment, ook over een herstart heen.

De Nether en de End zijn aparte werelden en moeten afzonderlijk worden voorgegenereerd. Op Paper en Spigot heten ze standaard zo:

/chunky world world_nether
/chunky radius 1000
/chunky start

Voor de Nether volstaat een kleinere radius, omdat daar één blok overeenkomt met acht blokken in de bovenwereld. Een Nether-radius van 1000 dekt dus 8000 blokken bovenwereld af.

Waar u rekening mee moet houden

• Tijd. Een radius van 5000 blokken is ongeveer 78 miljoen blokken oppervlak. Afhankelijk van hardware, modpack en wereldgenerator duurt dat van een uur tot meerdere dagen. Modpacks met een eigen wereldgenerator zijn duidelijk trager dan vanilla.
• Opslagruimte. Een voorgegenereerde wereld beslaat al snel meerdere gigabytes. Controleer vooraf hoeveel er vrij is, anders loopt de schijf tijdens de run vol en dat treft de server harder dan welke lag ook. Hoe u dat controleert en opruimt, leest u in Schijf vol: opslagruimte vinden en vrijmaken.
• Moment. Doe de voorgeneratie met een lege server, niet tijdens het spelen. Tijdens de run is de tickrate zoals verwacht slecht, dat is geen fout. De hele bedoeling is nu juist om die belasting uit de speeltijd te halen.
• Wereldgrens instellen. Zonder grens loopt er ooit iemand voorbij het voorgegenereerde gebied en begint alles opnieuw. Zet de grens op dezelfde radius die u hebt voorgegenereerd.

Achteraf opruimen

Is de wereld al gegroeid en bevat die gebieden waar niemand meer komt, dan verwijdert Chunky de chunks buiten de wereldgrens:

/chunky trim

Dat verkleint de wereld en daarmee ook de back-ups merkbaar. Maak vooraf beslist een back-up, want verwijderde chunks worden bij het volgende bezoek opnieuw gegenereerd en alles wat spelers daar hadden gebouwd, is verloren.

Wanneer Chunky geen optie is

Op oudere servers staat vaak nog WorldBorder met /wb fill. Dat dient hetzelfde doel, maar het project wordt al jaren nauwelijks meer onderhouden, en voor actuele serverversies is Chunky de betrouwbaardere keuze. Controleer in beide gevallen vooraf of de aangeboden versie echt bij uw serverversie past.

view-distance en simulation-distance

Deze twee waarden in server.properties worden voortdurend door elkaar gehaald.

• view-distance bepaalt tot hoe ver chunks naar de client worden verstuurd. Kost bandbreedte en wat geheugen.
• simulation-distance bepaalt tot hoe ver de server entiteiten, redstone en blokupdates doorrekent. Kost CPU-tijd in de hoofdtick.

Chunks tussen de simulatiegrens en de kijkgrens worden wel weergegeven, maar staan aan serverzijde stil. De kosten groeien kwadratisch: bij view-distance=10 gaat het om 21 maal 21, dus om 441 chunks per speler.

Beproefde uitgangswaarden voor een survivalnetwerk met 10 tot 30 spelers:

view-distance=8
simulation-distance=5

Komt u nog handleidingen tegen met no-tick-view-distance, dan geldt: die Paper-optie is achterhaald. Mojang heeft met 1.18 simulation-distance geïntroduceerd en daarmee hetzelfde probleem officieel opgelost. Wie de oude waarde vandaag instelt, bereikt niets.

De prijs van lage waarden wordt zelden genoemd: bij een simulation-distance onder 4 vallen AFK-farms stil, mobspawns gedragen zich anders, ovens in de naastgelegen chunk lopen niet door en redstoneklokken staan stil. Wie een community met veel farms heeft, bezuinigt hier op de verkeerde plek en ruilt een technisch probleem in voor een spelersprobleem. Ga in stappen van één omlaag en meet na elke stap opnieuw.

Opruimen zonder de wereld te slopen

Elke ingreep in de wereldgegevens begint met een back-up bij een gestopte server. Geen compromis, geen uitzondering:

tar -czf wereld-backup.tar.gz world world_nether world_the_end

Daarna loont een blik op de omvang van de regiogegevens:

du -sh world/region

Werelden die over jaren zijn gegroeid, bevatten vaak honderden megabytes aan terrein waar één enkele speler ooit één keer overheen is gevlogen. Die chunks kosten geen ticktijd, maar wel schijfruimte, en ze verlengen elke opslagronde. Wordt de ruimte krap, dan helpt daarnaast het artikel Schijf vol onder Linux opruimen.

Regelmatige spikes van enkele seconden die precies om de vijf minuten optreden, zijn bijna altijd het automatisch opslaan. In bukkit.yml regelt ticks-per.autosave het interval, in paper-world-defaults.yml begrenst max-auto-save-chunks-per-tick hoeveel er per tick wordt weggeschreven. Een kleinere waarde spreidt de belasting in plaats van die te bundelen.

Voor kleine privéservers bestaat sinds de 1.21-reeks in server.properties de optie pause-when-empty-seconds. Staat daar een waarde groter dan nul, dan stopt de server na die tijd zonder spelers met het ticken van de wereld. Op een gedeelde rootserver scheelt dat merkbaar rekentijd.

Wanneer de JVM remt

Blijft de ticktijd gemiddeld laag, maar schiet die onregelmatig omhoog naar enkele honderden milliseconden, dan is vaak de garbage collection van de Java-runtime de boosdoener. Dat controleert u rechtstreeks:

spark gcmonitor
spark heapsummary

Twee wijdverbreide misverstanden. Meer heap is niet automatisch beter, want grote heaps veroorzaken langere pauzes bij het opruimen. En de heap mag nooit zo groot worden gekozen dat het besturingssysteem in de swap wordt gedrukt. Een Minecraft-server die swapt, is reddeloos traag. Controleer dat met vmstat 1 5: blijvende waarden in de kolommen si en so zijn het doodvonnis. De achtergrond daarvan leest u in het artikel Swap instellen en Out of Memory voorkomen.

Deze melding is een symptoom, geen oorzaak:

java.lang.OutOfMemoryError: Java heap space

De heap verhogen schuift de crash alleen maar op wanneer een plug-in geheugen lekt of er miljoenen entiteiten bestaan.

Bij de Java-versie verschillen de distributies duidelijk, en juist daarop stranden veel installaties. Vanaf Minecraft 1.20.5 is Java 21 vereist. Debian 12 levert in de standaardrepository alleen OpenJDK 17 en geen OpenJDK 21, Debian 13 levert 21 en 25, maar geen 17. Ubuntu 22.04 en 24.04 hebben 17 en 21 in de repository. Wie op Debian 12 moet blijven, installeert Temurin uit de Adoptium-repository. De stappen staan in Java 21 op Debian installeren, voor oudere serverversies in Java 17 op Debian installeren.

Grijp daarbij niet naar het gemakkelijke verzamelpakket default-jre-headless. Dat wijst afhankelijk van de release naar een totaal andere versie: Debian 13 en Ubuntu 24.04 leveren er Java 21 mee, Debian 12 levert Java 17, Debian 11 en Ubuntu 22.04 leveren Java 11. De installatie verloopt overal foutloos, maar op de laatste twee start de server toch niet. Noem de versie daarom uitdrukkelijk, dus openjdk-21-jre-headless.

java -version
java -XX:+PrintFlagsFinal -version 2>/dev/null | grep -w MaxHeapSize

De 2>/dev/null onderdrukt de versiebanner die de JVM naar de foutuitvoer schrijft en die anders midden in de uitvoer belandt. En grep -w MaxHeapSize levert precies één regel op, terwijl een onscherpe zoekopdracht ook SoftMaxHeapSize vindt.

Wanneer het misgaat en hoe u terugkomt

De server breekt af met een watchdog-fout. In het logbestand staat dan zoiets als dat één enkele tick 60 seconden heeft geduurd en dat de server als gecrasht wordt beschouwd. Dat is geen storing, maar een beveiliging tegen een proces dat blijvend vasthangt. De bijgevoegde stacktrace is goud waard: die laat precies zien waarin de server vastliep. De waarde max-tick-time in server.properties regelt die drempel. Die drempel uitschakelen verhelpt niets, het verandert de crash alleen in een server die permanent bevroren blijft.

Na een wijziging in de configuratie is het erger geworden. Juist daarom geldt de belangrijkste regel van deze zoektocht: steeds maar één wijziging per meting, en noteer de uitgangswaarde. Wie view-distance, entity-ranges en Java-flags tegelijk aanpast, weet achteraf niet wat er heeft gewerkt.

De server start na de crash niet meer op. Meestal is level.dat beschadigd. In de wereldmap staat level.dat_old, dat u eroverheen kunt kopiëren nadat u eerst een kopie van de kapotte stand hebt bewaard. Bij beschadigde regiobestanden helpt alleen de back-up.

Alles is geoptimaliseerd en de lag blijft. Controleer dan de laag eronder: %steal in mpstat, het swapgebruik in vmstat en de latency van de schijf. Blijft de ticktijd hoog terwijl Spark geen enkele veroorzaker boven 10 procent aanwijst, dan is het simpelweg te veel inhoud voor te weinig prestaties per kern. Dan helpt opsplitsen over meerdere instanties of meer rekenkracht, niet nog een draai aan de volgende configuratieknop.

Alleen de spelers hebben hoge pings, de server zelf is rustig. Dan ligt het aan het netwerk. Een locatie met korte routes naar uw spelers maakt hier het grootste verschil. Voor servers in Frankfurt am Main liggen typische latenties vanuit de Benelux in het lage dubbelcijferige bereik. Treden storingen plotseling en gebundeld op, dan kan er ook een aanval achter zitten, zie Server tegen DDoS-aanvallen beschermen. Aan de clientkant verschijnen dan meldingen van dit type:

Internal Exception: io.netty.handler.timeout.ReadTimeoutException
Timed out
Connection reset

Waaraan u merkt dat het echt verholpen is

Een oplossing geldt pas als bevestigd wanneer die standhoudt onder precies dezelfde belasting waaronder het probleem optrad. 's Nachts met twee spelers draait ook een kapotte server soepel. Controleer daarom tijdens de piekuren:

• spark tps toont in het venster van 15 minuten 20,0 en niet alleen in het venster van 5 seconden.
• Het 95e percentiel van de ticktijd ligt onder 40 ms, het maximum onder 100 ms.
• 24 uur aan logbestanden zonder ook maar één regel "Can't keep up!".
• Een vers Spark-profiel toont geen enkele afzonderlijke post boven 15 procent meer.
• spark gcmonitor meldt geen pauzes boven 200 ms.
• De spelers die het probleem hadden gemeld, bevestigen de verbetering op dezelfde plek in dezelfde spelsituatie.

Noteer de waarden van voor en na, idealiter met datum en met de wijziging die u toen hebt doorgevoerd. Bij de volgende inzinking over drie maanden is die lijst meer waard dan welke handleiding ook, want hij laat zien wat op precies uw server al eens heeft gewerkt. Zet u de server opnieuw op, dan vindt u de bijbehorende basis in Minecraft-server op Debian installeren en in de Checklist voor een nieuwe rootserver.