Lag op je Minecraft-server: vind de oorzaak voordat je iets oplost

Voordat je ook maar één instelling aanpast, moet je weten welke van drie soorten lag je hebt: de tickloop van de server die achterloopt, het netwerk tussen spelers en server, of de eigen computer van een speler die moeite heeft het spel te tekenen. Draai /spark tps in je drukste uur. Blijven de tickduren onder 50 ms, dan houdt de server het bij en komt de lag die je spelers voelen ergens anders vandaan.

De meeste "optimalisatiegidsen" slaan die stap over en geven je een lijst met instellingen. Sommige van die instellingen helpen, een paar maken het spel slechter en geen enkele lost een probleem op dat je nog niet hebt gevonden. Deze gids begint bij de diagnose.

Kort samengevat. Meet op het piekmoment, met spark. Is de server traag, maak dan een profiel en volg het grootste getal: meestal zijn het entiteiten, chunkgeneratie, redstone en trechters, of één plugin. Is de server snel maar hebben spelers lag, kijk dan naar het netwerk. Heeft maar één speler lag, dan ligt het aan zijn computer. Herstart in je rustige uur, en alleen als daar een reden voor is.

Drie soorten lag (servertick, netwerk, client)

Even een nerdy zijstap over de cijfers, want die verklaart waarom TPS liegt. De server mikt op 20 ticks per seconde, dus elke tick heeft een budget van 50 ms. TPS kan nooit hoger zijn dan 20, dus een server die 10 ms per tick nodig heeft en een server die 48 ms nodig heeft, laten allebei 20,0 TPS zien. De eerste kan een veelvoud van zijn huidige belasting aan, de tweede is nog maar één trechterfarm verwijderd van lag. MSPT (milliseconden per tick) toont die ruimte, dus let op MSPT, niet op TPS.

Meet voordat je iets verandert

1. Kies het juiste uur. Lag die op het piekmoment optreedt, kun je niet om vijf uur 's ochtends meten. De vier drukste uren van ons netwerk zijn 14:00 UTC tot 18:00 UTC in jouw tijdzone, en de openbare statistiekenpagina van je vermelding toont je eigen drukste uren.
2. Draai /spark tps. Het toont de TPS over de laatste 5 seconden tot 15 minuten en de tickduren als minimum, mediaan, 95e percentiel en maximum. Een mediaan ruim onder 50 ms met een 95e percentiel erboven wijst op pieken, niet op constante overbelasting. Het /mspt van Paper geeft de korte versie.
3. Draai /spark health. Het voegt CPU-gebruik, geheugen en schijf toe, zodat je in één oogopslag ziet of de machine zelf iets tekortkomt.
4. Lees de console. De vanilla-waarschuwing Can't keep up! Is the server overloaded? Running 2034ms or 40 ticks behind (de serverconsole schrijft die altijd in het Engels) betekent dat de server achterliep en vooruit sprong om bij te komen. Eén per dag is ruis. Eén per minuut is een probleem.
5. Noteer de nulmeting: tijd, spelers online, MSPT-mediaan en 95e percentiel, en waar de spelers waren (een nieuw gebied, een grote farm, een event). Daarmee vergelijk je na elke wijziging.

Op een server zonder spark geeft het /tick query van vanilla (Java Edition 1.20.3 en later, permissieniveau 3) de gemiddelde tijd per tick en de percentielen.

Piek 16:00 UTC

0003060912151821

Tijden in UTC

Het drukst om 16:00 UTC met ongeveer 17.845 spelers, het rustigst om 01:00 UTC. Het drukste uur heeft 2,6 keer zoveel spelers als het rustigste.

Gemeten op 19 okt 2026, 23:05 UTCHoe we meten

Een spark-profiel lezen

Als de cijfers zeggen dat de server traag is, zegt de profiler waarom. De documentatie van PaperMC stelt voor:

/spark profiler start --timeout 600

Dat neemt tien minuten lang steekproeven van alle threads en geeft je een link naar het rapport. Twee varianten helpen bij specifieke problemen:

• /spark profiler start --only-ticks-over 100 legt alleen ticks vast die langzamer zijn dan 100 ms, waardoor korte lagpieken los komen van de normale achtergrond.
• /spark tickmonitor --threshold-tick 100 print een regel elke keer dat een tick langer dan 100 ms duurt, zodat je pieken kunt koppelen aan wat er in het spel gebeurde.

Het profiel moet draaien terwijl de lag optreedt. Een profiel van een rustige server om 05:00 zegt niets over de lag van 18:00.

Open in de viewer de serverthread en volg het grootste percentage naar beneden. Je zoekt de tak waar de tijd heen gaat:

• Entiteiten die tikken, vaak met mob-AI of het zoeken van paden door dorpelingen eronder, wijzen naar mobs (volgende sectie).
• Blokentiteiten, met trechters hoog in de lijst, wijzen naar trechterketens en opslagsystemen.
• Chunkwerk (genereren, laden, opslaan) wijst naar spelers die nieuw terrein verkennen.
• De naam van een plugin in de aanroepboom, of hoog in de uitsplitsing per plugin in de viewer, wijst naar die plugin. Noteer wat hij deed (een eventhandler, een geplande taak, een databaseaanroep) voordat je hem de schuld geeft, want dezelfde plugin kan prima draaien met een andere instelling.

Spark registreert ook garbage collection. Frequente pauzes van honderden milliseconden wijzen op geheugendruk, wat /spark gc in de loop van de tijd laat zien. Maak ook één keer een profiel als de server goed draait, zodat je weet hoe normaal eruitziet op jouw setup.

De gebruikelijke verdachten (entiteiten, chunkgeneratie, redstone, plugins, garbage collection)

Entiteiten

Mobfarms, handelshallen met dorpelingen, stapels gedropte items, mijnkarsystemen en decoraties met harnashouders: ze tikken allemaal mee. Op Paper toont /paper entity list de entiteiten die tikken per type, en een filter als /paper entity list minecraft:villager verfijnt dat, zodat je kunt vinden waar ze zich opstapelen. /paper mobcaps laat zien hoe vol de mobcaps zijn en /paper chunkinfo hoeveel chunks geladen zijn en tikken. De oplossingen zijn limieten, geen verboden: een plafond voor entiteiten per chunk, farmregels waar je spelers het mee eens zijn en een gesprek met degene die de hal met 400 dorpelingen bouwde.

Chunkgeneratie

Een nieuwe chunk genereren is een van de duurste dingen die een server doet, en spelers met elytra kunnen er tientallen per minuut eisen. Genereer de wereld één keer vooraf, met een plugin als Chunky (/chunky radius 5000, daarna /chunky start), tijdens rustige uren, en stel een bijpassende wereldgrens in met /worldborder set 10000. De grens neemt een diameter en de Chunky-radius is de helft, dus die twee getallen beschrijven hetzelfde vierkant. Daarna laadt verkennen alleen nog chunks van schijf, en dat is veel goedkoper.

Redstone en trechters

Snelle redstoneklokken en lange trechterketens tellen op. Paper biedt twee hefbomen in config/paper-world-defaults.yml. misc.redstone-implementation: ALTERNATE_CURRENT schakelt over op een snellere implementatie van redstonestof. hopper.disable-move-event: true maakt trechters goedkoper, maar breekt plugins die op dat event rekenen, zoals sommige beschermings- en trechterfilterplugins, dus test eerst. hopper.cooldown-when-full staat standaard al aan.

Plugins

Een zware plugin staat met naam in het profiel. De gangbare patronen zijn scoreboards, hologrammen of tablijsten die elke tick opnieuw worden opgebouwd, database- of webverzoeken op de hoofdthread, kaartrenderers die een grote wereld doorwerken en anticheatcontroles onder belasting. De oplossing is meestal eerst configuratie (verversintervallen, renderlimieten), dan een update en daarna een vervanging.

Garbage collection

Laat spark lange of frequente collectiepauzes zien, controleer dan eerst het geheugen: is -Xmx te klein voor de wereld en de plugins, en heeft -Xms dezelfde waarde? De aanbevolen flags van PaperMC zijn een degelijk uitgangspunt. Meer geheugen helpt alleen als de collectie het probleem is, en op een gedeelde host laat je het besturingssysteem verhongeren als je alles toewijst.

Oplossingen die werken

Als je de oorzaak kent, zijn dit de wijzigingen die meestal lonen, grofweg in de volgorde waarin wij ze zouden proberen:

De wijziging van simulation-distance is groter dan ze lijkt. Rond elke speler laat de server ongeveer een vierkant van chunks tikken, dus van 10 naar 6 gaan verkleint dat van ongeveer 21 bij 21 chunks naar 13 bij 13, van rond de 441 chunks naar rond de 169, terwijl spelers nog steeds zo ver kijken als view-distance toestaat.

Sommig populair advies helpt niet. Plugins die om de paar minuten alle gedropte items wissen, behandelen een symptoom en irriteren spelers. "Optimalisatieplugins" die hogere TPS beloven zonder te zeggen wat ze veranderen, verdienen een profiel ervoor en erna. En elke twee uur herstarten verbergt problemen in plaats van ze te vinden.

Netwerklag van buitenaf gezien

Eén detail verrast veel eigenaren. De statusping die serverlijsten gebruiken, wordt beantwoord door de netwerkthreads van de server, niet door de tickloop, dus een server kan in het spel flink lagen en onze pinger toch binnen een paar milliseconden antwoorden. Tick-lag kunnen we van buitenaf niet zien, en precies daarom bestaat spark. Achter Velocity praat de pinger alleen met de proxy.

Wat onze pinger wel kan zien, is het netwerk. De openbare statistiekenpagina van je vermelding (/server/your-server/stats) toont drie dingen die het lezen waard zijn:

• Reactietijd, hoe lang de server erover deed om onze pinger te beantwoorden, met de mediaan, het gebruikelijke bereik en een grafiek. Het niveau wordt vooral bepaald door de afstand tot onze pinger in West-Europa, dus een server in de Verenigde Staten laat daar geen 10 ms zien, tenzij een beschermingsnetwerk vanaf een nabij knooppunt antwoordt. Kijk naar de vorm in de tijd, niet naar de waarde.
• Pieken boven het gebruikelijke bereik. Als antwoorden alleen in je drukke uren ver boven het gebruikelijke bereik uitkomen, is de machine of de netwerkverbinding op die momenten verzadigd. Is het bereik op alle uren breed, verdenk dan de route of het netwerk van de host.
• Het storingslogboek. Korte gaten zijn herstarts of crashes. Lange gaten verdienen een blik op de statuspagina van je host en je crashrapporten.

Vraag getroffen spelers aan hun kant om een traceroute naar je adres (tracert op Windows, traceroute op macOS en Linux) en hun regio. Als iedereen in één land lag heeft en niemand anders, ligt het aan de route, en verhuizen of een beschermingsnetwerk met een nabij knooppunt toevoegen kan meer helpen dan welke instelling ook. Spelers die helemaal niet kunnen verbinden hebben andere problemen, die onze gids over verbindingsfouten behandelt.

Wanneer herstarten, en wanneer niet

Herstarts zijn niet gratis. Iedereen die online is wordt eruit gezet, en een speler die op een zondagavond midden in een gevecht wordt gekickt, onthoudt dat. Onze storingsdata laat zien hoe eigenaren ze in de praktijk plannen.

In de 30 dagen tot en met 16 oktober 2026 waren 90 vermeldingen op onze lijst minstens 90% van de tijd speelbaar. 58 daarvan hadden minstens één storing, die wij tellen als drie of meer pings achter elkaar zonder speelbaar antwoord, en samen hadden ze er 515. Gemeten van de eerste gemiste ping tot de laatste was de helft van de storingen binnen vijf minuten voorbij, en het langste tiende deel duurde langer dan twee uur. 375 van de 515 (73%) duurden 15 minuten of korter, de lengte van een herstart of een crash met reboot.

Wanneer begonnen die korte storingen? Eén uur springt eruit: 04:00 UTC, met 39 van de 375, de vorm van geplande nachtelijke herstarts. Buiten dat uur zijn ze redelijk gelijk over de dag verspreid. 64 van de 375 (17%) begonnen tussen 14:00 en 18:00 UTC, de vier drukste uren op onze lijst, ongeveer het aandeel dat je zou verwachten als herstarttijden willekeurig werden gekozen.

19%Korte storingen die begonnen in de vier drukste uren van het netwerk, afgelopen 30 dagen

Gemeten op 19 okt 2026, 21:52 UTCHoe we meten

Live, voor de afgelopen 30 dagen: 472 storingen bij 83 vermeldingen met 90% of meer, met een mediaan van 5 minuten minuten, en 70% daarvan van 15 minuten of korter. Het meest voorkomende beginuur van korte storingen is 04:00 UTC in jouw tijdzone, en het rustigste uur van het netwerk is 01:00 UTC.

Wat je hieruit meeneemt:

1. Herstart in je eigen rustige uur, niet op een rond getal. De heatmap op je statistiekenpagina laat zien welk uur dat is, en wanneer servers het drukst zijn laat zien hoe het per regio verschilt. Zitten je spelers verspreid over tijdzones, kies dan het laagste punt van je curve, niet middernacht.
2. Kondig het aan met een aftelling in de chat, en houd die kort.
3. Herstart met een reden. Updates, een geheugenlek dat je volgt, een configwijziging die het nodig heeft. Een dagelijkse herstart die niets oplost, kost nog steeds elke dag een kick.
4. Zoek het lek in plaats van het te verbergen. Als het geheugen oploopt tot een herstart, laat /spark heapsummary zien wat het vult.

Herstarts verhelpen geen tick-lag. Een farm die 30 ms per tick kost, kost vijf minuten na een herstart nog steeds 30 ms per tick. Ons uptimerapport heeft alle storingscijfers over de lijst.

Wanneer je hardware moet upgraden

Upgrade als het profiel dat zegt. De signalen:

• MSPT op het piekmoment blijft boven ongeveer 40 ms nadat je de verdachten hierboven hebt aangepakt.
• Het profiel toont tijd verspreid over gewoon vanilla-werk (entiteiten, chunks, blokupdates) zonder dat er één schuldige overblijft.
• Op een VPS laat top zien dat de CPU steal (de waarde st) in drukke uren oploopt, wat betekent dat je buren cores gebruiken waarvoor jij betaalt.

Koop dan eerst single-core-snelheid, want de tickloop draait op één core. Meer RAM lost alleen geheugenproblemen op. Kom je daarmee niet verder, verdeel dan de belasting: meerdere servers achter een Velocity-proxy, of Folia voor een heel grote wereld, allebei behandeld in onze gids over serversoftware. Hosting kiezen heeft de vragen die je moet stellen voordat je betaalt voor de nieuwe machine.