Garry's Mod lag wordt bijna altijd veroorzaakt door één van de drie dingen: tickrate die hoger is ingesteld dan de server aankan, te veel props en entiteiten, of een addon die elke tick werk doet. Geheugen is zelden de oorzaak, wat verklaart waarom het upgraden naar een groter plan vaak niets verandert.
Source voert zijn simulatie uit op één thread. Dat ene feit verklaart het grootste deel van het volgende.
Tickrate is een budget, geen kwaliteitsinstelling
Tickrate is hoe vaak per seconde de server de wereld simuleert. Een hogere tickrate voelt scherper aan, en kost CPU op elke tick, of er nu iets interessants gebeurt of niet.
De valkuil is dat tickrate alles vermenigvuldigt. Een fysiek zware Sandbox-server die het bij een lagere tickrate aankan, kan bij een hogere zonder andere wijziging omvallen, omdat elke prop nu vaker wordt gesimuleerd.
- Sandbox is fysiek intensief. Props, constraints en ragdolls kosten CPU per tick, en spelers bouwen er in de loop van de tijd meer van.
- TTT en DarkRP gedragen zich anders. Ronde-gebaseerde gamemodes hebben pieken aan het begin van een ronde; roleplay-servers bouwen gedurende uren entiteiten op.
- Verhoog de tickrate pas als de server stabiel is bij de lagere stand. Het is de laatste afstapeling, niet de eerste.
Props en entiteiten zijn de echte kostenpost
Op elke Sandbox- of DarkRP-server die langdurig draait, groeit het aantal entiteiten zonder dat iemand dat bewust besluit.
- Prop-limieten bestaan niet voor niets. Een server zonder limiet ontdekt zijn grens meestal op een moeilijke manier, vaak tijdens een bouwsessie.
- Beperkte constructies kosten meer dan losse props. Fysieke constraints worden elke tick opgelost, en een grote gelaste constructie is veel duurder dan hetzelfde aantal losse props.
- Automatische opruiming op schema. Automatisch props opruimen tussen rondes of op een timer is de effectiefste aanpassing op de meeste servers.
- Ragdolls en gibs stapelen zich op. Ze zijn individueel goedkoop, maar niet goedkoop als ze er honderden zijn.
Addons: de gebruikelijke verdachte die niemand controleert
Een addon die elke tick werk doet kost je meer dan zestig keer per seconde continu. De meeste adverteren dit niet.
- Voeg addons toe in kleine batches, zodat je weet wat het probleem veroorzaakt wanneer de prestaties achteruitgaan.
- Wees achterdochtig over alles dat reageert op gebeurtenissen ergens op de map, in plaats van nabij een speler.
- Workshop-collecties worden door elke speler die meedoet gedownload. Een grote collectie vormt evenzeer een drempel om mee te doen als een belasting voor de server. Dit voel je vooral bij Sandbox-buildservers: zie Sandbox mastery.
Hetzelfde principe bepaalt de modkeuze in Factorio: wat kost het per tick, en moet iedereen het geïnstalleerd hebben?
Diagnoseer voordat je upgrade
Werk dit af in deze volgorde, omdat de goedkope oplossingen ook het waarschijnlijkst zijn:
- Tel entiteiten. Als het aantal de hele dag stijgt, is dat het probleem.
- Zet addons in batches uit en kijk of de ondergrens omhoog gaat.
- Verlaag de tickrate één stap en kijk of de haperingen verdwijnen.
- Controleer het geheugen laatst. Als het niet vol is en geen grote schommelingen vertoont, is RAM niet je beperkende factor.
Dit is dezelfde volgorde die geldt voor Minecraft tick lag, waar meer geheugen ook niet helpt bij een CPU-beperkte server. Andere game, dezelfde fout.
Onze Garry's Mod serverhosting geeft toegang tot tickrate- en addonbeheer via het paneel, zodat het testen van een lagere tickrate een herstart vereist in plaats van een supportticket.
Wanneer het plan echt te klein is
Geheugen is de bottleneck als je ziet dat de server crasht in plaats van vertraagt: crashes bij mapwissel, of falen bij het laden van een grote Workshop-collectie bij opstart. Dat is een echte reden om een hoger plan te nemen. Een server die goed draait maar haperingen kent tijdens bouwen niet.
Als je een buildserver runt voor zes vrienden, is het kleinste plan met een prop-limiet beter dan een groter plan zonder limiet.

door 


