Cel optymalizacji serwera Minecraft: realne oczekiwania i punkty kontrolne
Administrator, który chce optymalizować serwer Minecraft na Bukkit/Spigot/Paper, musi najpierw ustawić właściwą poprzeczkę: nie istnieje coś takiego jak absolutny brak lagów, istnieje natomiast stabilne utrzymanie 20 TPS przy określonej liczbie graczy, pluginów i rozmiarze świata. Cały proces optymalizacji sprowadza się do eliminowania wąskich gardeł, pilnowania kilku kluczowych metryk i testowania zmian krok po kroku, zamiast losowego kopiowania „magicznych configów” z internetu.
Jak rozumieć wydajność serwera Minecraft: oczekiwania vs realne możliwości
TPS vs FPS – dwa światy, które gracze ciągle mylą
Gracze bardzo często wrzucają do jednego worka dwa różne zjawiska: FPS (klatki na sekundę po stronie klienta) i TPS (tiki na sekundę po stronie serwera). FPS zależy głównie od komputera gracza, jego karty graficznej, paczki shaderów i ustawień graficznych. TPS to zupełnie inna historia – mówi, ile razy na sekundę serwer jest w stanie przeliczyć świat, fizykę, AI mobów, mechaniki redstone i logikę pluginów.
Serwer Minecraft dąży do wartości 20 TPS. Jeśli spada do 15 TPS, każda sekunda gry zaczyna trwać 1,33 sekundy w świecie rzeczywistym. Przy 10 TPS gra płynie dwa razy wolniej, a gracze widzą opóźnione reakcje: wolniej biją się moby, później odświeżają się tablice wyników, teleporty mają wyraźne lagi. W praktyce to właśnie spadki TPS generują skargi „laguje”, nawet jeśli FPS u gracza jest stabilny.
Punkt kontrolny wygląda tak: zanim zaczniesz cokolwiek „optymalizować”, sprawdź, czy problem rzeczywiście dotyczy TPS, a nie słabego komputera konkretnego gracza. Jeśli konsola pokazuje stałe 20 TPS, a na serwerze narzeka jedna osoba – źródło problemu nie leży po stronie serwera.
Realny cel: stabilne 20 TPS, a nie mit „zero lagów”
Mit „zero lagów” prowadzi do niepotrzebnych frustracji i złych decyzji konfiguracyjnych. Sensowny cel to utrzymanie 19,5–20 TPS przez zdecydowaną większość czasu przy założonej liczbie graczy (np. 10, 30 lub 80), przy normalnym obciążeniu (farmy, redstone, eksploracja). Sporadyczne spadki do 17–18 TPS w krótkich pikach (np. teleport 20 graczy w jedno miejsce) są akceptowalne – ważne, żeby serwer szybko wracał do normy.
Jeżeli wymagasz 20 TPS przy 20 graczach, 100 pluginach, ogromnym świecie i hostingu z taniego VPS-a – oczekiwania nie są spójne z zasobami. Konfiguracja może dużo pomóc, ale nie „wyczaruje” mocy CPU ani lepszego dysku. Wydajność to zawsze kompromis: albo więcej graczy i mniejszy „bajer”, albo mniej graczy i cięższe pluginy/masywne farmy.
Jeśli serwer utrzymuje 20 TPS przy obecnym obciążeniu, a gracze mimo wszystko narzekają, przyjrzyj się pingom, trasom sieciowym i jakości hostingu. TPS to punkt kontrolny numer jeden, ale nie jedyny wskaźnik jakości.
Główne źródła problemów z wydajnością – gdzie szukać winnych
Najczęstsze wąskie gardła serwera Minecraft na Bukkit/Spigot/Paper to:
CPU – zbyt słaby pojedynczy rdzeń, za niska częstotliwość, stara generacja, przepalony tani VPS dzielony z innymi klientami;
RAM – za mało pamięci dla JVM lub zbyt duży przydział pamięci na słabej maszynie (masz wrażenie, że „laguje od RAM-u”, a problemem jest garbage collector);
Dysk – brak SSD/NVMe, przeciążony storage na tanim hostingu, długie czasy zapisu chunków i logów;
Sieć – wysoki ping, gubione pakiety, przeciążone łącze, słaby routing między graczem a serwerem;
Pluginy – źle napisane lub nieaktualne, uruchamianie ciężkich zadań synchronicznie w głównym wątku serwera;
Świat – agresywne generowanie nowych chunków, ogromna liczba encji (moby, itemy), niekontrolowane farmy i mechanizmy redstone.
Jeżeli serwer ma słabe TPS już przy 5–10 graczach na PaperMC z sensowną konfiguracją, sygnałem ostrzegawczym jest przede wszystkim podejrzenie słabego CPU lub dysku. Jeżeli problemy pojawiają się dopiero przy eksploracji nowych terenów, pod lupę trzeba wziąć generowanie chunków, konfigurację view-distance oraz pluginy związane ze światami.
Rodzaje serwerów – inny poziom wymagań i optymalizacji
Inaczej planuje się optymalizację serwera dla kilku znajomych, a inaczej dla kilkudziesięciu obcych graczy. Trzy proste profile:
Serwer prywatny dla znajomych (2–10 graczy) – nacisk na wygodę, proste backupy, kilka popularnych pluginów (EssentialsX, WorldEdit, anty-grief), niewielkie wymagania sprzętowe, ale nadal obowiązuje dysk SSD i sensowna konfiguracja JVM.
Serwer pół-publiczny (10–40 graczy) – większe wymagania: mocniejsze CPU, przemyślany dobór pluginów, aktywne monitorowanie TPS i mspt, kontrola nad farmami i generacją świata.
Serwer dla większej społeczności (powyżej 40–60 graczy) – mocne, stabilne maszyny, często dedykowane, rygorystyczna polityka pluginów, podział na wiele serwerów (BungeeCord/Velocity), testowe instancje i procedury migracji.
Jeżeli planujesz przejście z profilu „serwer dla znajomych” na serwer pół-publiczny, punkt kontrolny to ocena obecnej stabilności: stałe 20 TPS przy pełnej liczbie znajomych to minimum do rozważenia „otwarcia się” na większą liczbę graczy.
Minimalny zestaw metryk: bez nich nie ma kontroli
Aby sensownie optymalizować serwer Minecraft, trzeba stale znać kilka liczb. Minimum to:
TPS – ogólny wskaźnik płynności serwera;
MSPT (milliseconds per tick) – ile milisekund zajmuje serwerowi pojedynczy tik (przy 20 TPS powinno to być poniżej 50 ms);
Zużycie RAM – w ujęciu realnym, nie tylko przydzielonym (monitoring procesu Java, nie samego systemu);
Obciążenie CPU – najlepiej dla pojedynczego rdzenia, bo to on zwykle jest wąskim gardłem;
Obciążenie dysku – czasy zapisu, kolejki I/O na hostingu/VPS.
Jeśli nie wiesz, ile masz aktualnie TPS, mspt i jak wygląda profil obciążenia CPU, każda zmiana konfiguracji jest strzałem w ciemno. Pierwszy krok optymalizacji to wdrożenie podstawowego monitoringu i nauczenie się interpretacji tych metryk.
Źródło: Pexels | Autor: Alexander Kovalev
Sprzęt i środowisko systemowe – fundament, którego nie da się „przekonfigurować”
CPU: priorytetem jest pojedynczy rdzeń, nie „ilość wątków”
Silnik Minecrafta (Bukkit/Spigot/Paper) jest w ogromnej większości jednowątkowy w części krytycznej. Oznacza to, że wydajność pojedynczego rdzenia jest ważniejsza niż 16 słabych rdzeni. Lepszy będzie procesor z nowszej generacji, wysokim taktowaniem (np. 4+ GHz w boost) i dobrą wydajnością IPC, niż starszy serwerowy CPU z wieloma wolnymi rdzeniami.
Przy wyborze hostingu lub maszyny warto sprawdzić:
rodzinę CPU (np. Intel Xeon starej generacji vs współczesne Intel/AMD Ryzen/Epyc),
rzeczywiste taktowanie przy obciążeniu (nie tylko „do 4,5 GHz” w teorii),
ewentualne limity CPU na VPS (overselling to typowy sygnał ostrzegawczy w tanich ofertach).
Jeśli serwer utrzymuje 100% użycia jednego rdzenia przy 10–20 graczach, a TPS spada poniżej 18, jedynym skutecznym rozwiązaniem bywają: redukcja obciążenia (pluginy, encje, view-distance) lub migracja na mocniejszy procesor. Konfiguracja może pomóc, ale nie zastąpi wydajnego CPU.
RAM: ile pamięci naprawdę jest potrzebne
Przydział RAM dla JVM musi uwzględniać zarówno wymagania serwera Minecraft, jak i systemu operacyjnego oraz innych usług (np. panelu WWW, serwera bazy danych). Ogólny punkt startowy:
Mały serwer (do 10–15 graczy) – 3–5 GB RAM dla JVM, przy czym maszyna powinna mieć co najmniej 6–8 GB całkowitej pamięci;
Średni serwer (do 30–40 graczy) – 6–8 GB dla JVM, łącznie na maszynie 10–16 GB, w zależności od liczby światów i pluginów;
Większy serwer (powyżej 40 graczy) – 10+ GB dla JVM, maszyna 16+ GB, często więcej w przypadku wielu światów i ciężkich pluginów.
Zbyt mały przydział RAM powoduje częste pełne GC, wyrzucanie chunków z pamięci i ogólną niestabilność. Zbyt duży przydział RAM na słabym hostingu prowadzi do długich pauz GC i „gumowych lagów”, mimo że teoretycznie „pamięci jest dużo”. Jeżeli JVM ma 10 GB na VPS-ie z 12 GB RAM całkowitego, a system zacznie swapować – serwer będzie praktycznie niegrywalny.
Jeśli zużycie pamięci stale oscyluje przy 90–95% przydzielonego Xmx, a GC nie jest w stanie zwolnić miejsca, czas na audyt pluginów, redukcję ilości światów lub zwiększenie pamięci (ale dopiero po upewnieniu się, że maszyna to wytrzyma).
Dysk: SSD/NVMe jako absolutne minimum
Dysk talerzowy (HDD) to dzisiaj sygnał ostrzegawczy numer jeden w kontekście wydajności serwera Minecraft. Generowanie i zapisywanie chunków, logi, pliki konfiguracyjne i bazy danych pluginów intensywnie korzystają z I/O. Na HDD każde większe zapisanie mapy lub backup może powodować widoczne lagi, a w skrajnych przypadkach – całkowite „przywieszenie” serwera.
Rekomendacją minimum jest SSD, a w idealnym scenariuszu NVMe z sensownym współdzieleniem na hostingu. Pytania kontrolne do hostingu/VPS:
czy storage jest SSD/NVMe czy hybrydowy,
czy są limity IOPS,
jak wygląda współdzielenie zasobów (tani „unlimited SSD” to zwykle haczyk).
Jeżeli podczas generowania backupów, większego przerzutu plików lub automatycznego zapisu świata TPS spada drastycznie, a na monitoringu widać kolejki I/O – czas na zmianę hostingu albo przeprojektowanie strategii backupów (np. snapshoty na poziomie systemu plików zamiast kopiowania „na żywo”).
System operacyjny: stabilny Linux i podstawowe ustawienia
Większość wydajnych serwerów Minecraft działa na Linuxie, co wynika z lepszej kontroli nad środowiskiem, mniejszego narzutu systemu i łatwiejszej automatyzacji. Kilka technicznych punktów kontrolnych:
Dystrybucja – Debian, Ubuntu Server, CentOS/Alma/Rocky; kluczowa jest stabilność, nie „najmodniejsze” wydanie;
Swappiness – ograniczenie używania SWAP-u, np. przez ustawienie vm.swappiness na 10–20;
Zasilanie – wyłączenie trybów energooszczędnych, które obniżają taktowanie CPU pod obciążeniem;
Aktualizacje – kontrolowane aktualizacje bezpieczeństwa, bez „samoczynnego” restartowania usług w środku dnia.
Jeżeli serwer nadmiernie korzysta ze SWAP-u lub CPU zrzuca taktowanie, nawet najlepiej ustawiony PaperMC nie utrzyma 20 TPS. Minimum to konfiguracja systemu pod aplikację serwerową, a nie „domyślny desktop z przypadkowym serwerem Minecraft gdzieś w tle”.
Kiedy czas zmienić hosting lub rodzaj maszyny
Powtarzalne lagi przy prawidłowej konfiguracji JVM, PaperMC, pluginów i świata są wyraźnym sygnałem, że problem leży w hostingu. Typowe sytuacje:
stałe skoki pingów dla wszystkich graczy (niezależnie od ich lokalizacji),
TPS spada, gdy tylko serwer zapisuje świat lub robi backup,
monitoring pokazuje duże kolejki I/O lub 100% użycia jednego rdzenia przy niewielkiej liczbie graczy,
host sam przyznaje się do „przeciążonych węzłów” i „incydentalnych spadków wydajności”.
Jeżeli serwer na tym samym zestawie pluginów i mapy działa znacznie lepiej na innym hostingu/VPS, wątpliwości znikają. Migracja bywa niewygodna, ale w wielu przypadkach więcej zysku przynosi zmiana maszyny niż tygodnie dłubania w konfiguracji.
Konfiguracja JVM i uruchomienia – pamięć, garbage collector, parametry startowe
Dobór wersji Javy do serwera Bukkit/Spigot/Paper
Nowe wersje PaperMC i Spigot wymagają współczesnych wersji Javy. Obecny standard dla 1.18+ to Java 17, a coraz częściej także Java 21. Wybierając wersję, należy sprawdzić:
zalecenia twórców Paper/Spigot dla danej wersji Minecrafta,
kompatybilność pluginów (stare pluginy mogą nie działać na nowszych Javach),
dojrzałość danej wersji Javy (czyli ilość poprawek, stabilność GC i biblioteki towarzyszące).
Bezpiecznym schematem jest używanie LTS z zalecanej gałęzi (obecnie 17 lub 21) z dystrybucji przeznaczonych na serwery: Eclipse Temurin (dawne AdoptOpenJDK), Azul Zulu, Corretto. Jeśli plugin krytyczny dla rozgrywki działa wyłącznie na starszej Javie (np. 11), sygnałem ostrzegawczym jest brak aktualizacji tego dodatku – w takim przypadku rozsądniejsze bywa znalezienie zamiennika niż cofanie całego środowiska.
Punkt kontrolny: jeżeli przy przejściu z Javy 8/11 na 17/21 wydajność spada lub pojawiają się błędy, pierwsze co trzeba zweryfikować to zgodność pluginów i użyte parametry JVM. Część „starych” paczek startowych z Internetu jest nieaktualna wobec nowych mechanizmów GC i potrafi bardziej zaszkodzić niż pomóc.
Parametry JVM: Xms, Xmx i rozsądny garbage collector
Przy serwerach Paper/Bukkit dobrym punktem startowym jest ustawienie -Xms równego -Xmx (np. -Xms6G -Xmx6G). Eliminuje to fragmentację pamięci i kosztowną, dynamiczną rezerwację RAM. Zapas zostawiony dla systemu operacyjnego i innych usług powinien wynosić co najmniej 2–4 GB, w zależności od roli maszyny. Jeżeli system zaczyna korzystać ze SWAP-u, priorytetem jest zmniejszenie Xmx lub zwiększenie fizycznego RAM, a nie „tuningi” GC.
Dla współczesnych wersji Javy na serwerach Minecraft sensownym wyborem jest G1GC, zwykle bez agresywnego „uprawiania magii” w parametrach. Przykładowy szkielet uruchomienia (Java 17/21):
To tylko szablon, a nie dogmat. Jeżeli serwer ma wyraźnie inne potrzeby (setki graczy, dziesiątki światów), konfiguracja GC wymaga pomiarów – analiza logów GC, obserwacja realnych pauz (GC pause) i korekt wybranych parametrów zamiast ślepego kopiowania „magicznych stringów” z forów.
Jeśli pauzy GC przekraczają kilkaset milisekund, TPS spada w momentach „przycięć”, a wykres mspt wygląda jak zęby piły, pierwszym ruchem nie powinno być zwiększenie Xmx „bo się przycina”, tylko identyfikacja źródła alokacji (ciężkie pluginy, masowa generacja chunków, wycieki pamięci) i ewentualna delikatna korekta parametrów G1GC.
Parametry startowe pod serwer produkcyjny
Poza pamięcią i GC konfiguracja linii komend Javy powinna obejmować kilka oczywistych elementów, ale bez przesady. Z praktyki dobrze sprawdzają się:
-Dfile.encoding=UTF-8 – spójne kodowanie logów i plików konfiguracyjnych;
-Dusing.aikars.flags=false – jeśli używasz paczek parametrów, upewnij się, co faktycznie robią;
-XX:+AlwaysPreTouch – na mocniejszych maszynach prealokacja pamięci przy starcie, stabilizuje działanie pod obciążeniem;
parametry przypisania wątków GC (G1) pozostawione domyślne, chyba że profilowanie wskazuje inaczej.
Sygnał ostrzegawczy: jeżeli linia poleceń uruchamiająca serwer zajmuje kilka ekranów, a nikt w zespole nie potrafi wyjaśnić sensu większości flag, ryzyko przypadkowych degradacji wydajności rośnie. Minimum to krótka dokumentacja przyjętego zestawu parametrów i regularny przegląd w oparciu o aktualne zalecenia PaperMC i Javy.
Przy serwerach hostowanych „u kogoś” dobrym nawykiem jest zapisanie aktualnej linii startowej w repozytorium lub przynajmniej w osobnym pliku tekstowym wraz z datą i krótkim opisem zmian. Ułatwia to cofnięcie nietrafionych modyfikacji oraz porównanie zachowania serwera przed i po aktualizacji Javy lub PaperMC. Punkt kontrolny: jeżeli po zmianie flag TPS, mspt lub zużycie pamięci pogarsza się, a jedyną reakcją jest dalsze dokładanie parametrów z losowych źródeł, problem organizacyjny jest poważniejszy niż same ustawienia JVM.
Przy każdej większej korekcie warto przeprowadzić kontrolowany test obciążeniowy: kilka – kilkanaście osób wykonuje typowe dla waszej rozgrywki czynności (PvP, farma, eksploracja nowych chunków), a administrator równolegle monitoruje TPS, mspt, zużycie RAM, czas pauz GC i obciążenie CPU. Jeśli po wprowadzeniu prostego zestawu flag serwer utrzymuje stabilne 20 TPS przy tym samym scenariuszu, a logi GC nie pokazują długich zatrzymań, eksperyment uznajemy za udany i zamykamy temat – dalsze „upiększanie” linii startowej jest jedynie ryzykiem wprowadzenia regresji.
Ostatecznie, dobrze skonfigurowany serwer Bukkit/Spigot/Paper to kombinacja kilku warstw: przemyślane pluginy, zoptymalizowane światy, stabilna maszyna z sensownym dyskiem oraz prosta, rozumna konfiguracja Javy. Jeżeli każdy z tych obszarów przechodzi podstawowy audyt (brak oczywistych wąskich gardeł, znane punkty kontrolne, zdefiniowane limity), serwer wytrzyma zarówno pojedynczego gracza, jak i nieplanowany „nalot” kilkudziesięciu osób. Gdy mimo tego pojawiają się twarde ściany wydajności, czas przestać „tuningować na ślepo” i podeprzeć się profilowaniem lub zmianą infrastruktury zamiast kolejnej paczki magicznych ustawień.
Źródło: Pexels | Autor: panumas nikhomkhai
Konfiguracja PaperMC i Spigot – kluczowe parametry wpływające na TPS
Silnik Bukkit/Spigot/Paper rozdziela ustawienia na kilka plików. Zanim zacznie się cokolwiek „tuningować”, pliki muszą być w wersji wygenerowanej przez aktualny silnik. Przestarzałe pliki przenoszone z wersji na wersję to klasyczny powód dziwnych zachowań.
server.properties – ustawienia ogólne serwera (sloty, widoczność, port, poziom trudności);
paper.yml oraz config/paper-world-defaults.yml – zaawansowane sterowanie fizyką, AI, generacją świata;
bukkit.yml – kilka starszych, ale nadal istotnych opcji (np. limity zwierząt, potworów, spawnów).
Punkt kontrolny: po każdej większej aktualizacji PaperMC usuń lub przenieś stare pliki konfiguracyjne, uruchom serwer, wygeneruj nowe i dopiero potem ręcznie przenieś ustawienia, mając otwartą dokumentację. Jeżeli w pliku wiszą opcje, których silnik już nie używa, audyt zaczyna się od ich usunięcia.
Jeżeli konfiguracja „odziedziczona po poprzednim adminie” jest dłuższa niż kilka ekranów i nikt nie wie, po co dana opcja powstała, minimum to utworzenie kopii, wyłączenie podejrzanych fragmentów (komentarze) i test przy kontrolowanym obciążeniu.
Ograniczenie zasięgu widzenia i symulacji – server.properties i spigot.yml
Najprostszy, a zarazem jeden z najskuteczniejszych sposobów na stabilny TPS to racjonalny view-distance i simulation-distance. Każdy dodatkowy chunk renderowany i symulowany dla gracza to dodatkowe obciążenie.
view-distance w server.properties – ile chunków gracz widzi;
simulation-distance (nowsze wersje) – ile chunków jest aktywnie przetwarzanych (AI, redstone, ticki).
Dla serwerów survival z kilkunastoma graczami dobrym punktem startowym jest view-distance=8–10 oraz simulation-distance=6–8. Dla masywnych serwerów z dziesiątkami graczy nierzadko schodzi się niżej (np. 6/6), ale wymaga to testów akceptowalności przez graczy.
W spigot.yml znajdziesz dodatkowe ograniczenia w sekcji world-settings, np. entity-tracking-range. Odpowiednio:
zmniejszenie players, monsters, animals – mniej odległych encji do śledzenia;
osobne zakresy dla misc, other – projektyle, ramki, wagony itp.
Jeżeli gracze skarżą się na znikające moby „z daleka”, a TPS jest stabilny na poziomie 20, można stopniowo zwiększać tylko konkretne zakresy, zamiast podnosić globalny view-distance. Sygnał ostrzegawczy: jednoczesne podniesienie view-distance, simulation-distance i wszystkich tracking-range zwykle kończy się skokowym wzrostem mspt przy pierwszym większym evencie.
Jeżeli po obniżeniu view-distance i simulation-distance o 2–3 poziomy TPS wraca do 20, a gracze nadal mogą normalnie eksplorować i walczyć, oznacza to, że poprzednie ustawienia były przesadzone względem mocy maszyny.
Limity entity i ticków – kontrola mobów, farm i redstone
Nadmierna liczba entity i agresywnie zbudowane farmy to jedna z głównych przyczyn spadków TPS. Silnik PaperMC daje sporo narzędzi, aby ograniczyć ten aspekt, często bez zauważalnej straty jakości rozgrywki.
W bukkit.yml i spigot.yml sprawdź przede wszystkim:
spawn-limits (bukkit.yml) – maksymalna liczba potworów, zwierząt, wodnych i ambient na chunk;
ticks-per (bukkit.yml) – odstęp czasowy między próbami spawnu poszczególnych typów mobów;
entity-activation-range (spigot.yml) – dystans, w jakim moby „aktywnie” działają (AI);
entity-lCramming (rule w grze, ale warto mieć politykę) – zbijanie nadmiarowych entity w ciasnych klatkach.
Rozsądna strategia to lekkie obniżenie spawn-limits i zwiększenie ticks-per zamiast całkowitego „zabijania” mobów. Dla serwerów survival różnicę najbardziej czuć w industrialnych farmach; zwykły gracz w kopalni lub w lesie często nawet nie zauważy zmian.
PaperMC dodaje konfiguracje takie jak:
per-player-mob-spawns – rozkład spawnu mobów per gracz, zamiast skupiania w jednym miejscu;
optimize-explosions – szybsze liczenie wybuchów, mniejsze zużycie CPU przy TNT;
max-auto-save-chunks-per-tick – kontrola obciążenia przy zapisywaniu światów.
Punkt kontrolny: jeżeli w momentach lagów licznik entity (np. w debug screen lub pluginie) pokazuje radykalny wzrost w jednym sektorze mapy, trzeba przeprowadzić audyt farm w tej okolicy i dopasować limity. Samo podnoszenie RAM-u czy zmiana flag JVM nie rozwiąże problemu krowy w klatce 2000×.
Jeżeli po wprowadzeniu ograniczeń entity gracze raportują mniejszą skuteczność „mega farm”, ale TPS przestaje skakać podczas ich pracy, bilans jest zwykle dodatni. W przypadku serwerów publicznych minimalizacja lagów przeważnie jest ważniejsza niż 10% różnicy w wydajności konkretnych farm.
Optymalizacja ticków świata – paper-world-defaults.yml
Paper udostępnia centralny plik config/paper-world-defaults.yml, który aplikuje domyślne ustawienia do wszystkich światów (world, nether, the_end, światy eventowe). Zamiast konfigurować każdy z osobna, lepiej ustawić sensowne wartości globalnie i nadpisywać tylko wyjątki.
Krytyczne obszary do przejrzenia:
chunk-loading – limity ładowania chunków na tick, sposób ładowania asynchronicznego;
villager – AI mieszkańców, pathfinding, limity wyszukiwania miejsc pracy i łóżek;
hoppers – prędkość i tryb pracy lejków, możliwość pseudo-batchowania operacji;
mob-spawns – dodatkowe reguły rozkładu i limitowania spawnu w różnych typach światów.
Dokumentacja Paper szczegółowo opisuje każdą opcję. Minimum to:
ograniczenie agresywnego pathfindingu villagerów w wielkich wioskach-handlarni;
przegląd ustawień hoppers pod kątem zmniejszenia ich częstotliwości pracy bez łamania mechanik serwera;
zastosowanie domyślnych rekomendacji Paper w sekcjach redstone i chunk-loading, zamiast ręcznego wymyślania wartości.
Jeśli mspt stabilizuje się po lekkim zaostrzeniu ustawień villagerów i hopperów, a gracze nie widzą różnicy w normalnym użytkowaniu skrzyń i handlek, konfiguracja jest na właściwej ścieżce. Sygnał ostrzegawczy to narzekania konkretnych graczy na „zepsute mechaniki” tuż po zmianie – trzeba zweryfikować, czy nie przesadzono z redukcją ticków obwodów krytycznych dla trybu gry.
Pluginy Bukkit/Spigot/Paper – selekcja, audyt i profilowanie
Minimalny zestaw pluginów a „paczki wszystkomające”
Każdy plugin to dodatkowy kod uruchamiany na głównym wątku serwera, często przy każdym ticku lub zdarzeniu (event). Im większa „paczka” bez rzeczywistej potrzeby, tym wyższe ryzyko spadków TPS.
Przed instalacją czegokolwiek przeprowadź krótki audyt funkcjonalny:
jaką konkretnie funkcję plugin ma spełniać i czy serwer naprawdę jej potrzebuje;
czy tę samą funkcję nie zapewnia już inny zainstalowany plugin lub sam silnik PaperMC;
czy autor aktywnie wspiera wersję Minecrafta, na której działa serwer;
czy plugin ma przejrzystą dokumentację i historię aktualizacji (changelog, repozytorium).
Punkt kontrolny: jeżeli jedynym argumentem za instalacją jest „bo widziałem na innym serwerze” lub „ktoś polecił na Discordzie”, wstrzymaj wdrożenie i sprawdź logi, opinie administratorów oraz wsparcie autora. Przy serwerze produkcyjnym nie ma miejsca na pluginy bez podstawowej weryfikacji.
Jeżeli po odinstalowaniu kilku „zbędnych” pluginów (np. powielających funkcje economii czy prostych kosmetyków) serwer nagle trzyma stabilne 20 TPS w godzinach szczytu, wniosek jest oczywisty: minimalny, świadomie dobrany zestaw jest wydajniejszy od losowo złożonej kolekcji.
Audyt wydajności pluginów – narzędzia i procedura
Trudno zarządzać czymś, czego się nie mierzy. Dla PaperMC podstawowym narzędziem diagnostycznym jest spark (profilowanie) oraz wbudowane komendy Paper. Standardowa procedura audytu powinna wyglądać podobnie przy każdej większej zmianie konfiguracji.
/spark profiler --timeout 60 – profilowanie ticków przez minutę pod normalnym obciążeniem;
/spark tps – bieżący podgląd TPS, mspt i wykresu historii;
/spark healthreport – raport ogólny, często wystarczający do identyfikacji najcięższych pluginów;
/timings on / /timings paste (Paper/Spigot) – klasyczne timeingi, ale interpretowane z ostrożnością.
Podczas profilowania przeprowadź powtarzalny scenariusz: to samo lobby, podobna liczba graczy, ten sam event (PvP, eksploracja, praca farm). Tylko wtedy porównanie raportów „przed” i „po” ma sens.
Sygnały ostrzegawcze w raportach:
pojedynczy plugin zużywający wyraźnie więcej czasu ticka niż pozostałe razem wzięte;
eventy wywoływane tysiące razy na tick przez jeden dodatek (np. PlayerMoveEvent, BlockPhysicsEvent);
ciężkie operacje I/O (zapisy do bazy, plików) wykonywane na głównym wątku.
Jeżeli spark wskazuje 2–3 pluginy odpowiedzialne za większość obciążenia, rozmowa o „tuningu JVM” schodzi na dalszy plan. Najpierw trzeba rozstrzygnąć: aktualizacja, zmiana konfiguracji, optymalizacja po stronie autora czy rezygnacja.
Gdy kolejne raporty profilera pokazują spadek czasu procesora na tick po wyłączeniu konkretnego dodatku, decyzja o jego zastąpieniu jest w pełni uzasadniona technicznie – nie opiera się na wrażeniu, lecz na twardych danych.
Typowe klasy pluginów generujące problemy wydajnościowe
Pewne rodzaje pluginów z natury są bardziej obciążające. To nie znaczy, że są „złe”, ale wymagają bardziej rygorystycznego audytu i ostrożnej konfiguracji.
antycheaty – intensywne nasłuchiwanie ruchu graczy, obliczenia wektorowe, analiza historii ruchów;
loggery bloków / rollback – częste zapisy danych o każdym postawionym/zniszczonym bloku;
pluginy ekonomii z własnymi systemami sklepów i aukcji – odpytywanie baz danych, kalkulacje ofert;
systemy questów / MMO – wiele warunków i skryptów sprawdzanych przy każdym zdarzeniu gracza;
rozbudowane pluginy „all-in-one” – ogromny zakres funkcji, z których używany jest tylko ułamek.
Przykładowa sytuacja z praktyki: serwer survival z 30–40 graczami działał przyzwoicie, dopóki nie dodano ciężkiego plugina questów. Profilowanie wykazało, że przy każdym zabiciu moba plugin wywoływał serię złożonych zapytań w bazie SQL. Zmiana konfiguracji na cache i rzadsze zapisy natychmiast usunęła skoki mspt.
Punkt kontrolny: każdorazowa instalacja plugina z powyższych kategorii wymaga planu testów – offline lub na serwerze testowym – oraz monitoringu w pierwszych dniach działania na produkcji. Jeżeli nie ma możliwości takiego testu, trzeba liczyć się z ryzykiem konieczności szybkiego wyłączenia dodatku w razie problemów.
Jeżeli po czasowym wyłączeniu podejrzanego plugina mspt spada o połowę, nie ma sensu szukać usprawnień w innych obszarach zanim nie zostanie uzgodnione rozwiązanie z jego autorem lub zastępstwo.
Po więcej kontekstu i dodatkowych materiałów możesz zerknąć na Blog.
Aktualizacje pluginów i kompatybilność między wersjami
Stare pluginy z czasów 1.12–1.15 uruchomione „na siłę” na nowszych wersjach często nie są świadome zmian w API, co prowadzi do błędów, wycieków pamięci i niepotrzebnych obliczeń. Utrzymywanie ich na serwerze produkcyjnym to dług techniczny.
Checklist przy aktualizacji i doborze pluginów:
czy autor deklaruje wsparcie wersji Minecrafta i Javy, które są używane na serwerze;
czy changelog zawiera poprawki wydajnościowe (np. „moved heavy tasks off main thread”);
czy repozytorium jest aktywne (commity, zgłoszenia na issue trackerze) w ostatnich miesiącach;
czy autor jasno określa status plugina (beta, stable, abandoned);
czy istnieje wersja dev / prerelease dopasowana do Twojej wersji Paper i czy ma udokumentowane różnice;
czy plugin korzysta z nowego API (np. Adventure, systemy chunków) zamiast haków na niskim poziomie, które zwykle psują się przy aktualizacjach.
Bezpieczny proces aktualizacji zakłada przejście przez dwa środowiska: najpierw serwer testowy, potem produkcja. Scenariusz jest zawsze ten sam: aktualizacja jednego plugina, restart, test kluczowych funkcji (logowanie, ekwipunek, ekonomia, teleporty, zabezpieczenia), krótki profil spark przy obciążeniu. Jeśli po zmianie rośnie mspt lub pojawiają się nowe błędy w konsoli, aktualizację trzeba uznać za nieudaną i przywrócić poprzednią wersję.
Sygnał ostrzegawczy to sytuacja, w której plugin wymaga konkretnej starej wersji silnika (np. wyłącznie Spigot 1.16) i od lat nie dostał aktualizacji. Taki dodatek może działać pozornie poprawnie, ale pod obciążeniem generować wycieki pamięci lub błędy concurrency. Jeśli autor otwarcie informuje, że projekt jest porzucony, a serwer ma charakter produkcyjny, minimalny rozsądek to zaplanowanie migracji do wspieranego odpowiednika.
Jeżeli po przejściu na nowszą wersję plugina w raportach spark znikają długie, blokujące operacje I/O lub spada czas obsługi konkretnych eventów, aktualizacja spełnia swoje zadanie. Jeżeli odwrotnie – pojawiają się nowe „piki” mspt – trzeba bez wahania zgłosić problem autorowi wraz z raportem i tymczasowo pozostać przy poprzednim wydaniu.
Kompatybilność między pluginami bywa równie problematyczna jak zgodność z wersją silnika. Dwa dodatki ingerujące w te same zdarzenia (np. ochrona regionów + własny system flag PvP, kilka warstw antycheata) potrafią nawzajem się blokować, generując kaskady eventów, a w konsekwencji opóźnienia ticków. Punkt kontrolny: każda grupa pluginów realizujących podobną funkcję powinna być przejrzana pod kątem duplikacji – w idealnym scenariuszu za jedno zadanie odpowiada jeden, dobrze utrzymywany dodatek.
W praktyce stabilny i wydajny serwer Minecraft z Bukkit/Spigot/Paper powstaje nie z jednego „magicznego” ustawienia, lecz z serii drobnych, świadomych decyzji: konserwatywnej konfiguracji silnika, przemyślanego doboru pluginów oraz regularnego profilowania przy realnym obciążeniu. Jeśli każde większe wdrożenie kończy się pomiarem (spark, raporty mspt, obserwacja zachowania graczy), a wprowadzane dodatki przechodzą prosty audyt jakości, serwer będzie znacznie lepiej znosił skoki ruchu i eksperymenty z nowymi funkcjami.
Najczęściej zadawane pytania (FAQ)
Jak sprawdzić, czy mój serwer Minecraft naprawdę laguje przez TPS, a nie przez komputery graczy?
Najpierw zweryfikuj TPS i mspt po stronie serwera. Użyj komendy z pluginu typu EssentialsX, Spark albo wbudowanych narzędzi (np. /tps na Paper/Spigot) i sprawdź, czy serwer utrzymuje stabilne ~20 TPS oraz mspt poniżej 50 ms. To jest podstawowy punkt kontrolny: jeśli TPS jest stabilne, problem raczej nie leży po stronie serwera.
Następnie porównaj to z raportami graczy. Jeżeli narzeka jedna osoba, a pozostali grają płynnie, szukaj przyczyny w jej sprzęcie, shaderach, paczce zasobów lub łączu internetowym (wysoki ping, gubione pakiety). Sygnał ostrzegawczy pojawia się dopiero wtedy, gdy kilku graczy jednocześnie zgłasza „spowolnienie świata” (wolne moby, teleporty, opóźnione scoreboardy) i równocześnie widać spadki TPS.
Jeśli TPS jest w normie, a gracze widzą tylko spadki FPS, problem jest po stronie klientów. Jeśli TPS spada poniżej ~18 przy kilku graczach, to już kwestia serwera: konfiguracji, pluginów albo sprzętu.
Jakie są realne oczekiwania wobec wydajnego serwera Minecraft – czy da się mieć „zero lagów”?
„Zero lagów” w praktyce nie istnieje. Realnym celem jest stabilne utrzymanie 19,5–20 TPS przy założonej liczbie graczy, liczbie pluginów i rozmiarze świata. Krótkie spadki do 17–18 TPS przy nagłych pikach obciążenia (masowe teleporty, duże eventy) są normalne, o ile serwer szybko wraca do 20 TPS. W przeciwnym razie mówimy o trwałym problemie wydajnościowym.
Przed stawianiem wymagań porównaj oczekiwania z zasobami. Punkt kontrolny: liczba graczy, rodzaj i liczba pluginów, parametry CPU, rodzaj dysku (SSD/NVMe), przydział RAM. Jeśli chcesz 20 TPS przy kilkudziesięciu graczach, ciężkich pluginach i ogromnym świecie na tanim, słabym VPS-ie, już na starcie masz konflikt między wymaganiami a możliwościami.
Jeśli serwer osiąga stabilne 20 TPS, a gracze nadal narzekają, kierunek audytu przesuwa się na sieć (ping, routing, jakość hostingu) oraz klienta (FPS, mody, shadery). Jeśli TPS regularnie spada poniżej 18 przy typowej liczbie graczy, trzeba szukać wąskich gardeł w CPU, pluginach, encjach i konfiguracji świata.
Jakie są najczęstsze przyczyny lagów na serwerze Bukkit/Spigot/Paper?
Najczęstsze źródła problemów to kilka typowych wąskich gardeł. Wśród nich wyróżniają się: zbyt słaby pojedynczy rdzeń CPU (niskie taktowanie, stara generacja), źle dobrany lub przesadny przydział RAM (GC dusi serwer zamiast pomagać), wolny lub przeciążony dysk (brak SSD/NVMe, storage współdzielony na tanim hostingu) oraz problemy sieciowe (wysokie pingi, gubione pakiety, słaby routing).
Drugą grupę stanowią pluginy i świat. Źle napisane, nieaktualne lub działające synchronicznie pluginy potrafią blokować główny wątek serwera. Dodatkowo agresywne generowanie nowych chunków, nadmierna liczba encji (moby, itemy na ziemi) i niekontrolowane farmy lub mechanizmy redstone powodują gwałtowne wzrosty mspt. Sygnałem ostrzegawczym jest sytuacja, gdy przy niewielu graczach TPS już „siada”, a generowanie świata albo proste akcje nagle mocno obciążają serwer.
Jeśli problemy pojawiają się przy małej liczbie graczy, w pierwszej kolejności audytuj CPU i dysk. Jeżeli kłopoty zaczynają się przy eksploracji nowych terenów lub masowym farmawaniu – skup się na konfiguracji view-distance, limitach encji, pluginach kontrolujących świat oraz optymalizacji konkretnych farm.
Ile RAM przydzielić serwerowi Minecraft i czy „więcej RAM” zawsze pomaga na lagi?
Dobrą bazą jest dopasowanie RAM do skali serwera. Dla małego serwera (do ok. 10–15 graczy) rozsądny punkt startowy to 3–5 GB RAM dla JVM, przy całkowitej pamięci maszyny co najmniej 6–8 GB. Dla serwera średniego (około 30–40 graczy) typowy zakres to 6–8 GB RAM dla JVM i 10–16 GB pamięci całkowitej. Powyżej 40 graczy zwykle trzeba 10 GB RAM i więcej dla JVM oraz min. 16 GB dla całego systemu, szczególnie przy wielu światach i rozbudowanych pluginach.
Więcej RAM nie jest uniwersalnym lekarstwem. Zbyt duży przydział na słabej maszynie może nasilić pracę garbage collectora, co gracze odbiorą jako mikroprzycięcia lub nagłe „zamrożenia”. Sygnał ostrzegawczy: serwer ma teoretycznie dużo RAM, ale widzisz częste, krótkie freezy i długie pauzy przy zapisie świata lub pełnym GC.
Jeśli serwer „laguje”, a wykorzystanie RAM nie jest bliskie maksimum, dalsze zwiększanie przydziału nic nie zmieni. W takiej sytuacji szukaj przyczyny w CPU, dysku, konfiguracji świata i pluginach, a nie tylko w „dosypywaniu pamięci”.
Jaki procesor (CPU) jest najlepszy pod serwer Minecraft na Bukkit/Spigot/Paper?
Dla serwera Minecraft kluczowa jest wydajność pojedynczego rdzenia, a nie liczba wątków. Silnik Bukkit/Spigot/Paper większość krytycznych zadań wykonuje w jednym głównym wątku, więc wyższe taktowanie i lepsze IPC (instrukcje na cykl) są ważniejsze niż 16 słabych rdzeni. Z tego powodu współczesne procesory klasy desktop (Ryzen, nowsze Intel Core) często sprawdzają się lepiej niż stare, wielordzeniowe Xeony z niskim taktowaniem.
Przy wyborze hostingu zwróć uwagę na: generację i rodzinę CPU, realne taktowanie pod obciążeniem (nie tylko „do X GHz” w opisie) oraz ewentualne limity CPU na VPS (overselling, ograniczenia na pojedynczy rdzeń). Punkt kontrolny: jeśli przy 10–20 graczach jeden rdzeń siedzi stale blisko 100%, a TPS spada poniżej 18, procesor jest prawdopodobnym wąskim gardłem.
Jeśli po ograniczeniu encji, obniżeniu view-distance i przejrzeniu pluginów serwer nadal dusi jeden rdzeń, rozwiązaniem jest już tylko migracja na mocniejsze CPU albo zmiana architektury (np. podział na kilka serwerów połączonych BungeeCord/Velocity).
Jakie metryki monitorować, żeby skutecznie optymalizować serwer Minecraft?
Minimum, bez którego każda zmiana jest strzałem w ciemno, to: TPS (ogólna płynność), mspt (ile milisekund trwa jeden tik, docelowo poniżej 50 ms przy 20 TPS), realne zużycie RAM przez proces Java, obciążenie CPU z naciskiem na pojedynczy rdzeń oraz obciążenie dysku (czasy zapisu, kolejki I/O na hostingu/VPS). Te dane można wyciągnąć z narzędzi serwerowych, pluginów profilujących (np. Spark) i paneli hostingu.
Opracowano na podstawie
Minecraft Server: Performance and Debugging. Mojang Studios – Oficjalne informacje o TPS, lagach i debugowaniu serwera Minecraft
SpigotMC Wiki – Lag and TPS. SpigotMC – Wyjaśnienie TPS, MSPT, typowych źródeł lagów i metod diagnostyki
PaperMC Server Optimization Guide. PaperMC – Zalecenia konfiguracyjne Paper dotyczące wydajności, TPS i MSPT
Bukkit Plugin Best Practices. Bukkit – Dobre praktyki tworzenia i używania pluginów pod kątem wydajności
Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide. Oracle – Wpływ konfiguracji JVM i GC na wydajność aplikacji Java
