Lag på en Rust-server skyldes sjelden at én enkelt ting går i stykker. Nesten alltid handler det om at server.fps faller under 30, og derfra går det som en dominoeffekt: rubber banding, dører som nekter å lukke seg, raids som ser ut som en lysbildefremvisning og den fryktede frysen av hele serveren hvert femte minutt når kartet lagres. Som host med flere titalls Rust-instanser på Pterodactyl ser vi at de samme fem årsakene står bak ~90 % av alle saker om at «Rust-serveren min lagger». Denne guiden går gjennom hva som faktisk er galt på maskinen din, hva du skriver for å bekrefte det og de nøyaktige verdiene som fikser hver årsak.
Symptomer: slik ser serverlag faktisk ut
Før du endrer noe, må du bekrefte at det er serverlag og ikke klientlag. Den raskeste måten er å gå inn i serverkonsollen (Konsoll-fanen i Pterodactyl, eller RCON) og skrive:
server.fps
Dette er simuleringsraten til den dedikerte serveren din, ikke FPS-en på klienten. Tallene du vil se:
- 200+ på en vanilla-server med under 50 spillere: sunt
- 120 til 200 på en moddet server med 50 til 100 spillere: akseptabelt
- 60 til 120 moddet med tunge plugins: begynner å føles tregt for spillerne
- Under 30: dette er det spillerne kaller «lag». Dører henger etter, byggeblokker flimrer, treff registreres ikke og kjøretøy hakker
Ligger server.fps på 200+ mens spillerne fortsatt melder om lag, er problemet på klientsiden (skjermkortet deres, nettverket deres eller pakketap mellom dem og datasenteret), og ingenting du endrer på serveren hjelper. Er den under 60, særlig under kamper eller nær store baser, gjelder resten av artikkelen.
Årsak 1 (vanligst): spikes fra garbage collection i plugins
Dette er den aller største årsaken til saker av typen "serveren var fin i går, og nå lagger den hvert 30. sekund". Plugins på Oxide/uMod bygger opp objektallokeringer, .NET-runtimen stopper hovedtråden for simuleringen for å rydde opp, og du får en synlig frys på 0,5 til 1,5 sekunder for hver spiller på serveren.
Løsningen har to deler. Kjør først en manuell opprydding fra konsollen:
gc.collect
Forsvinner lagget rett etter denne kommandoen, er garbage collection i plugins flaskehalsen din. Den permanente løsningen er enten å redusere pluginbelastningen eller å planlegge oppryddinger på forhånd.
Plugins som er beryktet tunge (gå gjennom disse først hvis du har lag):
- CopyPaste som limer inn store blueprints når det er mest folk inne
- BetterChat med omfattende plugins for chatlogging lagt oppå
- Backpacks med 48+ plasser og mange spillere
- ZoneManager med mange overlappende soner
- NTeleportation når mange spillere teleporterer samtidig
- Alt som sjekker noe hver tick (CombatLog, forfallsplugins). Se i kildekoden til pluginen etter OnEntityTick eller lignende hooks.
Åpne Pterodactyl-konsollen og kjør oxide.plugins (eller carbon.plugins hvis du bruker Carbon) for å se hva som faktisk er lastet. Har du mer enn 50 plugins, har du et pluginproblem uansett hvilke det er.
Årsak 2: lagringsspiken hvert femte minutt
Som standard lagrer Rust servertilstanden hvert 300. sekund. På enhver server med folk på er denne lagringen synkron og stopper hele simuleringen i 2 til 8 sekunder, avhengig av antall entiteter og diskhastighet. Spillerne opplever det som: gå, frys, teleporter.
Åpne serverkonfigurasjonen og finn:
server.saveinterval 300
For en wipe med mange spillere (alt etter dag tre med 50+ spillere) setter du den til:
server.saveinterval 600
For svært store kart eller mot slutten av en wipe er 900 fornuftig. Baksiden: krasjer serveren, mister du opptil så mange sekunder med fremgang. På godt hostet maskinvare er krasjrisikoen nesten null, så 600 til 900 går fint. Vi setter nye Rust-servere hos DoomHosting til 600 som standard nettopp av denne grunnen.
Du kan bekrefte at det er lagringsspiken som skaper akkurat ditt lag ved å følge med på serverkonsollen i det øyeblikket frysen skjer. Ser du [Server] Saving complete rett etter frysen, var det synderen.
Årsak 3: entiteter som hoper seg opp gjennom wipen
Rust spawner og holder styr på hver dør, hver lagringsboks, hver kodelås, hver smelteovn og hver gjenstand som ligger på bakken. Innen dag 5 i en wipe har en server med 100 plasser og 30 aktive baser ofte passert 300 000 entiteter. Hver entitet koster simuleringstid hver tick.
Sjekk antall entiteter:
server.entitiesPerPlayer
print(BaseNetworkable.serverEntities.Count)
Sunne nivåer:
- Dag 1: under 50 000 entiteter
- Dag 3: 100 000 til 150 000
- Dag 5+: 200 000 til 300 000 er normalt, 400 000+ er når du ser lag sent i wipen
Det finnes ingen ren løsning midt i en wipe, annet enn å skru på mer aggressivt forfall (raskere riving av baser uten TC) og opprydding av gjenstander på bakken:
decay.scale 1.5
decay.upkeep true
Den egentlige løsningen er å wipe. Dør serveren jevnlig rundt dag 7 til 10, bør du korte ned wipe-planen. De fleste vellykkede moddede servere wiper ukentlig eller annenhver uke nettopp på grunn av denne kurven.
Årsak 4: server.tickrate, fps.limit og andre innstillinger som får skylden, men sjelden betyr noe
Det er en seiglivet myte at du fikser lag ved å senke server.tickrate. Det gjør du ikke. server.tickrate er på klientsiden og styrer hvor ofte klientene sender posisjonsoppdateringer til serveren. Å senke den reduserer nettverkstrafikken, men frigjør ikke CPU på den dedikerte serveren din.
På samme måte gir ikke fps.limit på serveren deg mer FPS. Den setter et tak for å unngå bortkastede CPU-sykluser. 256 er den fornuftige standarden. Går du lavere, kan du faktisk skape lag, fordi serveren får mindre slingringsmonn for spikes.
Dette er det som betyr noe:
server.maxplayerssatt høyere enn maskinvaren tåler. Vanilla med 100 plasser trenger minst 4 dedikerte kjerner på 4,5 GHz+, moddet med 100 plasser trenger 6+ og minst 16 GB RAM.- Delt CPU hos en billighost. Rust hater delte kjerner: ytelse per tråd er alt.
- At serverprosessen ikke er låst til en rask kjerne.
Er du hos en host som bruker Ryzen 9- eller i9-maskinvare, mens serveren fortsatt ligger under 60 server.fps med under 50 spillere, er flaskehalsen programvare (plugins, entiteter, lagring) og ikke maskinvare.
Årsak 5: lag etter oppdatering («lagger etter oppdatering»-tilfellet)
Nesten hver stor patch fra Facepunch gir en midlertidig ytelsesforverring et sted, som regel i en ny entitetstype eller et omskrevet system. Mønsteret i 2026:
- Patchen kommer torsdag med force wipe
- Spillerne melder om hakking i 3 til 4 dager
- Modskaperne sender ut kompatibilitetsoppdateringer i løpet av helgen
- Tirsdagen eller onsdagen etter patchen stabiliserer det seg
Startet lagget rett etter en oppdatering fra Facepunch uten at du har rørt pluginsene, er årsaken nesten helt sikkert en utdatert plugin som ikke er oppdatert for det nye API-et. Sjekk sidene på Oxide/uMod for hver plugin du har, og fjern eller deaktiver alt som ikke er oppdatert siden patchen. Feilloggen (server.log) peker som regel ut synderen med stack traces for NullReferenceException.
Sjekkliste for feilsøking (lim dette inn i konsollen)
Når en spiller melder om lag, kjører du disse i rekkefølge i Pterodactyl-konsollen:
server.fps
print(BaseNetworkable.serverEntities.Count)
oxide.plugins
gc.collect
server.fps
Sammenlign den første server.fps-verdien med verdien etter gc.collect. Hoppet den med 20+, er garbage collection i plugins flaskehalsen, og du må gå gjennom pluginsene. Rørte den seg ikke, er flaskehalsen entiteter (årsak 3) eller maskinvare (årsak 4).
Dette justerer vi som standard på Rust-serverne våre
Til sammenligning er dette hva hver ferske Rust-installasjon hos DoomHosting leveres med rett ut av boksen:
server.saveinterval 600fps.limit 256decay.scale 1.0(kan konfigureres per server)- Ressursgrenser i Pterodactyl dimensjonert slik at Rust-prosessen alltid har dedikert CPU-slingringsmonn
- Serverprosessen kjører på Ryzen 9-maskinvare med enkelttråds boost over 5,0 GHz. Rust er begrenset av én tråd, så høy klokkefrekvens slår flere kjerner hver gang.
- Automatiske nattlige sikkerhetskopier, så du kan skru opp saveinterval uten frykt
Vi leverer også bare de pluginsene du installerer selv, ingen forhåndsinstallert dødvekt. De fleste lagsakene vi ser når folk flytter fra konkurrenter, kommer fra plugins som er blitt liggende igjen fra forrige host.
Lagger det fortsatt?
Gå gjennom årsakene igjen, i rekkefølge: garbage collection i plugins (gc.collect-testen), så lagringsintervall, så entiteter, så maskinvare. Rekkefølgen er viktig fordi hver årsak er omtrent 5 ganger dyrere å fikse enn den forrige. Har du gjort alle fire, og er server.fps fortsatt under 60 med under 50 spillere, trenger du nesten helt sikkert enten bedre maskinvare eller en fersk wipe.
Host Rust-serveren din hos DoomHosting
Er du lei av å feilsøke tickrate hos en host med delte CPU-er, kjører Rust-serverne våre på dedikerte Ryzen 9-kjerner med justeringene over allerede på plass. Sett opp en Rust-server hos DoomHosting, velg wipe-planen din og la oss ta oss av resten. Umiddelbart oppsett, full FTP for Oxide-pluginsene dine og et supportteam som er tilgjengelig 24/7 og faktisk spiller spillet.
