☀️ Ensimmäinen kuukausi 50 % halvemmalla:SUMMER26
Rust-palvelimen lagin korjaus 2026: miksi FPS tippuu ja miten palautat tickraten

Rust-palvelimen lagin korjaus 2026: miksi FPS tippuu ja miten palautat tickraten

Rust-palvelimen lagipiikit, matala server.fps, jäätyvät blokit tallennuksen aikana. Oikeat korjaukset hostilta: saveinterval, gc.collect, pluginit, entityt.

Magnus·
6 min lukuaika
·
26.5.2026
·
Päivitetty viimeksi: 2.8.2026

Rust-palvelimen lagi on harvoin yksi rikki mennyt asia. Kyse on melkein aina siitä, että server.fps tippuu alle 30, ja siitä se kaskadoituu kumilenkkiliikkeeksi, oviksi jotka kieltäytyvät sulkeutumasta, raideiksi jotka näyttävät diaesitykseltä ja siltä pelätyltä koko palvelimen jäätymiseltä viiden minuutin välein, kun kartta tallennetaan. Hostina, joka ajaa kymmeniä Rust-instansseja Pterodactylilla, näemme samojen viiden syyn kattavan noin 90 % kaikista "mun Rust-palvelin laggaa" -tiketeistä. Tämä opas käy läpi, mikä koneellasi oikeasti on rikki, mitä kirjoitat varmistaaksesi sen, ja tarkat arvot jotka korjaavat kunkin syyn.

Oireet: miltä palvelinlagi oikeasti näyttää

Ennen kuin muutat mitään, varmista että kyse on palvelimen eikä clientin lagista. Nopein tapa on mennä palvelimen konsoliin (Pterodactylin Console-välilehti tai RCON) ja kirjoittaa:

server.fps

Tämä on dedikoidun palvelimesi simulaationopeus, ei clientisi FPS. Luvut jotka haluat nähdä:

  • 200+ vanilla-palvelimella alle 50 pelaajalla: terve
  • 120-200 modded-palvelimella 50-100 pelaajalla: hyväksyttävä
  • 60-120 moddattuna raskailla plugineilla: alkaa tuntua pelaajista kankealta
  • Alle 30: tätä pelaajat kutsuvat "lagiksi". Ovet laggaavat, rakennusblokit välkkyvät, osumat eivät rekisteröidy, ajoneuvot nykivät

Jos server.fps istuu 200:ssa tai yli ja pelaajat silti raportoivat lagia, ongelma on clientin puolella (heidän näytönohjaimensa, verkkonsa tai pakettihäviö heidän ja konesalin välillä) eikä mikään palvelimella tehty muutos auta. Jos se on alle 60, erityisesti taisteluiden aikana tai isojen tukikohtien lähellä, loppu tästä artikkelista koskee sinua.

Rustin raid-taistelu

Syy 1 (yleisin): pluginien roskienkeruupiikit

Tämä on ylivoimaisesti yleisin syy "palvelin toimi eilen ja nyt se laggaa 30 sekunnin välein" -tiketeille. Oxiden ja uModin pluginit kasaavat objektiallokaatioita, .NET-ajoympäristö pysäyttää pääsimulaatiosäikeen siivotakseen ne, ja lopputuloksena jokainen palvelimen pelaaja näkee 0,5-1,5 sekunnin jäätymisen.

Korjaus on kaksiosainen. Aja ensin manuaalinen keruu konsolista:

gc.collect

Jos lagi katoaa heti tämän komennon jälkeen, pluginien roskienkeruu on pullonkaulasi. Pysyvä korjaus on joko vähentää pluginikuormaa tai ajastaa keruut ennakoivasti.

Pluginit jotka ovat tunnetusti raskaita (auditoi nämä ensin, jos sinulla on lagia):

  • CopyPaste kun se liittää isoja blueprintejä ruuhka-aikaan
  • BetterChat kun päälle on kasattu rikkaita chat-lokitusplugineja
  • Backpacks 48 paikan tai isommilla asetuksilla ja isolla pelaajamäärällä
  • ZoneManager monella päällekkäisellä alueella
  • NTeleportation kun moni pelaaja teleporttaa yhtä aikaa
  • Mikä tahansa joka pollaa joka tickillä (CombatLog, decay-pluginit). Tarkista pluginin lähdekoodista OnEntityTick tai vastaavat hookit.

Avaa Pterodactylin konsoli ja aja oxide.plugins (tai carbon.plugins, jos ajat Carbonia) nähdäksesi mitä oikeasti on ladattuna. Jos plugineja on yli 50, sinulla on pluginiongelma riippumatta siitä mitkä ne ovat.

Syy 2: viiden minuutin tallennuspiikki

Oletuksena Rust tallentaa palvelimen tilan 300 sekunnin välein. Millä tahansa asutulla palvelimella tuo tallennus on synkroninen ja pysäyttää koko simulaation 2-8 sekunniksi entitymäärästä ja levyn nopeudesta riippuen. Pelaajille se näyttäytyy näin: kävelyä, jäätyminen, teleportti.

Avaa palvelimesi asetustiedosto ja etsi:

server.saveinterval 300

Asutulle wipelle (mikä tahansa kolmannen päivän jälkeen ja 50+ pelaajaa) aseta tämä arvoon:

server.saveinterval 600

Hyvin isoille kartoille tai wipen loppupäähän 900 on järkevä. Kompromissi: jos palvelin kaatuu, menetät korkeintaan tuon verran sekunteja edistystä. Hyvin hostatulla raudalla kaatumisriski on lähellä nollaa, joten 600-900 on täysin riittävä. Me asetamme uusille Rust-palvelimille DoomHostingilla oletuksena 600 juuri tästä syystä.

Voit varmistaa, että tallennuspiikki on juuri sinun lagisi syy, seuraamalla palvelimen konsolia täsmälleen jäätymisen hetkellä. Jos näet [Server] Saving complete heti jäätymisen jälkeen, syyllinen löytyi.

Syy 3: entityjen kasautuminen wipen aikana

Rust-tukikohta deployableineen

Rust spawnaa ja seuraa jokaista ovea, jokaista säilytyslaatikkoa, jokaista koodilukkoa, jokaista uunia, jokaista maahan pudotettua esinettä. Wipen viidenteen päivään mennessä 100 paikan palvelin jolla on 30 aktiivista tukikohtaa on usein ylittänyt 300 000 entityn rajan. Jokainen entity maksaa simulaatioaikaa joka tickillä.

Tarkista entitymääräsi:

server.entitiesPerPlayer
print(BaseNetworkable.serverEntities.Count)

Terveet haarukat:

  • Päivä 1: alle 50k entityä
  • Päivä 3: 100k-150k
  • Päivä 5+: 200k-300k on normaalia, 400k+ on se piste jossa näet loppuwipen lagin

Kesken wipen ei ole siistiä korjausta muuta kuin aggressiivisempi decay (nopeampi TC:ttömien tukikohtien purku) ja pudotettujen esineiden siivous:

decay.scale 1.5
decay.upkeep true

Oikea korjaus on wipe. Jos palvelimesi kuolee johdonmukaisesti päivän 7-10 kohdalla, lyhennä wipe-aikatauluasi. Useimmat menestyvät modded-palvelimet wipettävät viikoittain tai joka toinen viikko juuri tämän käyrän takia.

Syy 4: server.tickrate, fps.limit ja muut asetukset joita syytetään mutta joilla harvoin on väliä

On sinnikäs myytti, että server.tickraten laskeminen korjaa lagin. Ei korjaa. server.tickrate on clientin puolella ja säätää sitä, kuinka usein clientit lähettävät sijaintipäivityksiä palvelimelle. Sen laskeminen vähentää verkkoliikennettä mutta ei vapauta prosessoritehoa dedikoidulta palvelimeltasi.

Samoin fps.limit palvelimella ei anna sinulle lisää FPS:ää. Se rajaa yläreunan, jottei prosessorisyklejä kulu hukkaan. 256 on järkevä oletus. Matalampi arvo voi jopa aiheuttaa lagia, koska palvelimella on vähemmän varaa piikkeihin.

Näillä on merkitystä:

  • server.maxplayers asetettuna korkeammaksi kuin rautasi kestää. Vanilla 100 paikkaa vaatii vähintään 4 dedikoitua ydintä 4,5 GHz:n yli, moddattu 100 paikkaa vaatii 6+ ydintä ja vähintään 16 GB muistia.
  • Jaetulla prosessorilla ajaminen halpishostilla. Rust vihaa jaettuja ytimiä: yhden säikeen suorituskyky on kaikki kaikessa.
  • Palvelinprosessia ei ole kiinnitetty nopeaan ytimeen.

Jos olet hostilla joka käyttää Ryzen 9- tai i9-rautaa ja palvelimesi on silti alle 60 server.fps:n alle 50 pelaajalla, pullonkaula on ohjelmistossa (pluginit, entityt, tallennus) eikä raudassa.

Syy 5: päivityksen jälkeinen lagi ("laggaa päivityksen jälkeen" -tapaus)

Lähes joka isompi Facepunchin patchi tuo mukanaan tilapäisen suorituskykyregression jonnekin, yleensä uuteen entity-tyyppiin tai uudelleenkirjoitettuun järjestelmään. Kaava vuonna 2026:

  1. Patchi tulee torstaina ja pakottaa wipen
  2. Pelaajat raportoivat nykimistä 3-4 päivää
  3. Modien tekijät työntävät yhteensopivuuspäivitykset viikonlopun aikana
  4. Patchia seuraavana tiistaina tai keskiviikkona tilanne vakautuu

Jos lagisi alkoi heti Facepunchin päivityksen jälkeen etkä ole koskenut plugineihin, syy on melkein varmasti vanhentunut plugin, jota ei ole päivitetty uudelle rajapinnalle. Tarkista jokaisen pluginisi sivu Oxidessa ja uModissa ja poista tai kytke pois kaikki, mitä ei ole päivitetty patchin jälkeen. Virheloki (server.log) osoittaa yleensä syyllistä NullReferenceException-pinojäljillä.

Diagnostiikkalista (liitä tämä konsoliisi)

Kun pelaaja raportoi lagia, aja nämä järjestyksessä Pterodactylin konsolissa:

server.fps
print(BaseNetworkable.serverEntities.Count)
oxide.plugins
gc.collect
server.fps

Vertaa ensimmäistä server.fps-arvoa arvoon gc.collectin jälkeen. Jos se hyppäsi 20:llä tai enemmän, pluginien roskienkeruu on pullonkaulasi ja sinun pitää auditoida pluginit. Jos se ei liikkunut, pullonkaulasi on entityissä (syy 3) tai raudassa (syy 4).

Proseduraalista Rust-maastoa

Mitä me viritämme oletuksena Rust-palvelimillamme

Vertailun vuoksi, tässä mitä jokainen tuore Rust-asennus DoomHostingilla saa suoraan paketista:

  • server.saveinterval 600
  • fps.limit 256
  • decay.scale 1.0 (palvelinkohtaisesti säädettävissä)
  • Pterodactylin resurssirajat mitoitettuna niin, että Rust-prosessilla on aina omaa prosessorivaraa
  • Palvelinprosessi Ryzen 9 -raudalla, jonka yhden säikeen boost on yli 5,0 GHz. Rust on yhden säikeen rajoittama, joten korkea kellotaajuus voittaa ydinmäärän joka kerta.
  • Automaattiset yölliset varmuuskopiot, jotta voit kasvattaa saveintervalia pelkäämättä

Toimitamme myös vain ne pluginit jotka itse asennat, ei esiladattua turhaketta. Suurin osa kilpailijoilta siirtyvien lagitiketeistä johtuu edelliseltä hostilta jääneistä plugineista.

Laggaako vieläkin?

Käy syyt uudelleen järjestyksessä: pluginien roskienkeruu (gc.collect-testi), sitten tallennusväli, sitten entityt, sitten rauta. Järjestyksellä on väliä, koska jokainen syy on suunnilleen viisi kertaa edellistä kalliimpi korjata. Jos olet tehnyt kaikki neljä ja server.fps on yhä alle 60 alle 50 pelaajalla, tarvitset lähes varmasti joko paremman raudan tai tuoreen wipen.

Hostaa Rust-palvelimesi DoomHostingilla

Jos olet kyllästynyt debuggaamaan tickratea hostilla jolla on jaetut prosessorit, meidän Rust-palvelimemme pyörivät dedikoiduilla Ryzen 9 -ytimillä ja yllä oleva viritys on jo valmiina. Pystytä Rust-palvelin DoomHostingilla, aseta wipe-aikataulusi ja anna meidän hoitaa loput. Välitön käyttöönotto, täysi FTP-yhteys Oxide-plugineillesi ja 24/7-tuki joka oikeasti pelaa peliä.

Rust

Hanki oma Rust -palvelin

Vuokraa pelipalvelin DoomHostingilta. Välitön käyttöönotto, 24/7 tuki ja 99,99 % käytettävyystakuu.

Aiheeseen liittyvät kirjoitukset