Maksymalna wydajność serwera Minecraft na Paper krok po kroku

Dlaczego Paper i czym różni się od Bukkit/Spigot pod kątem wydajności

Krótkie porównanie silników Minecraft po stronie serwera

Paper wyrósł na standard dla serwerów, którym zależy na stabilnej i wysokiej wydajności. Żeby dobrze go wykorzystać, trzeba zrozumieć, jak wypada na tle Bukkit i Spigot.

Bukkit to stary, bazowy projekt API dla pluginów. Dziś praktycznie nikt nie stawia produkcyjnych serwerów na czystym Bukkit, bo ten silnik nie jest rozwijany pod kątem optymalizacji. Spigot był odpowiedzią na problemy z wydajnością – wprowadził liczne usprawnienia względem Bukkita: lepszą obsługę entity, spawn mobów, optymalizacje hopperów, ogólnie niższe zużycie zasobów.

Paper jest forkiem Spigota, ale nie tylko „lepiej zoptymalizowanym”. Dodaje:

• dodatkowe konfiguracje w paper.yml,
• łatwiejszą diagnostykę (timings v2, lepsze logi),
• naprawy błędów i exploitów, które w Spigocie ciągnęły się latami,
• agresywne optymalizacje chunków, pathfindingu i kolizji.

W praktyce dla administratora różnica między Spigot a Paper to kilkanaście–kilkadziesiąt konkretnych dźwigni konfiguracyjnych, które pozwalają wycisnąć z tego samego sprzętu znacznie więcej TPS przy większej liczbie graczy.

Różnice architektoniczne Paper vs Bukkit/Spigot a wydajność

Od strony architektury, Paper zmienia sposób działania niektórych mechanizmów silnika, zamiast tylko zmieniać pojedyncze wartości. Kilka kluczowych obszarów:

1. Obsługa chunków
Paper wprowadza asynchroniczne ładowanie chunków i bardziej agresywne buforowanie. Przy dobrze ustawionym paper.yml serwer spędza mniej czasu na blokujących operacjach dyskowych i lepiej rozkłada obciążenie pomiędzy tickami.

2. Pathfinding i AI mobów
Papier mocno ogranicza niepotrzebne obliczenia ścieżek (pathfinding), zwłaszcza dla mobów oddalonych od graczy. Dodatkowo można kontrolować częstotliwość odświeżania AI, co drastycznie zmniejsza koszty CPU w bazach z dużą liczbą istot.

3. Kolizje, fizyka i interakcje
Silnik w Paper pozwala wyłączyć lub uprościć sprawdzanie kolizji między entity, a także ograniczyć niektóre interakcje (np. itemy leżące na ziemi, ruch wody). To parametry, które w Spigocie były domyślne i mniej konfigurowalne.

Funkcje typowo wydajnościowe tylko w Paper

Podstawowa przewaga Paper to zestaw funkcji przeznaczonych stricte do optymalizacji serwera Minecraft. Kilka z nich ma bezpośredni, mierzalny wpływ na FPS graczy i TPS serwera:

• Asynchroniczne ładowanie chunków – minimalizuje krótkie przycinki przy teleportacji i szybkiej jeździe łodzią/elitrą.
• Opcje ograniczania kolizji entity – znacznie mniej obliczeń przy farmach z tysiącami zwierząt lub itemów.
• Rozbudowana kontrola nad hopperami i redstone – zmniejsza wpływ zautomatyzowanych systemów na ticki.
• Parametry per-świat – inne limity i ustawienia optymalizacyjne dla survivalu, netheru, endu czy lobby.
• Zaawansowane ustawienia mobów – ograniczenie pathfindingu, trackingu, losowych ruchów, itp.

Wszystkie te opcje znajdują się w paper.yml i dodatkowych plikach konfiguracyjnych tworzonych przez Paper, a nie w klasycznym spigot.yml.

Kiedy przesiadka na Paper ma sens, a kiedy niewiele zmieni

Zmiana silnika na Paper nie jest magicznym lekarstwem na każdy problem. Są sytuacje, gdy efekt będzie ogromny i takie, gdy praktycznie go nie zobaczysz.

Przesiadka ma realny sens, gdy:

• serwer cierpi na spadki TPS przy 20–50+ graczach,
• świat jest duży, a gracze często się przemieszczają (teleporty, elytra),
• na serwerze istnieją rozbudowane farmy, automatyzacje, duża liczba mobów i zwierząt,
• planujesz dalszą rozbudowę serwera, a sprzęt nie będzie od razu modernizowany.

Przesiadka niewiele zmieni, gdy:

• masz 5–10 graczy online, świat jest mały, a problemy wynikają ze słabego hostingu (wolny dysk, słaba sieć),
• główne lagi powoduje baza danych pluginu (np. błędny config ekonomii), a nie sam silnik,
• serwer stoi na bardzo słabym, współdzielonym hostingu i ma drastyczne limity CPU.

W takich przypadkach Paper nadal jest lepszym wyborem niż Spigot, ale skok wydajności może być ograniczony przez inne wąskie gardła.

Konsekwencje wyboru Paper dla pluginów i kompatybilności

Istnieje mit, że „Paper psuje pluginy”. W praktyce większość dodatków napisanych pod Bukkit/Spigot działa na Paper bez żadnych problemów. Trzeba jednak być świadomym kilku kwestii:

• pluginy używające nieudokumentowanych, wewnętrznych klas (NMS) mogą wymagać Paper-API lub aktualizacji,
• Paper ma własne API z dodatkowymi funkcjami – część lepszych pluginów wykorzystuje je, oferując większą wydajność tylko na Paper,
• czasem plugin napisany „pod czysty Spigot” może działać gorzej lub nie wykorzystywać pełnego potencjału Paper, jeśli korzysta z obejść, które Paper już rozwiązał inaczej.

Najrozsądniejsze podejście: stawiać serwer produkcyjny na Paper, a pluginy wybierać spośród tych, które są testowane i wspierane na tym silniku. Przy nietypowych dodatkach – koniecznie testy na środowisku testowym przed wdrożeniem na produkcję.

Sprzęt, system i Java – fundamenty, na których stoi wydajność

CPU, RAM, dysk, sieć – co naprawdę ma największe znaczenie

Silnik Paper, podobnie jak inne serwerowe implementacje Minecrafta, jest bardzo mocno jednowątkowy. Oznacza to, że pojedynczy, szybki rdzeń CPU ma większą wartość niż wiele wolnych rdzeni. System oczywiście wykorzystuje kilka wątków (np. dla IO, GC, async chunków), ale kluczowy main thread nadal ogranicza się do jednego rdzenia.

Najważniejsze elementy zasobów dla serwera Paper:

• CPU – wysoki zegar (najlepiej powyżej 3.5 GHz realnie utrzymywany), nowoczesna architektura, dobra wydajność pojedynczego rdzenia.
• RAM – wystarczający dla serwera + systemu, ale bez przesady; zbyt duży heap Javy może pogorszyć czasy GC.
• Dysk – SSD zamiast HDD, stabilne IOPS. Przy dużych światach różnica bywa gigantyczna.
• Sieć – niskie opóźnienia, stabilny upload, dobre peeringi. Dla samej wydajności ticków ma mniejsze znaczenie, ale bezpośrednio wpływa na komfort graczy.

W praktyce na średnimi i dużymi serwerami Minecrafta wąskim gardłem jest CPU i dysk. RAM i sieć mają znaczenie, lecz rzadko są pierwszą przyczyną lagów, o ile nie są ekstremalnie zaniżone.

Mocny rdzeń vs wiele rdzeni – jak myśleć o wyborze CPU

Przy wyborze serwera dedykowanego lub VPS warto porównać nie tylko liczbę rdzeni, ale też realną wydajność jednego z nich. Typowy błąd: wybór maszyny z dużą liczbą wolnych rdzeni „bo więcej = lepiej”. Silnik Minecrafta tego nie wykorzysta w takim stopniu, jak się oczekuje.

Lepsze podejście:

• wybrać CPU z wyższym zegarem i nową generacją (np. AMD Ryzen, Intel i5/i7/i9 nowszych generacji) zamiast starego Xeona z ogromną liczbą wolnych rdzeni,
• zadbać, by hosting nie miał ostrych limitów per wątek (częste w tanich VPS-ach),
• unikać współdzielonych środowisk z „burst CPU”, w których wydajność spada losowo.

Jeśli masz do wyboru: 4 rdzenie bardzo szybkie vs 8 rdzeni przeciętne – dla jednego serwera Paper w większości przypadków lepiej sprawdzą się te 4 szybkie.

Przykładowe parametry pod różne typy serwerów

Poniższa tabela to orientacyjne wskazówki dla pojedynczego serwera Paper z umiarkowaną liczbą pluginów (bez sieci bungee/velocity). Są to wartości poglądowe, nie twarde limity.

Te wartości zakładają poprawną konfigurację Paper i rozsądny dobór pluginów. Źle ustawiony serwer jest w stanie zabić nawet najlepszy sprzęt.

Wybór systemu: Linux vs Windows i proste optymalizacje

Większość doświadczonych adminów stawia serwery Paper na Linuksie (np. Ubuntu Server, Debian). Powody są proste:

• mniejsze zużycie RAM i CPU przez system,
• łatwiejsza automatyzacja (skrypty startowe, backupy, cron),
• brak zbędnych usług i „bloatu”,
• stabilne działanie przy długim uptime.

Na Windowsie Paper zadziała, ale wymaga większej dbałości o:

• wyłączenie zbędnych usług,
• ustawienie planu zasilania na wysoką wydajność,
• utrzymanie w ryzach aktualizacji i restartów systemu.

Podstawowe kroki optymalizujące środowisko (Linux):

• użycie dedykowanego użytkownika dla serwera (bez uprawnień roota),
• wyłączenie lub ograniczenie usług, które nie są potrzebne (serwery WWW, GUI, itp.),
• konfiguracja sensownego swappiness, tak aby system nie swapował agresywnie przy normalnym obciążeniu,
• monitoring obciążenia CPU, IO i pamięci (np. htop, iotop, netdata).

Wersja Javy, ustawienia JVM i komenda startowa

Paper jest rozwijany głównie pod nowe wersje Javy. Większość współczesnych wersji Minecrafta serwerowych zaleca Java 17 lub nowszą (w zależności od dokumentacji Paper dla danej wersji). Przy wyborze Javy trzymaj się stabilnych, wspieranych buildów (np. Temurin, Eclipse Adoptium).

Przykładowa, prosta komenda startowa dla serwera Paper:

java -Xms4G -Xmx4G -XX:+UseG1GC -XX:+ParallelRefProcEnabled 
-XX:MaxGCPauseMillis=200 -XX:+UnlockExperimentalVMOptions 
-XX:+DisableExplicitGC -XX:+AlwaysPreTouch -jar paper.jar nogui

Kluczowe zasady przy ustawianiu JVM:

• -Xms i -Xmx ustawiaj na tę samą wartość (stabilny heap),
• nie przydzielaj całego RAM maszyny tylko dla Javy – system i pluginy też czegoś potrzebują (logi, cache, IO),
• stosuj G1GC dla nowszych wersji Javy, który dobrze radzi sobie z typowym obciążeniem serwerów Minecraft.

Bardziej zaawansowane tuningi GC mają sens dopiero wtedy, gdy serwer jest stabilny i chcesz wycisnąć ostatnie procenty wydajności. Na start lepiej postawić na prostą, sprawdzoną konfigurację.

Struktura serwera Paper – porządek w plikach i środowisku

Rozdzielenie środowisk: produkcja, testy, lokalne instancje

Profesjonalne podejście do serwera Minecraft na Paper zaczyna się od jasnego podziału środowisk:

• Produkcja – główny serwer dla graczy.
• Testy – osobna instancja z kopiami konfiguracji, do sprawdzania pluginów i zmian w configach.
• Lokalne – serwery na komputerze admina/devów, do tworzenia i debugowania pluginów oraz map.

Dzięki takiemu podziałowi można bezpiecznie:

• testować aktualizacje Paper i pluginów,

• sprawdzać zmiany w konfiguracjach bez ryzyka uszkodzenia głównej mapy,
• reprodukować problemy zgłaszane przez graczy (lagi w konkretnym miejscu, błąd z pluginem, crashe),
• szlifować balans ekonomii czy dropów zanim trafią na produkcję.

Trzymając te środowiska osobno, unikniesz klasyki gatunku: „wrzuciłem nowy plugin wieczorem, wszystko padło przy 60+ graczach i nie mam jak tego szybko cofnąć”. Testy robisz na kopii, a na produkcję trafia tylko to, co już przeszło chrzest bojowy.

Czysta struktura katalogów i wersjonowanie konfiguracji

Przyda się prosty, powtarzalny układ katalogów. Przykład dla pojedynczej maszyny:

/mc/
  production/
    survival/
    lobby/
  test/
    survival-test/
  backups/
  tools/

W środku każdej instancji trzymaj porządek:

• /plugins – tylko pluginy używane na tej instancji, bez „śmieciowych” jarów po testach,
• /world, /world_nether, /world_the_end – nazwy światów spójne między środowiskami ułatwiają przenoszenie map,
• /logs – regularnie czyszczone lub obracane (logrotate), żeby nie puchły miesiącami.

Konfiguracje (server.properties, paper.yml, spigot.yml, configi pluginów) opłaca się trzymać w systemie kontroli wersji, np. Git. Nie commitujesz całych światów, tylko same pliki tekstowe. Dzięki temu widzisz dokładnie, co zmieniłeś między wersjami, możesz szybko cofnąć jedną złą edycję i łatwo synchronizować configi między produkcją a testami.

Skrypty startowe, backupy i minimalna automatyzacja

Nawet prosty skrypt start.sh rozwiązuje masę problemów na starcie. W jednym miejscu trzymasz:

• komendę uruchomienia Javy z parametrami,
• ustawienie katalogu roboczego,
• mechanizm automatycznego restartu przy crashu.

Do tego dochodzą backupy – minimum to zrzut świata i kluczowych configów raz dziennie na inny dysk lub zewnętrzny storage. Najwygodniej:

• zatrzymać świat (lub przynajmniej użyć wbudowanych komend save-on/save-off),
• spakować katalogi światów i konfiguracji,
• oznaczyć paczkę datą i rotować stare backupy (np. trzymać 7 dziennych, 4 tygodniowe).

Taki podstawowy poziom automatyzacji daje dwie rzeczy: serwer po padzie sam wstaje, a przy większej awarii nie zastanawiasz się „czy w ogóle mamy kopię”, tylko który backup przywrócić.

Dobrze poukładana struktura, stabilne środowisko i sensownie dobrany sprzęt sprawiają, że konfiguracja samego Paper, spigot.yml, paper.yml i pluginów staje się etapem doszlifowania, a nie desperacką walką o każdy TPS. Z takim fundamentem każda późniejsza optymalizacja ma realny efekt, a nie tylko maskuje problemy wygenerowane bałaganem.

Oddzielenie danych zmiennych od stałych

Serwer Paper generuje dużo plików, które zmieniają się non stop (światy, logi, cache) oraz takich, które praktycznie się nie ruszają (jar Paper, część configów). Dobrze jest to rozdzielić logicznie i organizacyjnie:

• „Stałe”: paper.jar, skrypty startowe, podstawowe configi (szablony), paczki zasobów.
• „Zmienne”: katalogi światów, logi, pliki danych pluginów (bazy, cache, storage), crash-reports.

Praktyczne podejście:

• trzymaj „stałe” w repozytorium Git (np. w katalogu /mc/config-templates),
• przy aktualizacji produkcji podmieniaj tylko to, co weszło w nowej wersji (np. configy pluginów z repo),
• światy i dane pluginów backupuj i przenoś narzędziami backupowymi, nie przez Git.

Przy awarii lub przenosinach na inny serwer wystarczy:

1. postawić czystą instancję z repo (jar + configi),
2. dograć świeży backup światów oraz katalogów plugins/<nazwa_pluginu>, które trzymają dane,
3. odpalić serwer i sprawdzić spójność.

Standaryzacja nazw i środowisk

Gdy pojawia się więcej niż jedna instancja (survival, lobby, event, test), chaos w nazwach bardzo szybko uderza w wydajność – admin szuka loga na złym serwerze, wgrywa plugin do złego katalogu, miesza światy.

Sprawdza się prosty standard:

• nazwy katalogów instancji: sv-survival, sv-lobby, sv-event, sv-survival-test,
• nazwy screenów/systemd: mc-survival, mc-lobby – łatwo potem sprawdzić zużycie CPU konkretnej instancji,
• konsekwentny prefix logów i backupów: survival-YYYY-MM-DD.tar.gz.

Takie drobiazgi skracają czas reakcji przy ataku lagów. Zamiast 10 minut szukania „który to był serwer”, w dwie minuty zerkasz w odpowiedni latest.log lub timings i od razu wiesz, gdzie dusi się CPU.

Podstawowa konfiguracja server.properties pod wydajność

Kluczowe parametry wpływające na TPS

server.properties to pierwszy filtr wydajności – część opcji ogranicza potencjalne „głupoty” graczy i zmniejsza obciążenie, zanim do gry wejdą pluginy.

Podstawowy zestaw do przejrzenia:

• view-distance
• simulation-distance (nowsze wersje)
• max-players
• spawn-protection
• online-mode (głównie pod bezpieczeństwo, ale wpływa na proxy)
• enable-command-block
• max-tick-time

Przykładowa konfiguracja dla średniego survivalu bez sieci serwerów:

view-distance=6
simulation-distance=6
max-players=60
spawn-protection=0
online-mode=true
enable-command-block=false
max-tick-time=60000

view-distance oraz simulation-distance to najważniejsze wartości. Ustawienie ich na 10–12 dla serwera z kilkudziesięcioma graczami to proszenie się o stałe 10–14 TPS. Dla większości serwerów:

• mały survival do 20 osób – 6–8,
• średni survival 20–50 osób – 5–7,
• duży, gęsto zaludniony serwer – 4–6.

Niższa simulation distance oznacza mniej aktualizowanych mechanik (moby, redstone, rośliny) daleko od gracza. Wizualnie różnica jest nieduża, a zysk na TPS konkretny.

Parametry sieciowe i sloty graczy

max-players nie zwiększa obciążenia bezpośrednio – liczy się realna liczba zalogowanych. Ustaw jednak rozsądny limit. Jeśli sprzęt „dźwiga” stabilne 40 osób, nie wpisuj 200 tylko dlatego, że wygląda to lepiej w MOTD.

Przy serwerze za proxy (Velocity/BungeeCord):

• online-mode=false na instancjach zza proxy,
• whitelist na poziomie backendu lub firewallu, żeby nikt nie połączył się bezpośrednio na IP serwera Paper,
• sloty (max-players) skoordynowane z limitem na proxy.

Zmniejsza to ryzyko ataków na backend i przypadkowych połączeń, które generują zbędne obciążenie.

Ograniczanie „niebezpiecznych” mechanik w configu

Command blocki, struktury z command blockami, świat creative i tryhardowe machiny redstone w jednym – to gotowy przepis na spadki TPS. Z poziomu server.properties możesz wyłączyć najbardziej problematyczne elementy:

• enable-command-block=false – na survivalu z pluginami praktycznie nigdy nie ma sensu trzymać tego na true,
• spawn-protection=0 – jeśli i tak używasz pluginu do ochrony spawnu (np. WorldGuard).

Im mniej „gołej” funkcjonalności vanilla bez kontroli pluginów, tym łatwiej potem wyłapywać problemy. Pluginy logują zdarzenia, mają własne limity, a czysty command block potrafi cicho zabić wydajność jednym źle napisanym clockiem.

Konfiguracja spigot.yml – odchudzanie silnika z niepotrzebnego balastu

Podstawowe sekcje, którymi warto się zająć

spigot.yml to warstwa pośrednia między Bukkit/Spigot a Paper. Część opcji Paper nadpisuje, ale wiele parametrów nadal ma znaczenie. Najważniejsze sekcje:

• world-settings – limity mobów, ticki, aktywność chunków,
• settings – ogólne zachowanie serwera, np. logowanie,
• messages – kosmetyka, wpływ głównie na czytelność.

Dobrze jest zacząć od ustawień globalnych w world-settings.default, a ewentualne wyjątki robić dla konkretnych światów (np. world_nether).

Ograniczanie rozprzestrzeniania się ognia, płynów i redstone

Mechaniki, które „rozlewają się” po świecie, praktycznie zawsze zabijają TPS, gdy gracze nie mają umiaru. W spigot.yml można mocno je przyciąć.

world-settings:
  default:
    lava-flow-speed:
      normal: 30
      nether: 10
    water-over-lava-flow-speed: 5
    merge-radius:
      item: 3.5
      exp: 4.0
    mob-spawn-range: 6
    nerf-spawner-mobs: true

Przykładowe zmiany i ich efekt:

• lava-flow-speed – wolniejsze rozlewanie lawy zmniejsza liczbę aktualizacji bloków przy masowych akcjach graczy (np. czyszczenie terenów lawą).
• merge-radius – większy promień łączenia itemów i expa znacząco zmniejsza liczbę entity na ziemi, a więc i liczbę operacji co tick.
• mob-spawn-range – mniejszy zasięg spawnów od gracza to mniej losowań mobów w odległych chunkach.
• nerf-spawner-mobs – moby ze spawnerów nie używają AI; grinder działa, ale świry od super-zaawansowanych farm trochę tracą na „inteligencji” mobów.

Kontrola gęstości mobów i entity

Nawet najlepiej zoptymalizowany kod Paper nie pomoże, jeśli w jednym chunku stoi kilkaset mobów lub tysiące itemów. spigot.yml daje kilka suwaków bezpieczeństwa:

world-settings:
  default:
    entity-activation-range:
      animals: 24
      monsters: 24
      raiders: 48
      misc: 16
    tick-inactive-villagers: false
    entity-tracking-range:
      players: 64
      animals: 48
      monsters: 48
      misc: 32
      other: 64

Niższe entity-activation-range oznacza, że entity poza tym promieniem praktycznie „śpią” – nie liczą AI, nie wykonują niepotrzebnych operacji. Dobrze ustalone wartości:

• nie zabijają wrażeń z gry (moby blisko gracza działają normalnie),
• tnie obciążenie przy farmach, zoo z setkami zwierząt w bazach, losowych zgromadzeniach mobów pod ziemią.

tick-inactive-villagers: false pomaga przy wioskach i bazach z setkami villagerów. Część automatów z villagerami może wymagać korekt, ale w zamian znikają niektóre losowe spadki TPS przy większych społecznościach.

Mechanizmy awaryjne – zbroja ostatniej szansy

spigot.yml ma też opcje typu „bezpiecznik”. Niby nie powinny się nigdy aktywować, ale gdy gracz lub plugin zrobią totalne szaleństwo, te limity uratują serwer.

settings:
  restart-on-crash: true
  restart-script: ./start.sh
  sample-count: 12

Przy restart-on-crash serwer po padzie wraca do życia automatycznie. Oczywiście lepiej, żeby nie crashował wcale, ale to minimalna poduszka bezpieczeństwa, zwłaszcza przy serwerze bez 24/7 nadzoru.

Konfiguracja paper.yml – pełne wykorzystanie potencjału Paper

Asynchroniczne zadania i optymalizacja chunków

paper.yml to miejsce, gdzie Paper pokazuje przewagę nad „gołym” Spigotem. Kluczowa część to zarządzanie chunkami i zadaniami asynchronicznymi.

settings:
  use-alternative-luck-formula: false
  async-chunks:
    enable: true
    generation: true
    population: true
    saving: true

Włączenie asynchronicznych chunków (w wersjach, które to wspierają):

• przenosi część ciężkiej pracy z głównego wątku,
• zmniejsza skoki TPS przy szybkim lataniu po świecie lub teleportacjach,
• wymaga jednak stabilnego dysku (najlepiej NVMe/SSD) i dobrej Javy.

Na słabym VPS z wolnym dyskiem lepiej testować to ostrożnie na środowisku testowym – źle dobrane ustawienia potrafią powodować doczytywanie chunków „na raty” lub mikro-przycięcia.

Limity per-tick i kontrola ciężkich mechanik

W paper.yml można bardzo precyzyjnie określić, ile operacji danego typu serwer ma prawo wykonać w jednym ticku. Daje to możliwość „przykręcenia kurków” bez całkowitego wyłączania funkcji.

world-settings:
  default:
    max-auto-save-chunks-per-tick: 50
    mob-spawner-tick-rate: 3
    fire-tick-delay: 5
    redstone-implementation: ALTERNATE_CURRENT

Przykład działania:

• max-auto-save-chunks-per-tick – zbyt wysoka wartość powoduje krótkie, ale mocne lagi przy autosavach; zbyt niska – zbyt rzadkie zapisy świata. Środek jest najlepszy.
• mob-spawner-tick-rate – spawny z mob spawnerów są rzadsze. Farmy dalej działają, tylko trochę wolniej, za to serwer nie dusi się przy dziesiątkach grinderów.
• fire-tick-delay – większe opóźnienie rozprzestrzeniania ognia; podpalenia lasów nie robią aż takiej sieczki z TPS.
• redstone-implementation: ALTERNATE_CURRENT – alternatywna implementacja redstone bardziej przyjazna wydajnościowo niż „czysty” vanilla.

Ochrona przed ekstremalnymi farmami i exploitami TPS

Paper ma kilka mechanizmów, które wprost powstały z myślą o „kreatywnych” graczach budujących farmy pod granicę możliwości silnika. Wspólna cecha: drobne odstępstwo od pełnego vanilla, za to duży zysk na stabilności.

world-settings:
  default:
    anti-xray:
      enabled: true
      engine-mode: 2
      hide-blocks:
        - diamond_ore
        - ancient_debris
    per-player-mob-spawns: true
    falling-block-height-nerf: 0
    tnt-entity-height-nerf: 0

Ustawienia warte rozważenia:

• per-player-mob-spawns: true – bardziej sprawiedliwy podział mobów między graczy i mniejsza szansa, że jedna gigantyczna farma przejmie wszystkie spawny.
• anti-xray – poza walką z oszustami poprawia też rozkład odkrywania chunków (mniej latania na pałę, mniej generacji z „x-ray-hopperami”).
• height-nerf dla spadających bloków/TNT – ogranicza wysokość, z której mogą operować te entity, co tłumi ekstremalne konstrukcje lagujące.

Te opcje koniecznie trzeba testować z faktyczną społecznością. Dla serwera „semi-vanilla” część z nich może być zbyt agresywna. Z drugiej strony, na serwerze ekonomicznym lub technicznym potrafią uratować dzień, gdy ktoś uruchomi gigantyczną maszynę TNT.

Dobrą praktyką jest przygotowanie dwóch wersji paper.yml: „normalnej” i „awaryjnej”. W normalnej konfiguracji limity są luźniejsze, a w awaryjnej – ostrzejsze (mniejsze zasięgi, niższe limity per-tick, agresywniejsze nerfy TNT i spadających bloków). Gdy społeczność odpali nową masową farmę i TPS zacznie siadać, można szybko podmienić plik i zrestartować serwer, zamiast desperacko wyłączać pół pluginów.

Przy każdej zmianie w paper.yml opłaca się robić prosty test: 15–20 minut normalnej gry kilku osób, potem analiza /timings lub profilu ze spark. Jeżeli po obniżeniu danego limitu TPS stoi stabilnie, a gracze nie zgłaszają dziwnych efektów (znikające moby, „wariujący” redstone, problemy z farmami), można taką zmianę uznać za stałą. Gdy pojawiają się skargi, lepiej cofnąć konkretną opcję, niż losowo kręcić innymi suwakami.

Najlepsze efekty daje spójne podejście: sprzęt i Java ogarnięte, server.properties, spigot.yml i paper.yml ustawione pod siebie, pluginy przefiltrowane z „śmieci”, a do tego regularny przegląd timingsów i logów. Z takim zestawem nawet serwer z kilkoma światami, ekonomią i kilkudziesięcioma aktywnymi graczami potrafi utrzymywać stabilne 20 TPS bez codziennego gaszenia pożarów ręcznie.

Pluginy – wybór, optymalizacja i trzymanie porządku

Minimalizm zamiast „paczek na wszystko”

Największy wróg wydajności po źle ustawionym silniku to przeładowany serwer pluginami. Każdy plugin:

• dodaje swoje zadania co tick,
• może podwajać działanie innych (np. kilka systemów ochrony działek),
• często trzyma własne dane w pamięci.

Prosty schemat selekcji pluginów przed wdrożeniem:

1. Sprawdź, czy Paper nie ma już wbudowanej funkcji (np. limity redstone, anti-xray, mob caps).
2. Sprawdź, czy inny używany plugin nie daje tej samej funkcji „przy okazji”.
3. Zweryfikuj aktywność autora (GitHub, SpigotMC, changelog, support).
4. Przeczytaj przynajmniej kilka ostatnich opinii użytkowników – czy nie ma narzekań na lag-spike’i i memory-leaki.

Lepiej mieć jeden dobrze skonfigurowany plugin „all-in-one” niż trzy osobne, które robią to samo i gryzą się ze sobą.

Rozdziel pluginy na kategorie

Pomaga prosty podział logiczny w plugins/ (przynajmniej w notatkach/arkuszu, bo fizycznie folder i tak jest jeden):

• Core – absolutne minimum: permissions, chat, anty-cheat, ochrona mapy.
• Gameplay – ekonomia, sklepy, questy, dodatki survival/skyblock.
• Techniczne – optymalizacje, logowanie, backup, synchronizacja z proxy.
• „Luksus” – kosmetyka, efekty, pety, drobne udogodnienia.

Przy spadku TPS wyłączaj i diagnozuj w odwrotnej kolejności: najpierw „luksus”, potem część gameplay, na końcu core. Dzięki temu wiesz, co faktycznie jest krytyczne dla serwera, a co tylko „miłe dodatki” ubijające ticki.

Jak czytać timings pod kątem pluginów

Paper ma własne timings: /timings report. Najważniejsze elementy raportu:

• Timings v2 – Plugins – lista pluginów z procentowym udziałem w czasie CPU.
• Handlers / Events – które eventy (np. BlockPlaceEvent, PlayerMoveEvent) są najcięższe i przez jaki plugin.
• Tasks – zadania synchronizowane i asynchroniczne, częstotliwość i czas trwania.

Jeśli jeden plugin zabiera ponad kilkanaście procent czasu ticka przy kilku–kilkunastu graczach, jest to kandydat do wymiany lub ostrych korekt konfiguracji. Typowy scenariusz z praktyki: plugin logujący każdy break/place bloków w pliku tekstowym powoduje „mikrofreezy” przy dużych budowach. Rozwiązanie: przejście na bardziej lekkie logowanie (np. baza + batch) albo zmiana pluginu na nowocześniejszy.

Profilowanie spark – głębsze cięcie

spark to must-have przy poważniejszych serwerach. Dwa kluczowe tryby:

• /spark profiler start → kilka minut gry → /spark profiler stop – pełny profil CPU, w tym metody z pluginów.
• /spark tickmonitor – podgląd na żywo, co dzieje się w tickach, skąd biorą się skoki.

Przydatny schemat działania:

1. Uruchom serwer, poczekaj aż gracze zrobią swoje (farmy, teleporty, bojki w Netherze).
2. Włącz spark profiler na kilka minut najbardziej intensywnej aktywności.
3. Przeanalizuj raport pod kątem metod, które pojawiają się na górze zestawienia.
4. Sprawdź, czy da się:
   • zmienić konfigurację pluginu,
   • przestawić zadania na rzadsze wykonywanie,
   • wyłączyć niektóre funkcje,
   • zastąpić plugin innym.

Przykład z życia: plugin od customowych enchantów miał co tick skan całego ekwipunku wszystkich graczy. Po korekcie, aby działał tylko przy konkretnych eventach (np. uderzenie, nałożenie przedmiotu), TPS wrócił do normy, mimo że sam plugin został na serwerze.

Częstotliwość tasków i eventów

Duża część „niewidocznych” lagów to praca schedulerów. W konfiguracjach pluginów szukaj sekcji typu update-interval, task-interval, scan-period i podobnych.

Bezpieczne modyfikacje, które często dają zysk:

• zmiana z 1 tick na 5–10 ticków przy wizualnych efektach (particle, dynamiczny scoreboard),
• zmiana z 5 sekund na 30–60 sekund przy skanerach regionów, kontach ekonomii, anti-afk,
• ograniczenie zasięgu sprawdzania (np. plugin dopuszczający komendy tylko w określonych regionach nie musi skanować całej mapy co chwilę).

Wiele pluginów jest napisanych „na wyrost” – domyślnie aktualizuje wszystko co tick, ale realnie nic nie traci, gdy odświeża się co 0,5–1 sekundę.

Utrzymanie porządku w pluginach

Chaos w wersjach i konfiguracjach zabija więcej serwerów niż pojedynczy bug. Kilka prostych zasad porządkowych:

• Trzymaj osobny folder plugins_disabled obok plugins i przerzucaj tam rzeczy do testów lub czasowo wyłączone.
• Przy aktualizacjach:
  • zapisz aktualną listę pluginów i wersji (screen lub /pl do pliku),
  • aktualizuj po kilka, a nie wszystkie naraz,
  • po każdej „porcji” zrób restart i test timings.
• Nowy plugin zawsze testuj najpierw na kopii serwera (minimalny zestaw graczy + symulacja obciążenia).

Dobrym nawykiem jest krótka notatka do każdego pluginu: po co jest, kto go konfiguruje, czy ma alternatywy. Po kilku miesiącach nikt nie pamięta, po co w ogóle został wrzucony egzotyczny plugin, który nagle jest na szczycie timingsów.

Analiza wydajności: timings, spark i proste metody diagnostyczne

Szybka diagnostyka na żywo

Przy pierwszych skargach graczy na lagi zrób podstawowe komendy diagnostyczne:

• /tps (Paper) – średnie TPS z ostatnich 1/5/15 minut.
• /mspt – czas ticka w milisekundach (komfortowo < 50 ms, cel < 20 ms).
• /gc (np. Essentials lub inne narzędzie) – użycie RAM, informacje o GC.
• /list – ilu graczy, oszacowanie obciążenia na osobę.

Jeżeli TPS jest w porządku, a gracze zgłaszają lagi, często problem leży w sieci (pings, routing, zapełniony upload) albo po stronie klienta. Gdy TPS spada poniżej 18–17 i mspt idzie w górę, szukaj winy w konfiguracji, pluginach albo mechanikach gry.

Timings – jak robić sensowny raport

Typowy błąd: odpalenie timings na minutę. Serwer trzeba łapać w naturalnych warunkach:

1. /timings on – włącz pomiar.
2. Odczekaj co najmniej 10–15 minut normalnej gry:
   • ludzie kopią, latają elytrą, chodzą po farmach,
   • dzieją się teleporty, wejścia/wyjścia do Netheru,
   • odbywają się walki, trade’y z villagerami.
3. /timings paste – wygeneruj link.

W raporcie zwróć uwagę na:

• Lag spikes – krótkie skoki mspt; szukaj zadań wykonywanych rzadko, ale bardzo drogo (np. autosave, backup, gen mapy).
• Stały wysoki mspt – jeden lub kilka procesów stale zjada ticki (konkretne eventy, duże farmy, pathfinding mobów w jednym regionie).
• Światy – który świat (overworld/nether/end/custom) generuje najwięcej kosztu.

Na tej podstawie planujesz kolejność działań: najpierw prosty zysk (zmiana ustawień autosave, cięcie częstotliwości zadań pluginu), potem cięższa artyleria (zmiany w paper.yml, limity mechanik).

spark – kiedy timings nie wystarcza

Timings dobrze wskazują „gdzie” jest problem, ale nie zawsze „co” w kodzie go robi. spark w trybie profilera wchodzi niżej – aż do pojedynczych metod.

Podstawowe kroki:

1. Zainstaluj spark jako plugin.
2. Przy niskim TPS uruchom:
   • /spark profiler start
   • po 2–5 minutach: /spark profiler stop
3. Przejdź do wygenerowanego raportu (link w konsoli / na czacie).

W raporcie szukaj „gorących punktów” – metod z najwyższym udziałem w czasie CPU. Jeśli widzisz długie łańcuchy typu PluginX.onPlayerMove → scanRegion → complexCalculation, masz jasny sygnał, że plugin robi za dużo pracy przy każdym kroku gracza. Rozwiązanie: konfiguracja pluginu (np. wyłączenie niektórych opcji), optymalizacja autora lub zmiana pluginu na lżejszy.

Proste „domowe” metody szukania problemów

Nawet bez zaawansowanych narzędzi możesz wiele wyłapać:

• Systematyczne wyłączanie – na kopii serwera wyłącz po kilka pluginów (przeniesienie z plugins do plugins_disabled), porównaj TPS, sprawdź timings.
• Teleport po „gorących” bazach – odwiedź największe bazy i farmy:
  • obserwuj mspt przed i po teleportacji,
  • sprawdź, czy nie ma setek villagerów, tysięcy itemów, setek armor standów.
• Logi serwera – szukaj spamujących wpisów z błędami (NPE, błędy bazy, timeouty HTTP). Czasem same wyjątki powodują lag-spike’i.

Prosty przykład: administrator narzekał na losowe spadki TPS do kilku sekund. Okazało się, że plugin wysyłał HTTP request przy każdym wejściu gracza na serwer do zewnętrznego API. API czasem wisiało, więc główny wątek czekał. Jedna zmiana w konfiguracji (asynchroniczny tryb + cache wyników) rozwiązała problem bez ruszania sprzętu.

Światy, generacja i „ciężkie” mechaniki gry

Ogranicz zasięg świata zamiast „nieskończoności”

Im dalej gracze lecą, tym więcej chunków trzeba wygenerować i utrzymać na dysku. bukkit.yml i server.properties pozwalają ustawić granice:

• world-border komendą w grze / przez plugin,
• max-world-size w server.properties.

Ustaw realistyczny limit w zależności od trybu i liczby graczy. Dla klasycznego survivalu z kilkudziesięcioma osobami spokojnie wystarczy kilka–kilkanaście tysięcy bloków promienia. Mniejszy świat to:

• mniej generacji on-the-fly,
• mniejsza ilość danych na dysku (backupy, kopiowanie),
• lepsze działanie narzędzi typu mapa online, logi bloków.

Pregeneracja mapy

Największe lagi generacji chunków dzieją się wtedy, gdy gracze pierwszy raz wlatują w dziewicze tereny (szczególnie elytrą). Rozwiązaniem jest pregeneracja wybranego obszaru świata przed startem „prawdziwej” gry.

Najczęściej stosuje się do tego osobne narzędzia / pluginy (np. Chunky, FastAsyncWorldBorder i inne). Schemat jest podobny:

1. Ustaw world-border / docelowy zasięg świata.
2. Skonfiguruj zasięg pregeneracji (np. do granicy world-border).
3. Uruchom generację:
   • pojedynczy świat naraz,
   • z limiterem prędkości generacji (żeby nie zabić dysku i CPU).
4. Po zakończeniu pregeneracji zrób pełny backup.

Pregenerację najlepiej robić przy zatrzymanym właściwym serwerze (na kopii) lub przy wyłączonym dostępie dla graczy. Dzięki temu masz pełną kontrolę nad obciążeniem, a nikt nie lata po półgotowym świecie.

Nether, End i światy poboczne

Każdy dodatkowy świat to osobne ticki, osobne moby, oddzielne chunk-loadery. W Paper/Spigot można:

• wyłączyć nieużywane światy (np. dodatkowy End dla eventów tylko wtedy, gdy faktycznie jest potrzebny),
• zmniejszyć częstotliwość używania rzadkich światów (eventowy Nether tylko na weekendowe eventy, potem wyłączony),
• ustawić osobne, agresywniejsze limity mobów i view-distance dla światów pobocznych.

Dobrze działa prosty podział ról: overworld jako główny świat survivalowy, Nether z wyraźnym limitem zasięgu i mniejszym limitem mobów, End tylko do wypraw po elytry/exp, resetowany co jakiś czas. Zamiast kilku bliźniaczych światów „eventowych” lepiej mieć jeden, włączany tylko pod konkretną akcję i trzymany poza produkcją, gdy nic się tam nie dzieje.

W konfiguracji Paper ogranicz agresywne mechaniki właśnie w światach pobocznych. Przykład: End z farmami expa i dużą ilością platform – niższy entity-activation-range, mniejszy tick-inactive-villagers, ostrzejsze limity hopperów. W Netherze możesz zejść z mob-spawn-range oraz limitu mobów, bo i tak większość farm działa w małej odległości od gracza. Zdarza się, że sam „dietetyczny” Nether zbija mspt o kilka–kilkanaście milisekund.

Kolejna rzecz to śmietnik chunków. Dziesiątki tysięcy wygenerowanych, ale opuszczonych obszarów zajmuje miejsce na dysku, wydłuża backupy i potrafi obciążyć niektóre narzędzia. Zanim odpalisz pluginy do przerabiania albo czyszczenia światów, zrób kopię i przetestuj operację na osobnej instancji. Czasem prościej jest postawić nowy świat poboczny (np. świeży Nether co sezon) i dać graczom jasny komunikat, niż ratować stary.

Ciężkie mechaniki – villagerzy, masowe farmy z mobami, ogromne sortownie – zawsze będą ciążyć serwerowi. Różnica między serwerem, który działa płynnie, a takim, który się dusi, zwykle nie wynika z pojedynczego „magicznego” ustawienia, tylko z sumy rozsądnych decyzji: dobrze dobrany sprzęt, sensownie ustawiony Paper, czyste pluginy, pilnowane światy. Jeśli trzymasz się tych zasad i reagujesz na problemy na etapie timings/spark, zamiast dopiero przy 10 TPS, serwer bez problemu wytrzyma zarówno codzienną grę, jak i większe eventy.

Ograniczanie i kontrola mobów

Wydajność serwera często zabijają nie gracze, tylko moby. Duże farmy, porzucone spawny, villager-halle – wszystko to mieli ticki bez przerwy. Zanim zaczniesz dłubać w egzotycznych ustawieniach, ogarnij podstawy:

• maksymalna liczba mobów na chunk / region,
• zachowanie mobów poza zasięgiem gracza,
• farmy, które chodzą 24/7, mimo że nikt z nich realnie nie korzysta.

W paper.yml i bukkit.yml możesz ustawić limity globalne, a resztę dopiąć zasadami na serwerze. Prosty przykład: maksymalnie 50 villagerów na bazę, 20 zwierząt na gatunek na chunk, zakaz klasycznych „lag-krowiarni” z kilkuset sztukami w jednym bloku.

Jeśli społeczność akceptuje twardsze podejście, dołóż automatyczne narzędzia:

• pluginy czyszczące nadmiar mobów pasywnych w pustych chunkach,
• limity spawnów per gracz (niektóre pluginy potrafią liczyć byty w promieniu od home’ów),
• automatyczne culling (np. usuwanie nadmiarowych zwierząt / armor standów w jednym obszarze).

Przy konfiguracji spawnów nie skupiaj się wyłącznie na „ile mobów generować”. Sprawdź też:

• mob-spawn-range – mniejszy zasięg oznacza mniej chunków, które muszą brać udział w losowaniu,
• ticks-per w bukkit.yml – rzadsze sprawdzanie pewnych typów spawnów (np. potworów wodnych),
• entity-activation-range – im dalej od gracza, tym mniej aktywne moby (AI, pathfinding, ruch).

Brutalne ustawienia bez głowy rozwalą gameplay. Dobre ustawienia prawie nie będą odczuwalne, a zabiorą kilkanaście procent obciążenia. Zawsze testuj zmiany na kopii: jedna zbyt agresywna wartość potrafi zabić wszystkie farmy lub zrobić „martwy” świat.

Villagerzy i ich AI

Villagerzy to klasyczny zabójca wydajności. Handel, pathfinding, szukanie łóżek, stanowisk pracy – to dużo logiki na każdy tick. W Paper masz kilka narzędzi, które mocno odmieniają sytuację.

Kluczowe ustawienia (w różnych wersjach plików konfiguracyjnych nazwy mogą się minimalnie różnić):

• tick-inactive-villagers – jeśli możesz, wyłącz lub mocno ogranicz tickowanie villagerów daleko od gracza,
• villager-brain-tick-rate – zwiększenie interwału między „myśleniem” villagera często niewiele zmienia w zachowaniu, a dużo w wydajności,
• entity-activation-range.villagers – mniejszy zasięg aktywności, zwłaszcza w Endzie/Netherze, gdzie bywają farmy z villagerami.

Do tego dochodzą zasady serwera. Bez ograniczeń pojawiają się korytarze z setkami villagerów, każdy z inną profesją. Rozsądny zestaw reguł może wyglądać tak:

• limit villagerów handlowych na bazę (np. X na osobę / klan),
• zakaz budowania „lag-tuneli” z dziesiątkami stanowisk pracy na chunk,
• przypominajka, że nie wszystkie profesje muszą być w jednym miejscu – część da się rozproszyć.

Czasem bardziej opłaca się zaakceptować nieco gorszy komfort handlu (więcej biegania między villagerami) niż pakować całą ekonomię w jedną halę z 200 NPC.

Redstone, hoppery i itemy w ruchu

Wydajność redstone to nie tylko ilość tłoków. Hoppery, sortownie, droppery przerzucające tysiące itemów na godzinę potrafią spokojnie zająć kilka–kilkanaście milisekund per tick, jeśli są źle zrobione lub źle skonfigurowane.

Na start ogarnij trzy rzeczy:

1. Hoppery – każdy sprawdza zawartość nad sobą i w skrzyni docelowej.
2. Itemy na ziemi – grupowanie i czas życia (merge, despawn).
3. Zegarowe farmy – generatory pulsów zbyt szybkich jak na potrzeby.

W paper.yml i spigot.yml:

• ustaw hopper.transfer i hopper.check na nieco wyższe wartości, zmniejszając częstotliwość działania hopperów,
• włącz stackowanie itemów i ustaw agresywniejsze merge-radius – itemy połączą się szybciej,
• skróć czas życia śmieciowych itemów (np. z farmy expa, mobgrinderów), zostawiając normalny despawn dla „ważnych” obszarów, jeśli masz narzędzia do wyjątków.

Sprawdź największe sortownie. Wiele projektów z YouTube nie jest myślane pod serwery z Paperem, tylko pod singleplayer lub bardzo mocne instancje. Sortownia o połowę mniejsza, za to testowana na realnym serwerze, daje dużo lepszy efekt niż „maksymalny kombajn”, który co chwilę zatyka ticki.

Jeżeli serwer publiczny choruje na kreatywność redstone, przydają się twarde ograniczenia:

• limit hopperów na chunk lub na region (np. przez plugin monitorujący),
• zakaz ciężkich zegarów z wieloma tłokami – tylko prostsze zegary (np. opóźnione comparator + redstone torch),
• monitoring chunków o największym zużyciu czasu (timings → „Chunk Task” → teleport na koordy i inspekcja).

Farmy mobów i mechaniki dropu

Rozbudowane farmy – zwłaszcza z utrzymywaniem mobów przy życiu i transportem – to kolejna, powtarzalna przyczyna lagów. Główne problemy:

• setki mobów upchnięte w jednym miejscu (AI, kolizje, pathfinding),
• ciągły drop + itemy, które nie są szybko zbierane,
• farmy zrobione nad voidem lub kilkoma warstwami, które wymuszają spawn w wielu chunkach na raz.

Dobrze działają proste reguły techniczne:

• limit mobów na jedną farmę; powyżej tego progiem plugin czyści nadmiarowe byty,
• zakaz zostawiania farm 24/7 bez obecności gracza (AFK boty, automatyczne makra),
• czasowe wyłączanie najbardziej obciążających farm na dużych eventach (przez flagi regionów lub pluginy).

Od strony konfiguracji gry:

• zmniejsz mob-spawn-range i limity spawnów w światach typowo „farmowych”,
• obniż max-tnt-per-tick i agresywnie zoptymalizuj mechanikę TNT, jeśli używasz farm opartych o wybuchy (Paper ma sporo opcji z tym związanych),
• skorzystaj z opcji per-player-mob-spawns (tam gdzie dostępne), żeby gracze nie blokowali sobie wzajemnie spawnów.

Na jednym serwerze survival admin po prostu ustalił, że w farmie nie może być więcej niż 100 sztuk danego moba w jednym klastrze. Dodał lekki plugin, który okresowo czyści nadmiar powyżej tego progu. Po tygodniu narzekań na „straty z farm” nikt już nie chciał wracać do poprzednich lagów.

Środowisko pluginów a ciężkie mechaniki

Nawet najlepsze ustawienia Paper nic nie dadzą, jeśli plugin obchodzi je bokiem. Typowe przypadki:

• pluginy wymuszające spawn mobów poza standardowym silnikiem,
• niestandardowe AI (customowe bossy, minigry),
• pluginy stale skanujące świat pod kątem określonych bloków / bytów.

Przy konfiguracji ciężkich pluginów przejdź przez krótką checklistę:

1. Czy plugin respektuje globalne limity mobów, czy spawnuje „ile się da”?
2. Czy ma własne ustawienia częstotliwości zadań (tasków), skanów, eventów?
3. Czy można go „związać” do konkretnego świata lub regionu zamiast całego serwera?

Dobrą praktyką jest trzymanie ciężkich mechanik w osobnym świecie z agresywnymi limitami i niższą jakością wizualną (mniejszy view-distance, mniej efektów, skrócone despawny). Jeśli plugin ma opcje optymalizacyjne, skorzystaj z nich, zamiast liczyć na to, że Paper wszystko załatwi. Autorzy większych projektów zwykle przewidzieli takie scenariusze, ale domyślne wartości są często ustawione „pod pokaz”, a nie pod produkcję.

Koordynacja z graczami i standardy budowy

Nawet perfekcyjna konfiguracja nie poradzi sobie z graczami, którzy stawiają wszystko „na pałę”. Potrzebny jest pakiet jasnych zasad technicznych – zwłaszcza na serwerach z długim życiem świata.

Przyda się krótki regulamin techniczny, w którym zawrzesz m.in.:

• limity villagerów, hopperów i mobów na bazę,
• zakaz specyficznych konstrukcji (np. wielopiętrowe farmy mobów oparte na TNT z dziesiątkami hopperów pod spodem),
• wymóg wyłączalności farm – prosty on/off redstone albo dźwignia, która realnie odcina mechanikę.

Do tego kanał komunikacji: ticket na Discordzie, formularz, cokolwiek prostego, gdzie gracz może zgłosić plan większej konstrukcji. Czasem drobna korekta projektu przed budową (inny układ chunków, o połowę mniej warstw) oszczędza ci godzin śledzenia lagów parę tygodni później.

Jeżeli społeczność jest techniczna, możesz udostępnić publicznie podstawowe statystyki: średni mspt, liczba bytów per świat, największe obciążenie chunków. Świadomość, że „ta farma ciągnie 20% serwera”, często skuteczniej motywuje do optymalizacji niż zakazy w regulaminie.

Optymalizacja światów – od generacji po utrzymanie

Światy są największym „zasobem” serwera. To one generują I/O, obciążają CPU przy generacji chunków, trzymają w pamięci byty i dane regionów. Chaotyczna polityka światów szybko kończy się sytuacją, gdzie nie wiadomo, co można bezpiecznie usunąć, a co trzyma TPS.

Polityka światów – ile i do czego

Na początek dobrze jest jasno określić, do czego służy każdy świat. Inaczej ustawisz świat survival, inaczej świat farm, inaczej mapę eventową czy lobby. Im prostsza struktura, tym łatwiej ją dopracować.

Przykładowy podział:

• świat główny – survival / główna rozgrywka,
• światy farmowe – osobne overworld/nether z agresywniejszą optymalizacją,
• świat eventowy / minigry – krótkotrwałe mapy, wysokie obciążenie, ale kontrolowane,
• lobby / hub – wizytówka, ale z małą liczbą aktywnych mechanik.

Dobrze działa prosta zasada: świat główny utrzymujesz „ładny” i w miarę komfortowy, a wszystko, co bardzo obciąża serwer (farmy, testowiska, eksperymenty), ląduje w osobnym świecie z twardszymi limitami.

Generacja chunków – pregen zamiast lagów przy eksploracji

Najgorszy scenariusz: kilku graczy leci elytrą w różne strony, a Paper musi generować nowe chunku w locie. TPS spada, mspt skacze, dysk dostaje serię losowych zapisów. Zamiast tego:

• zrób pre-generację światów przed startem sezonu (pluginami typu Chunky, WB, itp.),
• ustal twardą granicę świata (border) – pregen do tego zasięgu i koniec,
• pre-generuj oddzielnie overworld, nether, end, a jeśli masz świat farmowy – również jego.

Prosta mikro-checklista dla pregena:

1. Ustal promień świata (np. 10k bloków na stronę).
2. Skonfiguruj border (plugin lub wbudowany).
3. Uruchom pregen poza godzinami szczytu, z limitem chunków/tick.
4. Obserwuj mspt i I/O dysku, reaguj na przycięcia (zmniejsz tempo).

Raz dobrze zrobiony pregen potrafi wyciąć większość lagów związanych z eksploracją. Później pozostaje tylko kontrola, żeby nikt nie próbował „uciekać” poza granicę świata.

Utrzymanie świata – czyszczenie i przycinanie śmieci

Z biegiem miesięcy świat puchnie: porzucone bazy, rozwalone terenówki, tysiące nieużywanych chunków. To nie tylko miejsce na dysku. Każde wczytanie takich okolic (teleport, powrót gracza sprzed pół roku) to nagły zastrzyk pracy.

Przydatne procesy utrzymaniowe:

• czyszczenie nieaktywnych regionów – jeśli gracze nie logowali się X miesięcy, ich prywatne światy / działki można archiwizować poza instancją,
• regularne trimowanie chunków – usuwanie chunków poza aktualnym borderem, jeśli kiedyś był większy,
• porządkowanie map eventowych – po zakończonym evencie cały świat idzie do archiwum lub kosza, nie zostaje w worlds/ „na wszelki wypadek”.

Przed agresywniejszymi akcjami (trim, masowe kasowanie) zawsze robisz pełny backup. Dobrze też z góry zakomunikować graczom, że po X miesiącach nieaktywności ich tereny mogą zostać zarchiwizowane, a nie wiszą wiecznie w aktywnych światach.

View-distance i simulation-distance per świat

Współczesne wersje Paper pozwalają na osobne ustawianie view-distance i simulation-distance per świat. To kluczowe narzędzia, jeśli chcesz utrzymać płynność przy wielu światach.

Prosty schemat:

• świat główny – umiarkowana view-distance (8–10), simulation-distance nieco niższa (6–8),
• świat farmowy – niska view-distance (4–6), niska simulation-distance (4–6),
• lobby – bardzo niska simulation-distance, bo i tak większość to dekoracja,
• mapy eventowe – dopasowane do scenariusza (czasem opłaca się mocno ograniczyć obie wartości, bo liczy się płynność, nie krajobrazy).

W praktyce różnica między view 10 a 6 dla gracza często jest kosmetyczna, a dla serwera – wyraźna. Lepiej mieć stabilne 6–8 i przyzwoite mspt niż „epickie widoki”, które kończą się lagami na każdym evencie.

Konfiguracja spawnów per świat

Mob spawns to jedna z głównych przyczyn obciążeń. Paper pozwala dość precyzyjnie korygować limity spawnów i zasady dla poszczególnych światów. Warto rozdzielić światy „fabularne” od „technicznych”.

Przykładowa logika:

• w świecie głównym utrzymujesz domyślne lub lekko obniżone limity mobów pasywnych i agresywnych,
• w światach farmowych ustawiasz niższe limity globalne, za to pozwalasz na dedykowane farmy (np. przez regiony z innym configiem),
• w lobby i mapach PvP obcinasz spawny prawie do zera, a moby w razie potrzeby generujesz pluginem.

Dobrze jest przy tym zadbać o spójność: jeśli survival ma być „żywy”, nie tniesz spawnów zwierząt do zera tylko dlatego, że ktoś kiedyś postawił złą farmę. Zamiast tego przenosisz ciężkie projekty do świata technicznego i tam dopasowujesz limity pod konkretne konstrukcje.

Portalowanie, nether i end – ograniczanie chaosu

Nether i End to klasyczne miejsca na farmy oraz dziką eksplorację. Duże prędkości (elytra, łodzie w netherze), tunele i portale potrafią wywołać lawinę generacji chunków i problemów z synchronizacją.

Kilka prostych zasad technicznych pomaga to ujarzmić:

• ograniczenie liczby portali w małych odległościach – plugin mapujący portale i łączący zbliżone w jedną sieć,
• twardy worldborder w netherze i endzie, dostosowany do granic overworld (pamiętaj o skali 1:8 w netherze),
• osobny świat end-farmowy dla gigantycznych farm Endermana, jeśli gracze upierają się przy bardzo wydajnych konstrukcjach.

Jedna praktyczna sztuczka: jeśli wiesz, że gracze będą lecieć na end city, zrób pregen w pasie, w którym spodziewasz się ruchu, zamiast czekać, aż ktoś pierwszy raz tam doleci i pociągnie generację w locie.

Zaawansowana diagnostyka – wyjście poza timings

Timings to dobry start, ale przy długofalowym utrzymaniu serwera Paper przydają się bardziej szczegółowe narzędzia. Pozwalają nie tylko znaleźć „co laguje”, ale też zrozumieć, jak zachowuje się serwer w różnych porach dnia i przy różnych typach obciążenia.

Spark – profilowanie ticków i pamięci

spark to jeden z najważniejszych pluginów diagnostycznych. Potrafi profilować ticki, pamięć, a nawet CPU z poziomu JVM. Dobrze skonfigurowany staje się „czarną skrzynką” serwera.

Podstawowe zastosowania:

• profil ticka – która część serwera i które pluginy zużywają najwięcej czasu w ramach jednego lub wielu ticków,
• profilowanie pamięci – sprawdzenie, czy nie masz wycieków (np. plugin, który trzyma referencje do starych obiektów),
• monitorowanie na żądanie – szybkie profile w trakcie eventów lub przy nagłych lagach.

Prosty workflow przy incydencie lagowym:

1. Ktoś zgłasza mocne lagi / wyraźny spadek TPS.
2. Uruchamiasz profilowanie spark na krótki okres (np. 60–120 s).
3. Po zakończeniu analizujesz raport – patrzysz na najcięższe sekcje, powtarzające się zadania, konkretne klasy pluginów.
4. Łączysz wnioski z timings (np. czy ciężki chunk pasuje do ciężkiego zadania z spark).

Spark nie musi działać non-stop z agresywnymi ustawieniami. Najczęściej wystarczą krótkie, celowane profile – inaczej sam staje się elementem obciążenia.

Logi, crash-reports i obserwacja wzorców

Wielu adminów przegląda logi tylko wtedy, gdy serwer się wywali. Tymczasem powtarzalne ostrzeżenia (WARNy), długi start lub specyficzne błędy pluginów są sygnałem, że coś pochłania zasoby w tle.

Dobrze jest przejść przez krótką rutynę po każdym większym update lub restarcie:

• sprawdzenie, czy nie pojawiły się nowe WARNy z konkretnych pluginów,
• czas startu – czy nie wydłużył się wyraźnie po dodaniu/aktualizacji pluginu,
• analiza crash-reportów pod kątem out-of-memory, długich ticków, deadlocków.

Raz na jakiś czas możesz też zrzucić logi z kilku dni i przejrzeć je skryptem pod kątem powtarzających się komunikatów. Przykładowo: ciągłe ostrzeżenia o czasie ładowania chunków często sugerują problem z dyskiem lub I/O (zbyt wiele światów, brak SSD, słaby RAID).

Proste testy obciążeniowe przed wdrożeniem zmian

Zanim wprowadzisz duże zmiany (nowy plugin ekonomii, rework świata farmowego, event na kilkudziesięciu graczy), dobrze jest zrobić prosty test obciążeniowy. Nie musi to być profesjonalny load-test – wystarczy kontrolowana sytuacja na serwerze testowym.

Schemat praktyczny:

1. Stawiasz kopię świata i konfiguracji na osobnej instancji.
2. Zapraszasz kilku–kilkunastu graczy (lub używasz botów) do odtworzenia typowego obciążenia: latanie elytrami, farmienie, PvP.
3. Odpalasz timings i/lub spark na czas testu.
4. Sprawdzasz, co dzieje się z mspt, pamięcią i limitem bytu.

Jeden taki test potrafi wyłapać problemy, które w normalnej grze wychodzą dopiero po tygodniu i psują sezon. Na małych serwerach często wystarczy wieczór testowy z zaufaną ekipą.

Monitoring ciągły – mspt, TPS i liczba bytów

Stały podgląd podstawowych metryk daje pełniejszy obraz niż patrzenie na timings raz w tygodniu. Nawet prosty plugin pokazujący w konsoli lub na stronie:

• aktualny i średni mspt,
• TPS w ujęciu 1 min / 5 min / 15 min,
• liczbę bytów na świat,
• liczbę załadowanych chunków

pozwala łatwo wychwycić anomalie. Jeśli wiesz, że w zwykły dzień masz ~X bytów i ~Y chunków, a nagle liczby rosną dwukrotnie, szybko ustalisz, czy to event, czy ktoś postawił nową, ciężką konstrukcję.

Dla bardziej rozbudowanych infrastruktur (kilka instancji, proxy) przydają się zewnętrzne systemy typu Prometheus + Grafana. Pozwalają zbierać metryki z JVM, systemu, sieci i pluginów i układać je na jednym dashboardzie. Na mniejszym serwerze wystarczy jednak jeden solidny plugin z monitoringiem i okresowy rzut oka na jego statystyki.

Rutyny administracyjne – utrzymanie wysokiej wydajności w czasie

Jednorazowa optymalizacja przy starcie sezonu to za mało. Środowisko się zmienia: aktualizacje Paper, nowe pluginy, rosnąca liczba graczy, nowe światy. Bez prostych, powtarzalnych rutyn serwer po kilku miesiącach „rozjedzie się” wydajnościowo.

Cykle przeglądów konfiguracji

Konfiguracje paper.yml, spigot.yml, bukkit.yml, pluginów i JVM nie są „ustaw i zapomnij”. Po większych update’ach pojawiają się nowe opcje, stare zachowują się inaczej, zmienia się obciążenie.

Przegląd konfiguracji możesz robić co sezon albo co większą aktualizację:

• porównanie aktualnych plików z domyślnymi z nowej wersji Paper (narzędziem do diffów),
• wyszukanie nowych opcji związanych z wydajnością i wymyślenie, jak je wykorzystać,
• weryfikacja starych „magicznych” wartości – czasem to, co kiedyś pomagało, dziś szkodzi.

Dobrze jest przy tym prowadzić prostą dokumentację zmian – chociażby plik tekstowy z datą, opisem zmiany i powodem. Po kilku miesiącach łatwiej wtedy odkręcić eksperyment, który nie wyszedł, zamiast zgadywać, co wpisałeś pół roku temu.

Plan restartów i zadań w tle

Paper radzi sobie dobrze bez częstych restartów, ale niektóre pluginy lubią „odświeżyć się” raz na jakiś czas. Do tego dochodzą zadania utrzymaniowe: czyszczenie świata, backupy, pregen nowej części mapy.

Uporządkowany plan:

• układasz harmonogram restartów (np. raz na dobę lub co kilka dni przy małym serwerze),
• przesuwasz ciężkie zadania (backupy, pregen, większe czyszczenia) na godziny najmniejszego ruchu,
• pilnujesz, żeby nie nakładać na siebie kilku zasobożernych procesów (backup + pregeneracja + aktualizacja pluginów w tym samym oknie czasowym).

Dobrze działa prosty schemat: stały, krótki restart o tej samej porze + osobne „okienka serwisowe” raz na tydzień lub raz na dwa tygodnie. Gracze wiedzą, że wtedy mogą być drobne przerwy, a ty masz czas na porządki techniczne bez presji, że wszystko musi działać idealnie co do minuty.

Przy planowaniu takich zadań ustaw maksymalne limity I/O i CPU, jeśli plugin na to pozwala. Narzędzia do backupu czy pregenu często mają opcje typu „max files per tick” albo „throttle”. Dzięki temu serwer nie dostaje nagłej zadyszki, gdy w tle rusza większa operacja.

Kontrola pluginów i „dług technologiczny”

Pluginy to najczęstsze źródło długu technicznego. Z czasem zbiera się ich kilkadziesiąt, połowa nie jest już używana, kilka nie ma wsparcia, a część dubluje funkcje innych. Każdy jednak coś ładuje, coś trzyma w pamięci, coś wykonuje w ticku.

Raz na jakiś czas:

• robisz listę pluginów z krótkim opisem „po co to jest”,
• usuwasz zbędne lub zastępujesz lżejszymi odpowiednikami,
• sprawdzasz, które pluginy są dawno nieaktualizowane lub powodują błędy w logach,
• zlecasz konfigurację najbardziej obciążających pluginów (np. skyblock, questy, regiony) osobie, która faktycznie zna ich opcje.

Dobrą praktyką jest testowanie każdego nowego pluginu na instancji testowej choćby przez godzinę: start, podstawowa konfiguracja, szybki timings, kilka akcji typowych dla graczy. Łatwiej wtedy odrzucić „ładną, ale ciężką” wtyczkę, zanim trafi na produkcję i zacznie blokować tick.

Podejście iteracyjne zamiast nerwowych rewolucji

Przy problemach z wydajnością kusi, żeby wprowadzać wiele zmian naraz: nowe flagi JVM, duże korekty w paper.yml, wymiana kilku pluginów. Skutek jest taki, że trudno później ustalić, co faktycznie pomogło, a co tylko dołożyło problemów.

Bezpieczniej stosować małe kroki:

• zmieniasz jedną grupę ustawień (np. mob-spawn) i obserwujesz serwer kilka dni,
• notujesz, co dokładnie zmodyfikowałeś i jakie były efekty (TPS, mspt, skargi graczy),
• w razie pogorszenia łatwo cofasz konkretną zmianę, zamiast gmerać po całej konfiguracji.

Takie iteracyjne podejście wymaga odrobiny dyscypliny, ale oszczędza mnóstwo czasu przy dłuższym utrzymaniu. Serwer rozwija się stabilnie, gracze nie dostają co tydzień innego balansu, a ty masz kontrolę nad tym, jak wygląda „profil” obciążenia twojej instancji.

Dobrze poukładany Paper, rozsądna konfiguracja światów i pluginów, podstawowa diagnostyka oraz proste rutyny administracyjne wystarczą, żeby serwer działał płynnie nawet przy wymagających graczach. Reszta to już kwestia tego, jak mądrze wykorzystasz wydajność, którą udało się wycisnąć z silnika – czy na większą liczbę osób, czy na bogatsze mechaniki i bardziej rozbudowaną rozgrywkę.

Najczęściej zadawane pytania (FAQ)

Czy Paper naprawdę daje większą wydajność niż Spigot i Bukkit?

Tak. Paper jest forkiem Spigota z dodatkowymi optymalizacjami i rozbudowaną konfiguracją. Realnie możesz zyskać kilka–kilkanaście TPS przy większej liczbie graczy, szczególnie na serwerach z dużą liczbą mobów, farm i automatyzacji.

Różnica wynika głównie z agresywniejszej obsługi chunków, lepiej ograniczonego pathfindingu mobów, opcji cięcia kolizji entity i zaawansowanej kontroli hopperów oraz redstone. Bukkit w praktyce nie jest już konkurencją pod kątem wydajności – to bardziej „gołe” API pod pluginy.

Kiedy warto przejść ze Spigota na Paper?

Przesiadka ma sens, gdy obserwujesz spadki TPS przy 20+ graczach, gracze skarżą się na przycinki przy teleportach lub lataniu elytrą, a na mapie działają rozbudowane farmy, mobgrindery i automatyką stoi pół serwera. W takich warunkach Paper potrafi znacząco odciążyć CPU i dysk.

Mniej odczujesz zmianę, jeśli masz mały serwer (do 10 osób), mały świat i podstawowe pluginy, a głównym problemem jest słaby hosting (niskie IOPS dysku, limity CPU, słaba sieć). Wtedy Paper nadal jest lepszym wyborem, ale nie „cudem” – wąskim gardłem pozostanie sprzęt.

Czy pluginy na Bukkit/Spigot działają na Paper bez problemów?

Większość popularnych pluginów pisanych pod Bukkit/Spigot działa na Paper bez zmian. Paper zachowuje kompatybilność wsteczną z API, a dodatkowo oferuje własne rozszerzenia Paper-API, z których część pluginów korzysta dla lepszej wydajności.

Problemy pojawiają się głównie przy dodatkach intensywnie korzystających z NMS (wewnętrznych klas Minecrafta) albo robiących „brudne” obejścia mechaniki silnika. Wtedy:

• sprawdź, czy autor wspiera oficjalnie Paper,
• przetestuj plugin na serwerze testowym, zanim wrzucisz go na produkcję,
• szukaj alternatyw, które używają Paper-API zamiast hacków na NMS.

Jakie ustawienia sprzętowe są najlepsze pod Paper (CPU, RAM, dysk)?

Najważniejszy jest szybki pojedynczy rdzeń CPU. Paper, tak jak vanilla i Spigot, jest mocno jednowątkowy, więc 4 bardzo szybkie rdzenie są warte więcej niż 8 wolnych. Szukaj nowoczesnych Ryzenów lub i5/i7/i9 z wysokim realnym zegarem (powyżej ~3.5 GHz pod obciążeniem).

RAM: dla pojedynczego serwera survival/economy zwykle wystarcza 3–4 GB (mały serwer) lub 5–8 GB (20–50 graczy) przy rozsądnej liczbie pluginów. Dysk koniecznie SSD (najlepiej NVMe) – na HDD będziesz widzieć micro-lagi przy generowaniu i ładowaniu chunków, których Paper nie przykryje samą konfiguracją.

Jak Paper poprawia lagi przy teleportacji i lataniu elytrą?

Klucz to asynchroniczne ładowanie chunków i lepsze buforowanie. Paper przenosi część operacji wczytywania chunków z głównego wątku na wątki pomocnicze, dzięki czemu teleporty, szybkie loty elytrą czy jazda łodzią nie blokują bezpośrednio ticka serwera.

W praktyce oznacza to mniej „freeze’ów” przy tp, mniejsze przycinki przy przelotach nad nieodwiedzanymi wcześniej terenami oraz stabilniejsze TPS przy dużych mapach. Efekt mocno zależy jednak od szybkości dysku i konfiguracji parametrów chunków w paper.yml.

Czy Paper obniża FPS graczy, skoro „tnie” AI i kolizje mobów?

Najczęściej jest odwrotnie – stabilniejsze TPS serwera przekłada się na płynniejszą rozgrywkę i bardziej przewidywalne pozycje entity po stronie klienta. Mniej obliczeń po stronie serwera (np. rzadszy pathfinding daleko od graczy, ograniczone kolizje w dużych farmach) to mniej skoków opóźnień i gumkowania.

Jeśli nie przesadzisz z ekstremalnymi cięciami (np. całkowite wyłączenie kolizji, bardzo niska częstotliwość AI), gracze zazwyczaj nie zauważą różnicy „wizualnej”, a odczują po prostu mniej lagów. Dobrą praktyką jest test na małej grupce graczy – najpierw delikatne zmiany, później stopniowe zaostrzenie ustawień.

Czy na mały serwer survival (5–10 graczy) też opłaca się instalować Paper?

Tak, choć nie odczujesz tak dużego skoku, jak przy 30–50+ osobach online. Nawet na małym serwerze zyskujesz:

• lepszą kontrolę nad mobami, hopperami i redstone,
• łatwiejszą diagnostykę (timings v2, dokładniejsze logi),
• dodatkowe zabezpieczenia i naprawy bugów obecnych w Spigocie.

Jeśli korzystasz z taniego, współdzielonego hostingu z mocno przyciętym CPU lub wolnym dyskiem, przejście na Paper nie „zamaskuje” całkowicie problemów, ale nadal będzie to rozsądny silnik startowy – szczególnie gdy w przyszłości planujesz rozwój serwera.

Najważniejsze wnioski

• Paper to następca Spigota nastawiony na wydajność: daje więcej TPS na tym samym sprzęcie dzięki dodatkowemu zestawowi opcji i optymalizacji niedostępnych w Bukkit/Spigot.
• Kluczowe przewagi Paper wynikają ze zmian architektonicznych: asynchroniczne ładowanie chunków, agresywne buforowanie, optymalizacje pathfindingu i kolizji znacząco odciążają CPU przy większej liczbie graczy.
• Paper udostępnia rozbudowaną konfigurację w paper.yml (m.in. kolizje entity, AI mobów, hoppersy, redstone, ustawienia per-świat), co pozwala „podkręcić” wydajność pod konkretny styl gry i infrastrukturę.
• Przesiadka na Paper ma największy sens na serwerach z większą liczbą graczy, dużym światem, intensywnym ruchem (teleporty, elytra) i rozbudowanymi farmami – wtedy różnica w stabilności TPS bywa bardzo wyraźna.
• Przy małych, kameralnych serwerach (kilku graczy) lub słabym hostingu wąskim gardłem często pozostaje sprzęt (CPU/dysk/sieć) albo źle działające pluginy, więc sam Paper nie „naprawi” lagów.
• Większość pluginów Bukkit/Spigot działa na Paper bez problemu; kłopotliwe bywa jedynie mocne użycie NMS lub obejść specyficznych dla gołego Spigota, dlatego przed wdrożeniem nowych dodatków trzeba je przetestować na środowisku testowym.
• Ostateczny efekt Paperu zależy od bazy sprzętowej: Minecraft jest mocno jednowątkowy, więc szybry rdzeń CPU (wysokie taktowanie) i sensownie dobrany RAM mają większe znaczenie niż sama liczba rdzeni czy „przelany” heap Javy.

Źródła informacji

• PaperMC Documentation. PaperMC – Oficjalna dokumentacja Paper: konfiguracja, paper.yml, funkcje wydajnościowe
• SpigotMC Wiki. SpigotMC – Opis różnic Bukkit/Spigot, konfiguracja spigot.yml, wskazówki wydajnościowe
• Bukkit Plugin Tutorial and API Reference. Bukkit – Charakterystyka Bukkit jako API, podstawy architektury i przeznaczenia
• Minecraft Server Software Performance Guide. Akliz – Porównanie wydajności Bukkit, Spigot, Paper i wpływu konfiguracji
• Optimizing Minecraft Servers. BisectHosting – Praktyczne zalecenia dot. CPU, RAM, dysku i konfiguracji serwera Minecraft
• Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide. Oracle – Wpływ rozmiaru heap i GC na wydajność aplikacji Java
• Minecraft Server Performance Optimization. PebbleHost – Omówienie wątkowości serwera, znaczenia pojedynczego rdzenia CPU i I/O