Processzor vagy RAM: mitől lesz gyors egy játékszerver?
A RAM dönti el, mennyit tud a szerver tartani, a processzor azt, milyen gyorsan tud gondolkodni. Miért az egymagos sebesség a legfontosabb, és mikor segítenek a plusz magok.
5 perc olvasás · Frissítve: 2026. okt. 21. · Szerző: GuavaHost Team
A RAM dönti el, mennyit tud a szervered tartani, a processzor pedig azt, milyen gyorsan tud gondolkodni. A legtöbb szerverlag, amit az emberek a memóriára fognak, valójában processzorprobléma, úgyhogy ez az útmutató elmagyarázza a különbséget, azt, hogy miért számít többet az egymagos sebesség, mint a magok száma, és hogyan derítsd ki, melyikből van kevesed.
Két különböző munka
- A RAM a kapacitás. Ez tartja a világot, a játékosokat és a modokat. Ha szűkében vagy, a szerver akadozik, miközben memóriát szabadít fel, vagy összeomlik.
- A processzor a sebesség. Ő végzi az igazi munkát: mozgatja a mobokat, futtatja az MI-t, a fizikát, a redstone-t, a crafting állomásokat és minden plugint. Ha szűkében vagy, a szerver lemarad, és ezt mindenki egyszerre érzi meg késésként és gumizásként.
Ha egy processzorban szűkölködő szerverhez RAM-ot adsz, az semmit nem ér, és egy gyors processzor sem menti meg azt a szervert, amelyiknek elfogyott a memóriája. Mindkettőből kell elég, de másként hibáznak.
A tickköltségvetés
Egy játékszerver ciklusban fut. A ciklus minden körét ticknek hívják, és a szerver minden tickben frissít mindent a világban. A játék másodpercenként egy adott számú ticket vár el, és ez minden ticknek időköltségvetést ad:
| Játék | Cél frekvencia | Idő egy tickre |
|---|---|---|
| Minecraft Java | 20 tick másodpercenként | 50 ms |
| Terraria | 60 frissítés másodpercenként | körülbelül 16,7 ms |
| Counter-Strike 2 | 64 tick másodpercenként | körülbelül 15,6 ms |
Ha egy tick hosszabb ideig tart a költségvetésénél, a szerver nem tud lépést tartani. A Minecraftban ez úgy jelenik meg, hogy a TPS (tick per másodperc) 20 alá esik, az MSPT (milliszekundum per tick) pedig 50 fölé kapaszkodik. A TPS és MSPT olvasása útmutatónk megmutatja, hogyan mérd.
Ebben a költségvetésben a RAM sehol nem jelenik meg. Hogy minden tick időben befejeződik-e, pusztán attól függ, mennyi a munka, és milyen gyorsan végez vele a processzor.
Miért számít legtöbbet az egymagos sebesség
A legtöbb játékszerver a lényegi szimulációját egyetlen fő szálon végzi. A szál egyetlen munkafolyam, amit egy processzormag futtatni tud, és egy játékvilágot nehéz több szál között szétosztani, mert minden lépés az előzőtől függ: egy mob nem tud elmozdulni, amíg a szerver nem tudja, hol lett vége annak a blokknak, amelyre rálép.
A Minecraft, a Rust, az ARK, a Valheim, a Project Zomboid és a Terraria is így működik. Így egyetlen mag sebessége szabja meg a plafont az egész szervernek. Egy 16 lassabb magos processzor rosszabbul futtathat egy Minecraft világot, mint egy 8 gyorsabb magos, mert a világ a fő munkájához mindig csak egyet használ belőlük.
Az egymagos sebesség két dologból jön:
- Órajel, GHz-ben mérve: a mag másodpercenként hány ciklust fut le.
- Ciklusonkénti munka, ami minden processzorgenerációval javul. Egy újabb processzor ugyanazon a GHz-en gyakran érezhetően gyorsabb a régebbinél.
A nagy processzorgyorsítótár (egy kis mennyiségű, nagyon gyors memória magán a chipen) is segít, mert a játékszerverek folyamatosan ugrálnak sok apró adatdarab között.
Mikor segítenek mégis a plusz magok
A plusz magok nem haszontalanok. Mindent átvesznek, ami nem a fő tick:
- Háttérmunka. A világ mentése, a chunkok betöltése és generálása (a Paperhez hasonló szerverszoftverek ennek egy részét leveszik a fő szálról), a hálózati adat tömörítése és azoknak a pluginfeladatoknak a futtatása, amelyeket háttérműködésre írtak.
- Java szemétgyűjtés. A Minecraft Java több szál segítségével takarítja ki a nem használt memóriát, így a szabad magok rövidre fogják ezeket a takarításokat.
- Egynél több folyamat. Egy Don't Starve Together szerver a felszínt és a barlangokat két külön folyamatként futtatja, egy ARK fürt minden térképe pedig önálló szerver. Mindegyik használhatja a saját magját.
- Frissítések és mentések. Egy játékfrissítés letöltése vagy egy mentés tömörítése a játék mellett történik, nem egy ticken belül.
Néhány újabb motor, köztük az ARK és a Palworld mögött álló Unreal Engine, a munkája nagyobb részét szétosztja a plusz szálak között. A tempót még ott is a fő játékszál szabja meg.
Melyikből van kevesed?
| Amit látsz | Valószínű ok |
|---|---|
| A memóriagrafikon a limitre szegezve | RAM |
| Out of memory hibák, vagy összeomlás betöltés közben | RAM |
| A memóriában van hely, de a TPS esik és az MSPT kapaszkodik | Processzor |
| Lag csak egy óriási farm, egy megabázis vagy sok lény közelében | Processzor |
| A lag órák alatt épül fel, és egy újraindítás megoldja | Gyakran memóriakúszás, néha entitásfelhalmozódás |
| Csak egy játékos laggol | Egyik sem: az az ő pingje |
Egy részletet érdemes tudni: a GuavaHost vezérlőpultjában lévő Usage kártya (az Overview és a Console fülön) a processzort a csomagodhoz méri. Amikor a csomagodnak van processzorkorlátja, az érték a csomag összes magjának arányát mutatja, például "of 2 cores" feliratozással, tehát a 100 százalék azt jelenti, hogy mindegyik dolgozik. Egy játék fő szála csak egy magot tud használni, így egy 2 magos csomagon az az 50 százalék körül ülő szerver, amelyik laggol, lehet, hogy kimaxolja a fő szálát, pedig maradt még kapacitás. Amikor a csomagodnak nincs processzorkorlátja, az érték egyetlen mag százaléka, tehát a 100 százalék körül ülő, mégis laggoló szerver ugyanaz a történet. Ez a klasszikus jele a fő szál szűk keresztmetszetének.
A processzorból adódó lag javítása
Itt a több RAM nem segít. Az segít, ha a fő szálnak kevesebb dolga van minden tickben:
- Először a szimulációs távolságot vedd lejjebb, aztán a látótávolságot. Lásd a látótávolságot és szimulációs távolságot.
- Fogd meg a mobfarmokat, és takarítsd el a földre esett tárgyakat és a túl sok entitást.
- Generáld le előre a világodat, hogy ne játék közben készüljön az új terep.
- Keresd meg a nehéz pluginokat vagy modokat egy profilerrel. A Minecraftban az ingyenes Spark plugin pontosan megnevezi, mi eszi az egyes tickeket.
- Ütemezz napi újraindítást, hogy kitisztuljanak a felhalmozódott entitások és a memória.
A laglista sorban végigvezet ezeken.
Hogyan alkalmazható ez a GuavaHostnál
Minden GuavaHost szerver AMD Ryzen és Intel processzorokon fut, amelyeket az erős egyszálas teljesítményükért válogattunk, mert erre támaszkodnak a játékszerverek, NVMe SSD tárolóval együtt. Amit te választasz, az a RAM, a játékodhoz és a csapatodhoz méretezve, és bármikor módosíthatod a vezérlőpulton a Manage plan (csomag kezelése) alatt, arányos elszámolással. Ha a szervereden van szabad memória, mégis küszködik, az hangolási feladat, és a RAM-útmutatónk elmagyarázza, miért nem fogja megoldani több memória vásárlása.
Még mindig elakadtál? Gyere be a Discordunkra a discord.gg/GuavaHost címen, és a csapat segít.
- cpu
- ram
- performance
- single-thread
- cores
- tick rate
- lag
Még mindig elakadtál? Csapatunk a nap 24 órájában online, és megválaszolja a kérdéseidet.