In deze blog post leggen we, ook technisch, uit hoe we de LAG op onze Survival server hebben opgelost en hoe we er gekomen zijn. We willen open zijn in wat we hebben gedaan, en wat wel en wat niet heeft gewerkt voor ons.

Op 28 april hebben we ScoutCraft gelanceerd. Met een email naar jullie en wat posts op de socials zijn we live gegaan. Na een paar minuten waren er al bijna 100 mensen aanwezig op ScoutCraft! Waanzinnig!

Wij, de leiding, konden ons geluk niet op; we hebben een aantal weken gewerkt aan een mooie speelwereld en er zaten zo ongelofelijk veel mensen op, het was te gek! Voorafgaand aan de lancering hebben we ongeveer 2 weken BETA tests gedaan. We hebben een aantal groepen uit Nederland uitgenodigd om te spelen op ScoutCraft en om alle functies uit te testen.

Op de Creative server (lees hier wat Creative precies is) ging alles al snel goed, jullie hadden snel door hoe je plots kan claimen en er werden mooi dingen gebouwd. Tot onze schrik ging het heel erg snel bergafwaarts met de survival server. De LAG was niet te houden.

Lag is een gaming term, het wil zeggen dat je vertraging hebt in het spel. Dat kan verschillende redenen hebben en bij ons is die helaas een erg ingewikkelde, namelijk de server zelf.

LAG op de Survival server

Hier zie een je grafiek van hoe erg de LAG was. Je ziet een oranje gedeelte, dit gaf aan hoe erg de server achterliep. Dit oranje gedeelte hoort normaal groen te zijn.

Voor het draaien van de server heeft onze sponsor (FUGA) niet bezuinigd. We kregen de beschikking over 2 grote virtual machines met 12 cores en 44gb geheugen. Genoeg voor elk programma dachten we.

Minecraft heeft een mechanisme waarin alles plaatsvind, dit heet een ’tick’. Een tick is een stukje tijd waarin alles van de servers gebeurt. Elke tick worden er monsters bewogen, wolken bewogen, kun je een blokje hakken en nog veel meer. Een normale tick duurt ongeveer 50 milliseconden.

Echter is het zo een tick op dit moment bij ons ongeveer 150 milliseconden duurde. Dat betekende dat je soms wel 0,15 seconden moest wachten voordat je blokje verdween. Dit lijkt niet veel maar dit zorgt voor heel veel problemen.

Deze ticks worden uitgedrukt in TPS (ticks per second). 20 ticks per second is perfect.

Werk aan de winkel

Voor de leiding betekende dit slecht nieuws. De kwaliteit van de Survival server gaat hier door omlaag, alles duurt langer en sommige dingen werken slecht. Op dinsdagavond werd het voor ons enorm duidelijk: we hebben een héél groot probleem.

Dinsdagnacht

Tot diep in de nacht werd er gezocht naar redenen die konden verklaren waarom de server zo enorm veel leed aan LAG. Op de survival server werd amper rekenkracht of geheugen gebruikt en in eerste instantie is dit de plek waar we zijn gaan zoeken. Als een computer 12 cores heeft, wil je ze graag alle 12 gebruiken! Of als je 44GB geheugen hebt is het zonde als het leeg is, toch?

Nu wordt het echt heel erg nerdy
Geen zin om dit te lezen? Skip naar het einde.

We begonnen met het tunen van het JAVA proces dat PaperMC draait. We hebben de JAVA heap sizes verhoogd in de hoop dat meer geheugen meer snelheid zou betekenen. We zetten de heap sizes naar:

-XMs10G -XM20G

Dit had geen effect, erger nog, het leek zelfs tegen te werken.

Hierna hebben we, op advies van lieve mede-admins op Reddit en forum posts een aantal plugins geprobeerd om de LAG terug te brengen. We proberen de plugins: Clearlagg, Entitystacker (deze stopt bijvoorbeeld koeien op elkaar en dan zie je er x3 bij staan). We maken Timing na timing (een timing is een overzicht van wat er lang duurt.

Niets lijkt te helpen.

Woensdagavond en nacht

Op woensdagavond beslissen we om een stap te nemen die de PaperMC community ons aanraad om uit te voeren. We nemen de server de hele nacht in onderhoud en pregenereren de wereld.

De Minecraft wereld bestaat uit chunks. Een chunk is een stuk in de Minecraft wereld van 16 bij 16 blokken. Elke chunk moet worden gegenereerd, Minecraft beslist: komt er een berg, een mineshaft, welk materiaal moet er bij en hoe hoog moet alles zijn. Wij hebben de fout gemaakt om te beslissen dat dit best kan terwijl spelers de wereld aan het ontdekken waren.

Dat betekende dat als je als speler een chunk in liep die nog nooit door iemand anders eerder gezien was, dat de server deze moest berekenen. Dit zorgde voor veel problemen.

We hebben dus rond 00:00 op woensdag de server in onderhoud geplaatst, dit betekende voor de spelers dat zij tijdelijk niet op ScoutCraft terecht konden. En we hebben de server tot diep in de nacht deze wereld zelf laten berekenen. Je kunt onze onderhoudsaankondiging hier nog zien.

Tot diep in de nacht heeft @Acixsi dit proces in de gaten gehouden, dit grote proces moest en zou slagen.

In de ochtend is het probleem nog niet opgelost. Nog steeds gebruikt de server lang niet alle processoren en het geheugen wat beschikbaar gesteld is.

De oplossing

Op donderdagavond hebben we met het hele staffteam crisisoverleg gehad. Dit kan echt zo niet langer, we zijn inmiddels 3 dagen verder, er zijn heel erg veel uren in een oplossing gestoken en nog steeds is er geen zicht op een oplossing. We hebben nog steeds een TPS van rond de 5 (20 is perfect, onder de 16 wordt beschouwd als erg slecht).

Na het overleg kwamen we tot de conclusie dat de meest voor de hand liggende reden van de LAG issues een fenomeen is dat CPU scheduling heet. Dit betekent kort door de bocht dat omdat je een processor deelt met anderen, Minecraft niet weet hoe die hier goed mee om kan gaan.

We besloten een dedicated server af te nemen bij Hetzner met een hele goede processor, die snelle single core performance heeft. We hebben de keuze gelegd bij de Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz.

Na een korte migratie op vrijdag, is de LAG vrijwel direct opgelost! We voelen ons allemaal een stuk opgeluchter, en we kunnen met veel enthousiasme zeggen dat het LAG probleem op de Survival server is opgelost.