Parametry serwera gry: co naprawde wpływa na płynność rozgrywki

Par Benjamin D. · PDG

14 września 2026 · Mis à jour le 14 września 2026 · Lecture 8 min

Spis treści

Parametry serwera gry decydują o tym, czy rozgrywka jest płynna, czy gracze co chwilę widzą gumowanie postaci, opóźnione trafienia i zawieszone chunki. Taktowanie pojedynczego rdzenia, ilość pamięci dopasowana do silnika, dysk NVMe oraz stabilny tick rate tworzą razem realne odczucie z gry. Poniżej rozkładam te elementy na części i pokazuję, jak je dobrać do konkretnego tytułu i liczby graczy.

Parametry serwera gry: taktowanie jednego rdzenia ważniejsze niż liczba wątków

Większość silników gier wieloosobowych opiera się na pojedynczej pętli symulacji. Wszystko, co dzieje się w świecie — ruch NPC, fizyka, aktualizacja bloków, sprawdzanie kolizji, logika modów — jest liczone w jednym wątku, tick po ticku. Dodatkowe rdzenie obsługują zadania poboczne: kompresję pakietów, generowanie terenu w tle, zapisy dysku, wątki sieciowe. Dlatego maszyna z dwudziestoma wolnymi rdzeniami wypadnie gorzej niż cztery rdzenie o wysokim taktowaniu.

Budżet czasu na jeden tick

Minecraft pracuje domyślnie w 20 ticków na sekundę, co daje 50 ms na obliczenie pełnego stanu świata. Jeśli pętla nie zmieści się w tym oknie, TPS spada i czas w grze zaczyna płynąć wolniej: piece wytapiają dłużej, moby stoją, a gracz „cofa się” po skoku. Rust, ARK czy Valheim działają na innych wartościach, ale zasada jest identyczna — przekroczony budżet ticka to natychmiastowy spadek komfortu.

Silnik / gra	Typowy tick	Budżet na tick	Wrażliwość na taktowanie
Minecraft (Paper, Fabric)	20 TPS	50 ms	Bardzo wysoka
Rust	10–30 tick	33–100 ms	Wysoka
ARK: Survival Evolved / Ascended	~30 tick	~33 ms	Bardzo wysoka
FiveM (OneSync)	zmienny	zależny od resources	Wysoka
Valheim	~30 tick	~33 ms	Średnia–wysoka
Project Zomboid	zmienny	zależny od liczby zombie	Wysoka

Rdzeń współdzielony a rdzeń z gwarancją mocy

Druga kwestia to sposób przydziału CPU. Jeśli kilkanaście instancji walczy o te same rdzenie, w godzinach szczytu tick wydłuża się nie z powodu twojej konfiguracji, lecz z powodu sąsiada, który właśnie generuje mapę. Procesory Ryzen o wysokim taktowaniu bazowym w połączeniu z rozsądnym zagęszczeniem instancji to podstawa przewidywalnego TPS. Na maszynie o niskim zegarze żadna optymalizacja pluginów nie nadrobi straty.

Jeśli interesuje Cię gotowa konfiguracja pod ten konkretny tytuł, szczegóły techniczne znajdziesz na stronie hosting Minecraft, gdzie opisane są dostępne zasoby i sposób instalacji. Pełną listę obsługiwanych tytułów zebraliśmy w dziale Wszystkie nasze serwery gier.

RAM: ile naprawdę potrzebuje silnik, a ile jego modyfikacje

Pamięć to parametr najczęściej przeszacowywany i jednocześnie najgorzej dobierany. Liczba graczy wpływa na zużycie RAM w sposób umiarkowany. Prawdziwym konsumentem są: rozmiar świata, liczba załadowanych chunków lub komórek, liczba modów oraz mechanika zapisywania stanu.

Orientacyjne zapotrzebowanie według tytułu

Gra	Konfiguracja	Sensowny przydział RAM
Minecraft Vanilla / Paper	10–20 graczy	4 GB
Minecraft modpack (100+ modów)	10–20 graczy	8–12 GB
Rust	worldsize 3500, 100 graczy	10–16 GB
ARK: Survival Evolved	1 mapa, 30 graczy	8–12 GB
ARK: Survival Ascended	1 mapa	16 GB i więcej
Palworld	16–32 graczy	16 GB
Valheim	10 graczy, rozbudowane bazy	4–8 GB
Project Zomboid	16 graczy, duża mapa	6–8 GB
7 Days to Die	Navezgane / RWG 8k	8–12 GB
Enshrouded	16 graczy	12–16 GB

Java: dlaczego więcej pamięci potrafi zaszkodzić

W tytułach opartych o Javę przydział pamięci przekłada się bezpośrednio na pracę garbage collectora. Przydzielenie 24 GB instancji, która realnie używa 5 GB, wydłuża pauzy GC i objawia się regularnymi mikro-zacięciami co kilkadziesiąt sekund. Zdrowa praktyka to ustawienie -Xms równe -Xmx oraz świadome flagi G1GC:

java -Xms8G -Xmx8G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -jar paper.jar nogui

Pamiętaj też o narzucie poza stertą: metaspace, bufory sieciowe i biblioteki natywne potrafią dołożyć 1–2 GB ponad wartość -Xmx. Jeśli instancja ma limit 8 GB, ustaw stertę na 6 GB.

Silniki natywne i wycieki pamięci

W grach na Unreal Engine (ARK, Palworld, Satisfactory) zużycie rośnie w czasie działania procesu. To nie zawsze błąd konfiguracji, tylko charakterystyka silnika. Rozwiązanie jest proste i skuteczne: zaplanowany restart w oknie niskiej aktywności, wykonany z panelu wraz z wcześniejszym zapisem świata. Przy modowanym ARK czy dużym świecie Palworld codzienny restart nad ranem eliminuje większość skarg na spadki płynności — więcej kontekstu do tych tytułów znajdziesz przy opisie Serwer Palworld oraz Serwer ARK Survival Ascended.

Dysk NVMe, operacje I/O i zapisy świata

Dysk to parametr, o którym przypomina sobie dopiero administrator, którego świat waży 12 GB. Symulacja świata regularnie zrzuca stan na nośnik: regiony Minecrafta, pliki .ark, mapy Rust, bazy SQLite Project Zomboid. Na klasycznym dysku talerzowym taki zapis potrafi zablokować główny wątek na kilka sekund — gracze odczują to jako całkowite zamrożenie świata.

Gdzie NVMe robi różnicę

Start instancji — wczytanie modpacka z 200 modami to tysiące drobnych odczytów; różnica między NVMe a HDD to minuty, nie sekundy.
Generowanie terenu — eksploracja nowych obszarów oznacza jednoczesny zapis i odczyt chunków.
Autosave — im krótsze okno zapisu, tym mniejszy widoczny lag spike.
Kopie zapasowe — archiwizacja dużego świata przy wolnym I/O sama staje się źródłem spadków TPS.

Dostrojenie interwałów zapisu

Zbyt częsty autosave to niepotrzebne zacięcia, zbyt rzadki to ryzyko utraty postępu. Przykład dla Rusta uruchamianego z parametrami startowymi:

./RustDedicated -batchmode \
  +server.tickrate 30 \
  +server.maxplayers 150 \
  +server.worldsize 3500 \
  +server.saveinterval 600 \
  +server.secure true

W Palworld analogiczne ustawienia znajdziesz w pliku konfiguracyjnym:

[/Script/Pal.PalGameWorldSettings]
OptionSettings=(
  ServerPlayerMaxNum=32,
  AutoSaveSpan=600.000000,
  bIsMultiplayer=True,
  RCONEnabled=True,
  RCONPort=25575
)

Dobra zasada: interwał zapisu od 5 do 10 minut przy dużych światach, krótszy tylko wtedy, gdy testowo potwierdziłeś, że pojedynczy zapis trwa poniżej sekundy. Regularne kopie zapasowe wykonywane automatycznie zdejmują z tego decyzji sporo presji, bo nawet awaryjny restart nie kosztuje wtedy całej sesji społeczności.

TPS, opóźnienie sieci i ochrona anty-DDoS jako parametry serwera gry

Gracz nie widzi zegara procesora. Widzi trzy rzeczy: czy trafienie zostało zarejestrowane, czy postać nie cofa się po biegu i czy sesja nie urywa się w środku rajdu. Za te wrażenia odpowiadają trzy różne parametry serwera gry, które łatwo ze sobą pomylić.

TPS, FPS i ping to trzy osobne wartości

TPS / tick rate — jak często maszyna przelicza świat. Spadek oznacza spowolnienie symulacji dla wszystkich.
Ping / RTT — czas podróży pakietu. Zależy od trasy sieciowej i lokalizacji datacenter, nie od mocy CPU.
FPS klienta — wydajność komputera gracza. Wysoki tick niczego tu nie naprawi.

Zanim zaczniesz zmieniać konfigurację, zmierz. W Paper i Purpur podstawowa diagnostyka zajmuje kilkanaście sekund:

/tps
/mspt
/spark profiler start --timeout 120
/spark profiler stop

Wartość mspt poniżej 30 ms daje zapas bezpieczeństwa. Powyżej 45 ms jesteś na granicy i każdy nowy gracz albo farma redstone zepchnie TPS poniżej 20. Profiler pokaże, czy winna jest konkretna wtyczka, entity ticking czy generowanie chunków — to oszczędza godziny zgadywania.

Ograniczanie obciążenia po stronie konfiguracji

Zanim sięgniesz po mocniejszą maszynę, sprawdź ustawienia świata. W spigot.yml i paper-world-defaults.yml najwięcej daje ograniczenie zasięgu symulacji i limitów entity:

view-distance: 8
simulation-distance: 5
entity-activation-range:
  animals: 16
  monsters: 24
  misc: 8
chunks:
  max-auto-save-chunks-per-tick: 6

Zmniejszenie simulation-distance z 10 do 5 potrafi zdjąć z pętli głównej ogromną liczbę obliczeń, praktycznie niezauważalnie dla graczy. Analogiczne dźwignie istnieją w innych tytułach: limity zombie w Project Zomboid, zagęszczenie dinozaurów w ARK, liczba aktywnych resources w FiveM. Zasada jest stała — najpierw ogranicz to, co silnik liczy w każdym ticku.

Ochrona przed atakami wolumetrycznymi

Nasycone łącze to stan, w którym wszystkie inne parametry przestają mieć znaczenie: CPU jest bezczynne, a nikt nie może się połączyć. Filtrowanie ruchu na poziomie infrastruktury działa u nas domyślnie na każdej instancji, więc typowy atak wolumetryczny wygasa, zanim dotrze do portu gry. Po twojej stronie zostają praktyki higieniczne:

silne, unikalne hasło RCON i zmiana domyślnego portu zarządzania;
whitelist na etapie budowy społeczności lub w trakcie testów modów;
aktualizacje silnika i wtyczek — wiele exploitów crashujących instancję to załatane błędy;
automatyczne kopie zapasowe trzymane poza żywym światem;
konta podrzędne w panelu dla moderatorów, zamiast dzielenia jednego dostępu administracyjnego.

Szybka checklista doboru parametrów

Ustal silnik i jego wrażliwość na taktowanie jednego rdzenia.
Policz RAM od strony modów i rozmiaru świata, nie od liczby slotów.
Zostaw 20–25% zapasu pamięci ponad wartość szczytową z pomiarów.
Zmierz mspt przy pełnym obłożeniu, nie o trzeciej w nocy.
Dostrój zasięgi symulacji i interwały zapisu, zanim zwiększysz zasoby.
Ustaw restart dobowy dla silników z rosnącym zużyciem pamięci.

Praktyczna dokumentacja panelu, w tym limity zasobów i harmonogramy zadań, jest opisana w oficjalnej dokumentacji Pterodactyl. Konkretne notatki dla poszczególnych tytułów publikujemy na bieżąco na Blog Fly-Serv, a specyfikę survivali opisaliśmy przy okazji tekstów o Serwer Valheim i Serwer Rust.

Parametry serwera gry działają jak łańcuch: najsłabsze ogniwo wyznacza wynik. Wysoki zegar bez NVMe da zacinający się autosave, dużo RAM przy słabym rdzeniu nie podniesie TPS, a perfekcyjna konfiguracja bez filtrowania ruchu padnie przy pierwszym ataku.

Podsumowanie

Płynność rozgrywki wynika z kilku powiązanych elementów: taktowania rdzenia liczącego pętlę świata, pamięci dopasowanej do silnika i modów, szybkiego nośnika NVMe oraz stabilnego tick rate pod obciążeniem. Zacznij od pomiaru, potem dostrój zasięgi symulacji i interwały zapisu, a dopiero na końcu zwiększaj zasoby. Takie podejście daje przewidywalne wyniki i mniej zgłoszeń od graczy.

FAQ

Dlaczego TPS spada, mimo że procesor nie jest obciążony w 100%?

Bo liczy się obciążenie jednego wątku, a nie średnia ze wszystkich rdzeni. Pętla symulacji świata działa w pojedynczym wątku: jeśli on jest wysycony, TPS spada, podczas gdy zbiorcze użycie CPU pokazuje 20–30%. Sprawdź /mspt lub profiler i szukaj pojedynczej wtyczki, farmy entity albo intensywnego generowania terenu.

Ile pamięci przydzielić instancji Minecraft z modpackiem?

Dla modpacka z około 150 modami i 10–20 graczami rozsądny punkt startowy to 8 GB sterty, przy limicie instancji 10 GB. Ustaw -Xms równe -Xmx, użyj G1GC i obserwuj wykres pamięci przez tydzień. Przydzielanie dwukrotnie większej sterty niż realne zużycie wydłuża pauzy GC i pogarsza płynność.

Czy zwiększenie tick rate w Rust poprawi celność strzałów?

Do pewnego momentu tak: wyższy tick rate oznacza częstszą aktualizację pozycji i lepszą rejestrację trafień. Powyżej 30 rośnie jednak obciążenie rdzenia i ruch sieciowy, więc przy dużym obłożeniu efekt bywa odwrotny. Ustaw 30, zmierz stabilność pod pełnym obciążeniem i dopiero wtedy rozważaj zmiany.