Wydajność serwera gry: które parametry naprawdę się liczą

Par Benjamin D. · PDG

13 września 2026 · Mis à jour le 13 września 2026 · Lecture 9 min

Spis treści

Wydajność serwera gry rzadko zależy od jednej liczby w specyfikacji — decyduje o niej kombinacja taktowania jednordzeniowego, ilości pamięci RAM, szybkości dysku NVMe i jakości łącza z filtracją ruchu. Poniżej rozkładam te parametry na czynniki pierwsze i pokazuję, jak dopasować je do konkretnego tytułu, od Minecrafta po ARK-a i Rusta.

Wydajność serwera gry zaczyna się od taktowania jednordzeniowego

Silniki większości gier sieciowych opierają się na jednej głównej pętli symulacji — tzw. main thread. To w niej liczone są ruchy postaci, fizyka, AI mobów, rozrost roślin, zapisy stanu świata. Wątki poboczne (sieć, kompresja, zapis na dysk) można rozproszyć, ale sama pętla logiki jest sekwencyjna. Efekt jest prosty: procesor z 32 wątkami i niskim zegarem wypadnie gorzej niż 8 szybkich rdzeni o wysokim taktowaniu.

Budżet czasu na tick

Serwer Minecrafta pracuje w 20 tickach na sekundę, co daje 50 ms na wykonanie całej logiki. Jeśli przetworzenie ticku zajmie 70 ms, TPS spada do ~14 i gra zaczyna „gumkować": moby teleportują się, bloki wracają na miejsce, uderzenia nie rejestrują się poprawnie. W Ruście analogiczną rolę pełni server.fps, w ARK-u — wewnętrzny tick symulacji dinozaurów i struktur, a we FiveM — wątek skryptowy odpowiadający za resource'y.

Diagnostyka wygląda podobnie w każdym tytule: mierzysz czas ticku, a nie „obciążenie CPU w procentach". Procesor może pokazywać 25% wykorzystania, gdy jeden rdzeń jest zapchany w 100% — i to właśnie on wyznacza płynność.

# Minecraft (Paper/Purpur) – konsola serwera
tps
spark profiler --timeout 60

# Rust – konsola RCON
server.fps
global.status

# Linux – który wątek pali rdzeń
top -H -p $(pgrep -f java | head -n1)

Dlaczego liczba rdzeni też ma znaczenie

Wysoki zegar rozwiązuje problem głównej pętli, ale nie wszystkiego. Java potrzebuje wątków na garbage collector, Paper przenosi generowanie chunków i kompresję pakietów w tło, ARK i Palworld intensywnie korzystają z osobnych wątków I/O. Praktyczna reguła: 2–4 szybkie rdzenie na jedną instancję gry to sensowny punkt wyjścia, a przy klastrze map ARK-a lub kilku modpackach — odpowiednio więcej.

Jeśli szukasz maszyny pod konkretny tytuł i chcesz porównać konfiguracje sprzętowe pod kątem Ryzenów o wysokim taktowaniu i dysków NVMe, sprawdź stronę hosting Minecraft — a pełną listę obsługiwanych gier znajdziesz w sekcji Wszystkie nasze serwery gier.

RAM: ile faktycznie potrzebujesz i dlaczego „więcej" bywa gorsze

Pamięć jest drugim po zegarze parametrem, który realnie odczujesz w grze. Jej brak nie objawia się jednak spadkiem FPS-ów, tylko charakterystycznymi zacięciami co kilkadziesiąt sekund — to moment, w którym system zaczyna zwalniać pamięć albo maszyna wirtualna Javy wykonuje długą pauzę GC.

Java i pułapka zbyt dużej sterty

W Minecrafcie przydzielenie 16 GB sterty serwerowi obsługującemu 10 graczy nie poprawi niczego — wręcz przeciwnie. Im większa sterta, tym dłużej trwa pełne czyszczenie pamięci, a każda taka pauza to zamrożony tick. Rozsądniej ustawić -Xms równe -Xmx (brak dynamicznego rozrostu) i dobrać rozmiar do liczby graczy oraz modów.

java -Xms6G -Xmx6G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 \
  -jar paper.jar nogui

Te flagi (bazujące na znanym zestawie Aikara) skracają pauzy GC kosztem nieco częstszych, ale krótszych cykli. W panelu Pterodactyl ustawisz je w zmiennych startowych instancji, bez dotykania plików przez FTP.

Gry natywne: RAM rośnie z rozmiarem świata

W tytułach bez maszyny wirtualnej — ARK, Rust, Palworld, Valheim, 7 Days To Die — zużycie pamięci rośnie liniowo wraz z liczbą zapisanych obiektów: budowli, skrzyń, oswojonych stworzeń, przedmiotów na ziemi. Serwer Rusta z mapą 4500 po trzech tygodniach wipe'a potrafi zająć dwukrotnie więcej pamięci niż w dniu startu. Dlatego zapas RAM planuje się nie na dzień pierwszy, a na koniec sezonu.

Gra	Krytyczny parametr	Typowy pułap RAM	Uwagi
Minecraft (vanilla / Paper)	Zegar 1-rdzeniowy	4–8 GB	Modpacki: 8–12 GB, ostrożnie ze stertą
Rust	Zegar + RAM	10–16 GB	Zależne od rozmiaru mapy i wieku wipe'a
ARK: Survival Ascended	Zegar + RAM + NVMe	12–20 GB	Klaster map mnoży zapotrzebowanie
Palworld	Zegar 1-rdzeniowy	8–16 GB	Pale w bazach mocno obciążają tick
Valheim	Zegar + I/O zapisu	4–8 GB	Duże bazy = długie zapisy świata
Project Zomboid	I/O + RAM	6–12 GB	Streaming komórek mapy z dysku
FiveM	Zegar 1-rdzeniowy	6–16 GB	Liczy się jakość skryptów, nie ich liczba

Dysk NVMe, zapisy świata i mikro-przycięcia

To parametr najczęściej pomijany, a odpowiadający za najbardziej irytujący objaw: regularne zacięcie co kilka minut, dokładnie w rytmie autozapisu. Serwer gry musi cyklicznie zrzucić stan świata na dysk. Na nośniku o wysokiej latencji ten zrzut blokuje główną pętlę na setki milisekund.

Co realnie robi NVMe

Zapis świata — Minecraft zapisuje regiony, Valheim cały plik .db, ARK pliki .ark ważące setki MB. Różnica między dyskiem talerzowym a NVMe to przejście z sekund na ułamki sekundy.
Generowanie terenu — wejście gracza w niezbadany obszar wymusza zapis nowych chunków; przy wolnym I/O każdy nowy rejon to lag spike.
Start instancji — modpack z 250 modami wczytuje tysiące małych plików. IOPS liczy się tu bardziej niż transfer sekwencyjny.
Kopie zapasowe — automatyczne backupy wykonywane w tle nie mogą walczyć o dysk z pętlą gry.

Jak zmierzyć wąskie gardło dysku

# instalacja narzędzi diagnostycznych
apt update && apt install -y sysstat

# obserwacja opóźnień i kolejki I/O
iostat -x 2 5

# kto generuje ruch na dysku
iotop -oPa

Kolumna await powyżej kilkunastu milisekund przy jednoczesnych zacięciach w grze to jasny sygnał, że problemem jest magazyn danych, a nie procesor.

Strojenie częstotliwości zapisu

Nawet na szybkim nośniku warto rozłożyć zapisy w czasie. W Paperze steruje tym paper-world-defaults.yml, w Valheimie parametr uruchomieniowy, w ARK-u AutoSavePeriodMinutes.

# Paper – spread zapisów, mniej skokowe obciążenie
chunk-saving:
  max-auto-save-chunks-per-tick: 8

# ARK – GameUserSettings.ini
[ServerSettings]
AutoSavePeriodMinutes=15

# Valheim – parametr startowy
./valheim_server.x86_64 -name "Serwer" -world "Dedicated" -savedir /data/saves

Sieć, latencja i ochrona anty-DDoS

Można mieć idealny tick i zerowe I/O wait, a gracze i tak będą narzekać na „lagi". Wtedy winowajcą jest warstwa sieciowa. Tu liczą się trzy rzeczy: opóźnienie (RTT), stabilność (jitter, utrata pakietów) i odporność na ataki wolumetryczne.

Opóźnienie to geografia, nie sprzęt

Żaden procesor nie skróci drogi pakietu. Jeśli twoja społeczność gra głównie z Polski i Europy Środkowej, maszyna w zachodniej Europie da zwykle 20–40 ms RTT — wartość całkowicie akceptowalna dla survivali i sandboxów. Dla shooterów i trybów PvP w Ruście czy Arma 3 każde 30 ms w górę zmienia odczucie rejestracji trafień.

# stabilna trasa czy pakiety gubią się po drodze?
mtr -rwc 100 ip.twojego.serwera

# szybki test opóźnienia i jittera
ping -c 50 ip.twojego.serwera

Interpretacja: stały RTT z odchyleniem kilku ms = zdrowe łącze. Skoki o 100 ms i utrata pakietów na przedostatnim hopie = problem po stronie trasy lub przeciążenia węzła.

Filtracja ruchu jako element wydajności

Atak wolumetryczny nie „wyłącza" serwera — zwykle zalewa łącze śmieciowymi pakietami, przez co prawdziwe pakiety graczy czekają w kolejce. Objaw to nagły skok opóźnień i masowe rozłączenia, mimo że TPS na konsoli wygląda normalnie. Dlatego filtracja anty-DDoS na poziomie infrastruktury — włączona domyślnie na maszynach Fly-Serv — jest parametrem technicznym tak samo istotnym jak taktowanie rdzenia.

Higiena po twojej stronie

Silne, unikalne hasło RCON — nigdy domyślne, nigdy współdzielone z panelem.
Port RCON niedostępny publicznie; zarządzaj przez konsolę panelu, nie przez otwarty port.
Whitelist lub tryb zamknięty na czas testów nowego modpacka.
Kopie zapasowe automatyczne plus jedna kopia pobrana lokalnie przed każdą większą aktualizacją.
Subużytkownicy w panelu z ograniczonymi uprawnieniami zamiast dzielenia się głównym loginem.
Jeśli administrujesz maszyną samodzielnie: klucze SSH zamiast haseł, fail2ban i ufw z domyślną polityką DROP.

ssh-keygen -t ed25519 -C "admin-gameserver"
ufw default deny incoming
ufw allow 22/tcp
ufw allow 25565/tcp
ufw enable
systemctl enable --now fail2ban

Dopasowanie parametrów do konkretnego tytułu

Uniwersalna konfiguracja nie istnieje. Poniżej praktyczne wskazówki dla najczęściej uruchamianych gier.

Minecraft i modpacki

Dominuje zegar jednordzeniowy. Paper i Purpur dają duży zysk względem vanilli dzięki optymalizacji przetwarzania encji i chunków. Ogranicz view-distance do 8 i simulation-distance do 6 — to zwykle najszybszy sposób odzyskania kilku TPS. Modpacki typu „kitchen sink" wymagają więcej RAM, ale nadal to zegar decyduje o płynności. Szczegóły implementacyjne znajdziesz w oficjalnych materiałach Mojang.

ARK i Rust

Oba tytuły łączą wysokie zapotrzebowanie na RAM z wrażliwością na I/O. W ARK-u kluczowe są limity struktur i oswojonych stworzeń na kafelek — nieograniczone bazy graczy degradują tick szybciej niż liczba połączonych osób. Konfiguracje dla obu gier znajdziesz na stronach Serwer ARK Survival Ascended i Serwer Rust.

Palworld, Valheim, Enshrouded

Survivale kooperacyjne rzadko przekraczają kilkanaście slotów, ale ich symulacja bazy jest kosztowna: Pale pracujące przy stacjach, portale i sieć budowli w Valheimie, pełne odwzorowanie terenu w Enshrouded. Tu również liczy się zegar, a NVMe skraca zapisy dużych światów do niezauważalnego minimum. Zobacz Serwer Palworld oraz Serwer Valheim.

FiveM i RedM

W tych platformach wydajność jest głównie kwestią jakości skryptów. Jeden źle napisany resource z pętlą Citizen.Wait(0) obciąża wątek serwera bardziej niż dwudziestu dodatkowych graczy. Profiluj przed rozbudową sprzętu:

# konsola FiveM
resmon 1
profiler record 500
profiler view

Kolejność diagnozowania spadków wydajności

Zmierz tick/TPS i sprawdź, czy problem jest po stronie logiki gry.
Sprawdź obciążenie pojedynczego rdzenia, nie średnią CPU.
Zweryfikuj pauzy GC (Java) lub zużycie RAM względem limitu.
Zbadaj await i kolejkę I/O podczas autozapisu.
Na końcu testuj sieć: mtr, jitter, utrata pakietów.

Ta kolejność oszczędza czas: w praktyce ponad połowa zgłoszeń „serwer laguje" kończy się na punkcie pierwszym lub drugim. Więcej praktycznych poradników administracyjnych publikujemy na Blog Fly-Serv.

Podsumowanie

Płynność rozgrywki wynika z czterech powiązanych elementów: szybkiego rdzenia dla głównej pętli, wystarczającej pamięci bez przesady, nośnika NVMe redukującego zacięcia przy zapisach i stabilnego łącza z filtracją ruchu. Zanim dorzucisz zasoby, zmierz czas ticku i opóźnienia dyskowe — dane z konsoli i iostat wskażą wąskie gardło znacznie szybciej niż zgadywanie.

FAQ

Dlaczego mój serwer Minecraft ma niski TPS mimo 16 GB RAM?

Pamięć rzadko jest przyczyną spadków TPS. Główna pętla jest jednowątkowa, więc wąskim gardłem jest zwykle taktowanie rdzenia lub zbyt duża sterta powodująca długie pauzy GC. Ustaw -Xms równe -Xmx na 6–8 GB, zastosuj flagi G1GC, zmniejsz view-distance i uruchom spark profiler, by wskazać konkretny plugin lub mod obciążający tick.

Jak rozpoznać, że zacięcia w grze powoduje dysk, a nie procesor?

Charakterystyczny objaw to zacięcie powtarzające się regularnie, w rytmie autozapisu. Uruchom iostat -x 2 5 podczas gry: wartość await powyżej kilkunastu milisekund i wysoka kolejka operacji potwierdzają problem z nośnikiem. Rozwiązaniem jest magazyn NVMe, rozłożenie zapisów w czasie oraz przesunięcie kopii zapasowych poza godziny szczytu.

Czy ochrona anty-DDoS wpływa na opóźnienia w grze?

Poprawnie wdrożona filtracja działa na brzegu sieci i w normalnych warunkach nie dokłada zauważalnego opóźnienia. Realny wzrost RTT pojawia się dopiero bez takiej ochrony, gdy śmieciowy ruch zapycha łącze i pakiety graczy czekają w kolejce. Trasę i jitter sprawdzisz poleceniem mtr -rwc 100 z maszyny gracza.