Jak zoptymalizować konfigurację pluginów Bukkit i Paper, aby przyspieszyć serwer Minecraft

Od czego zależy wydajność serwera Minecraft na Bukkit i Paper

Cztery filary wydajności: sprzęt, silnik, pluginy, konfiguracja

Wydajność serwera Minecraft na Bukkit lub Paper nie wynika z jednego „magicznego” ustawienia. To zawsze układ czterech elementów: sprzęt, silnik serwera (Bukkit/Spigot/Paper), zestaw pluginów oraz konfiguracja tych pluginów i samych plików konfiguracyjnych silnika. Zignorowanie któregokolwiek z tych filarów kończy się jednym: gracze widzą lagi, a administrator szuka winnego po omacku.

Sprzęt to podstawa – zbyt wolne jedno rdzeniowe osiągi CPU, wolny dysk czy zbyt mało RAM-u zawsze będą blokować pełny potencjał konfiguracji. Jednak bardzo często na sensownym hostingu czy vps da się zyskać kilka lub kilkanaście TPS bez wymiany serwera, tylko przez mądrą optymalizację pluginów Bukkit i Paper.

Silnik to „interpretator” ticków. Bukkit jest bazą, Spigot dorzuca optymalizacje, a Paper idzie krok dalej, pozwalając pluginom i administratorowi agresywniej zarządzać entity, chunkami i zadaniami. Przy identycznym sprzęcie i podobnym zestawie pluginów dobrze skonfigurowany Paper potrafi utrzymać stabilne 20 TPS tam, gdzie „goły” Bukkit z domyślnymi configami zwyczajnie się dławi.

Ostatni filar – konfiguracja – to miejsce, gdzie wygrywa się lub przegrywa wydajność. Ten sam serwer, ta sama mapa i ci sami gracze mogą działać dramatycznie różnie przy ustawieniach domyślnych vs po dopracowaniu plików paper.yml, spigot.yml, bukkit.yml oraz configów najcięższych pluginów.

Co tak naprawdę „zjada” wydajność: tick, entity, chunki, I/O, baza danych

Serwer Minecraft pracuje w rytmie tzw. ticków. Standardowo powinno ich być 20 na sekundę. Każdy plugin, każdy mob, każda farma musi „zmieścić się” w tych 50 ms. Jeśli się nie mieści – TPS spada. Optymalizacja konfiguracji pluginów Bukkit i Paper polega w dużym skrócie na tym, żeby w pojedynczym ticku działo się mniej kosztownych rzeczy.

Najczęściej problematyczne są:

• Entity – moby, zwierzęta, itemy na ziemi, pancerne stojaki, wagoniki. Im więcej bytów, tym więcej obliczeń w każdym ticku.
• Chunki – generowanie, wczytywanie, utrzymywanie w pamięci. Losowe teleporty, elytry na dużym dystansie i świat „pocięty” pluginami od generatorów potrafią niszczyć wydajność.
• I/O dyskowe – logi, zapisywanie świata, zapisywanie danych pluginów na dysk w głównym wątku. Każde „przycięcie” dysku przenosi się bezpośrednio na spadek TPS.
• Baza danych – źle skonfigurowane połączenia MySQL, zapytania w głównym wątku i brak cache’owania wyników.

Do tego dochodzą intensywne taski pluginów, czyli zadania wywoływane co tick lub co kilka ticków, skany całych światów w poszukiwaniu określonych bloków lub graczy oraz zbyt agresywne logowanie każdego szczegółu rozgrywki do plików tekstowych.

Bukkit, Spigot, Paper – z punktu widzenia optymalizacji pluginów

Patrząc na optymalizację pluginów, różnice między Bukkit, Spigot i Paper można sprowadzić do tego, jakie możliwości dostaje administrator i autor wtyczki.

Bukkit to fundament API. Daje podstawowe eventy i strukturę, ale nie oferuje tak rozbudowanych narzędzi do cięcia kosztów jak Spigot i Paper. Instalując pluginy na gołym Bukkit, jesteś skazany głównie na to, co wtyczki same z siebie potrafią zoptymalizować.

Spigot wprowadza własne ustawienia w spigot.yml, które już pozwalają lepiej kontrolować np. zasięgi wyszukiwania graczy, limity entity czy zachowanie redstone. Dzięki temu pluginy, które korzystają z tych mechanizmów silnika, automatycznie zyskują na wydajności przy dobrym configu.

Paper idzie znacznie dalej, otwierając nowe haki dla pluginów, optymalizacje chunków, systemów kolizji, fizyki i asynchronicznych zadań. Plugin, który jest świadomie napisany pod Paper, potrafi wykonywać cięższe operacje poza głównym wątkiem lub w bardziej inteligentny sposób. Dodatkowo sam administrator ma w paper.yml dziesiątki opcji, które wpływają na to, jak często i jak „drogo” działają wtyczki korzystające z entity i chunków.

Przykład z praktyki: domyślna konfiguracja kontra serwer po optymalizacji

Wyobraź sobie serwer survival z 40 graczami online, dodanymi pluginami na ekonomię, działki, anti-cheat, kilka minigierek i rozbudowanym pluginem logującym blok po bloku. Przy domyślnych ustawieniach Paper, domyślnym view-distance i kilkoma taskami co tick, TPS spada w godzinach szczytu do 12–14. Gracze zgłaszają „teleportujące się moby”, lagi przy otwieraniu skrzyń i dziwne cofki.

Po przejrzeniu logów zdarzeń i raportów timings okazuje się, że trzy pluginy „dławią” serwer: ciężki logger bloków, stary plugin na regiony, który skanuje teren co kilka ticków, oraz rozbudowany anti-cheat z dziesiątkami checków co tick. Zmiana konfiguracji paper.yml (m.in. agresywniejsze limity entity, niższa simulation-distance), wyłączenie niektórych checków w anti-cheacie, ustawienie loggera na zapis asynchroniczny oraz zmiana interwałów tasków wystarczyły, aby przy tej samej liczbie graczy serwer utrzymywał 19–20 TPS.

To pokazuje, że optymalizacja konfiguracji pluginów Bukkit i Paper często daje więcej niż paniczne szukanie nowego hostingu. Dobrze przemyślane ustawienia i spójny zestaw wtyczek potrafią zrobić z przeciętnego serwera naprawdę stabilną maszynę.

Jak mądrze dobrać zestaw pluginów zanim zacznie się optymalizację

Najpierw cel serwera, potem plugin – a nie odwrotnie

Najwięcej problemów z wydajnością zaczyna się nie w configach, ale już w momencie wybierania pluginów. Zamiast pytać „jakie pluginy są fajne?”, lepiej od razu odpowiedzieć: co ten serwer ma robić. Inaczej będzie wyglądał zestaw dla klasycznego survivalu, inaczej dla skyblocka, a jeszcze inaczej dla sieci minigierek.

Prosta praktyka: rozpisz na kartce lub w pliku tekstowym listę funkcji, które są naprawdę potrzebne. Na przykład:

• ochrona działek i regionów,
• ekonomia i sklep,
• system rang i uprawnień,
• podstawowy anti-cheat,
• kilka małych udogodnień (home, tpa, spawn).

Dopiero do takiej listy dobieraj pluginy. Dzięki temu unikasz wtyczek „kombajnów”, które robią 20 rzeczy, z czego realnie używasz 3, a pozostałe obciążają serwer. Przy okazji łatwiej później ocenić, który plugin jest naprawdę krytyczny, a który można bez żalu wyłączyć podczas testów wydajności.

Unikanie dublowania funkcji: jeden cel – jeden plugin

Duża część serwerów cierpi na „syndrom dubla”. Po kilku miesiącach dochodzenia pluginów okazuje się, że są zainstalowane:

• dwa systemy ekonomii,
• trzy pluginy od czatu,
• dwa różne logger-y bloków,
• kilka nakładających się na siebie pluginów ochrony regionów.

Każdy z tych pluginów łapie eventy (np. niszczenie bloku), przetwarza je po swojemu i generuje dodatkowe obciążenie. Nie dość, że gryzie się to funkcjonalnie, to jeszcze przyspiesza zużycie zasobów. Zasada jest prosta: jedna kategoria – jeden dominujący plugin, a jeśli już musisz łączyć, to jasno dziel ich odpowiedzialności.

Przykład: zamiast mieć dwa pluginy ekonomii, które obie obsługują konta graczy, rozsądniej jest mieć jeden główny plugin na economy i niewielką wtyczkę „mostek” integrującą go z innymi systemami (np. sklepami GUI). W ten sposób tylko jeden plugin wykonuje ciężką robotę związaną z przechowywaniem i liczeniem pieniędzy.

Jak ocenić jakość pluginu przed instalacją

Plugin może wyglądać świetnie na stronie, ale zjadać procesor jak smok. Kilka prostych kryteriów pozwala odsiać większość potencjalnie problematycznych dodatków, zanim w ogóle dotkną serwera:

Bardzo dobrym źródłem inspiracji, ale też ostrzeżeń, są społecznościowe zestawienia i blogi skoncentrowane na serwerach, takie jak pluginybukkit.pl. Tam często wprost widać, które wtyczki uchodzą za lekkie i stabilne, a które od lat zbierają raporty o lagach.

• Reputacja autora – aktywny profil, wiele aktualnych projektów, sensowne odpowiedzi na zgłoszenia błędów.
• Częstotliwość aktualizacji – plugin porzucony kilka wersji wstecz często ma niezałatane problemy z wydajnością.
• Informacje o wydajności – wielu autorów uczciwie podaje, czy plugin jest „lekki”, czy może intensywnie korzysta z dysku/bazy.
• Opinie użytkowników – konkretne komentarze typu „po instalacji tego pluginu TPS spadł na 40 graczy” mówią o wiele więcej niż ogólne zachwyty.

Dobrym sygnałem jest, gdy autor pluginu wprost udostępnia zalecenia optymalizacyjne, opisuje opcje asynchronicznego zapisu, tłumaczy działanie tasków czy podaje rekomendowane ustawienia interwałów. Jeśli w configu widać opcje typu run-async, database-pool-size, log-interval, to przynajmniej wiadomo, że ktoś myślał o wydajności.

Lekkie alternatywy dla „kombajnów”

Rozbudowane pluginy „od wszystkiego” są kuszące – instalacja jednego jar-a i nagle masz 10 funkcji. Często jednak ceną jest wydajność. Wtyczka, która ma własny system czatu, ekonomii, dropów, tablisty i jeszcze mini-questy, niemal na pewno trzyma wiele rzeczy w pamięci i rejestruje mnóstwo eventów.

Bezpieczniejsze podejście to modularność. Dla przykładu:

• oddzielny plugin do rang i uprawnień,
• osobny do ekonomii,
• mała wtyczka do GUI sklepu,
• osobny, prosty plugin do czatu.

Jeśli któryś z nich okaże się problematyczny dla TPS, łatwiej go wymienić bez wywracania całej struktury serwera. Do tego często mniejsze, dobrze napisane pluginy są po prostu lżejsze niż jeden monolit próbujący „ogarnąć” wszystko.

Historia z praktyki: trzy wyrzucone pluginy i nagły powrót TPS

Na jednym z serwerów, z którym miałem do czynienia, administracja skarżyła się na nieustanne ścinki. Konfiguracja Paper była już w miarę ogarnięta, sprzęt przyzwoity, a mimo to przy 30–35 graczach TPS spadał do okolic 10–12. Profilowanie timings pokazało, że głównymi winowajcami są trzy wtyczki: ciężki logger bloków (logował wszystko), rozbudowany plugin „hubowy” z masą efektów i bardzo stary anti-cheat nakładający się z nowym.

Po krótkiej dyskusji w zespole adminów zapadła decyzja: usuwamy „kombajnowy” hub, zastępując go dwoma lżejszymi pluginami (oddzielnie efekty, oddzielnie tablica wyników), logger bloków zmieniamy na lżejszy, a stary anti-cheat wylatuje całkowicie. Już po pierwszym restarcie TPS wrócił do 19–20 na identycznym obciążeniu. Żadnej magii – tylko wyrzucenie nadmiarowego balastu.

Porządkowanie i priorytetyzacja pluginów – fundament pod dalszą konfigurację

Lista pluginów z opisem roli – prosty, ale kluczowy krok

Zanim zacznie się grzebać w configach, potrzebna jest pełna świadomość tego, co jest zainstalowane. Administratorzy często mają w /plugins więcej jar-ów, niż sami pamiętają. Dobrym nawykiem jest stworzenie prostej tabeli lub listy opisującej każdy plugin jednym, dwoma zdaniami: co robi i czy jest krytyczny dla serwera.

Można to zrobić na przykład tak:

• EssentialsX – komendy podstawowe, home, tp, spawn – krytyczny dla rozgrywki.
• WorldGuard – ochrona regionów, flagi – krytyczny.
• OldCombatMechanics – zmiana mechaniki walki – średnio ważny, zależny od stylu serwera.
• LoggerXYZ – dokładne logi bloków – ważny dla administracji, ale nie dla samej rozgrywki.
• ChatFormatter – kolorowy chat, formaty – kosmetyka.

Taka lista staje się bazą do późniejszych decyzji: co można wyłączyć na próbę, co przesunąć na lżejszy odpowiednik, a czego lepiej w ogóle nie ruszać, dopóki nie ma absolutnej pewności, że to winowajca.

Rozpoznawanie „ciężkich” kategorii pluginów

Nie wszystkie wtyczki obciążają serwer tak samo. Są całe kategorie, które z definicji są bardziej wymagające niż pozostałe. Dlatego dobrze je od razu oznaczyć i poświęcić im szczególną uwagę przy optymalizacji konfiguracji.

Do takich kategorii należą m.in.:

Kategorie pluginów, które najczęściej „bolą” wydajność

Kiedy spojrzysz na listę wtyczek pod kątem wydajności, pewne grupy niemal zawsze wyskakują na czerwono. To nie znaczy, że są „złe”, tylko że trzeba je konfigurować z głową, bo z natury dotykają wielu eventów lub często korzystają z dysku i bazy.

Do takich newralgicznych kategorii należą głównie:

• logger-y bloków i czynności graczy (CoreProtect, LogBlock, itp.),
• rozbudowane anti-cheaty,
• pluginy działek/regionów z masą flag i niestandardowych warunków,
• systemy questów i zadań śledzące postęp graczy niemal przy każdej akcji,
• skomplikowane pluginy dropów/lootów,
• pluginy mapujące i statystyczne (np. mapy WWW, dokładne statystyki online),
• rozbudowane systemy minigier z własną logiką tickową.

Jeśli widzisz, że w jednej kategorii masz po dwie–trzy takie wtyczki, to już sygnał ostrzegawczy. Lepiej postawić na jeden, dobrze ogarnięty system i zoptymalizować go maksymalnie, niż łączyć kilka średnio dogadujących się ze sobą kombajnów.

Grupowanie pluginów według ważności dla rozgrywki

Sama lista „co robi dany plugin” to dopiero start. Kolejny krok to ułożenie wtyczek w kilka prostych „koszyków ważności”. Dzięki temu podczas optymalizacji nie będziesz zastanawiać się za każdym razem od zera, co można tymczasowo wyłączyć.

Przykładowy podział może wyglądać tak:

• Krytyczne dla rozgrywki – bez nich serwer traci sens (ochrona regionów, uprawnienia, kluczowa ekonomia).
• Ważne, ale zastępowalne – można wymienić na lżejszy odpowiednik lub uprościć (np. zaawansowany czat, rozbudowany sklep GUI).
• Administracyjne / narzędziowe – logi, narzędzia do rollbacku, pluginy developerskie.
• Kosmetyczne – efekty, fajerwerki przy wejściu, funny-komendy, trochę „smaczków”.

Gdy przyjdzie moment, że TPS spada, nie musisz panikować. Najpierw „lecą” kosmetyki, później część narzędzi i dopiero na końcu dotykasz fundamentów, a i to ostrożnie. To trochę jak z oszczędzaniem prądu: najpierw gasisz neony, a nie wyłączasz lodówki.

Plan wyłączania i testów – nie baw się w losowe zgadywanie

Chaotyczne wyłączanie losowych pluginów w nadziei, że „może pomoże” zwykle kończy się większym bałaganem niż wcześniej. Wydajniej jest od razu przygotować prosty plan testów. Może być nawet w notatniku:

1. Lista pluginów kosmetycznych + data, kiedy były wyłączane.
2. Lista pluginów „ciężkich” (logger, anti-cheat, questy) z opisem, jak były modyfikowane.
3. Oznaczenie, przy jakiej liczbie graczy i TPS wykonywano test.

Podczas jednego z serwerów survival admin wprowadzał zmiany „na czuja” i po tygodniu nikt nie wiedział, co faktycznie pomogło. Dopiero gdy zaczął robić krótkie notatki przy każdym restarcie, okazało się, że winny był konkretny moduł w anti-cheacie logujący wszystko do plików.

Kluczowe pliki konfiguracyjne: paper.yml, spigot.yml, bukkit.yml – co naprawdę wpływa na wydajność

Dlaczego to właśnie te pliki są „szkieletem” ustawień

Pluginy dodają funkcje, ale to trójka paper.yml, spigot.yml i bukkit.yml ustala, jak serwer obchodzi się z tickami, światami, entity i ruchem graczy. To taki „system operacyjny” twojego Paper/Bukkit. Błędne ustawienia w tych plikach potrafią sprawić, że nawet lekkie pluginy zaczną lagować, bo pracują na złym fundamencie.

Dlatego lepiej podchodzić do tych configów świadomie, a nie tylko wklejać pierwszą „cudowną konfigurację” znalezioną w internecie. Serwer z 10 graczami na worldborder 5k nie potrzebuje tych samych ustawień, co serwer z kilkuset osobami na dużej mapie.

bukkit.yml – podstawy ticków i ogólnego zachowania świata

Choć bukkit.yml wydaje się skromny, kilka opcji naprawdę ma znaczenie dla wydajności, zwłaszcza w połączeniu z pluginami, które mocno pracują na entity i mechanikach vanilla.

• spawn-limits – maksymalna liczba mobów w świecie (monsters, animals, water-animals, ambient). Jeśli pluginy dodają własne mechaniki spawnów (farmy, custom moby), przesadnie wysokie limity mogą szybko zapełnić mapę entity. Rozsądne obniżenie tych wartości często działa lepiej niż agresywne cleary mobów.
• ticks-per – odstępy między tickami określonych zadań (np. mob-spawn, animal-spawns). Zwiększenie interwałów rozciąga w czasie niektóre akcje, co odciąża serwer. W połączeniu z pluginami typu mob-arena czy custom-mobs dobrze sprawdzić, czy te mechaniki nie dublują się ze spawnami Bukkit.
• chunk-gc (w starszych wersjach) – interwały odśmiecania chunków. Przy agresywnej konfiguracji i pluginach zapisujących dane w chunkach (np. działki) lepiej unikać zbyt częstych cykli, bo każdorazowy „garbage collection” chunków jest odczuwalny.

Dobrą praktyką jest ustawienie rozsądnych limitów spawnów i potem testowanie, jak reagują na to pluginy. Jeśli wtyczka od custom-mobów ma własne limity, trzeba je ze sobą zgrać, żeby nie powstał „wyścig zbrojeń” między Bukkit a pluginem.

spigot.yml – kontrola entity, zasięgów i kolizji

spigot.yml ma znacznie większy wpływ na to, jak pluginy „odczuwają” świat, bo definiuje zasięg śledzenia mobów, kolizje, limity tickowania entity i wiele innych drobiazgów.

Najważniejsze sekcje pod kątem współpracy z pluginami to:

• entity-activation-range – decyduje, z jakiej odległości entity są aktywnie tickowane. Jeśli pluginy polegają na tym, że mob zawsze „widzi” gracza (np. zaawansowane AI, custom dropy), zbyt mały zasięg może psuć mechanikę. Z drugiej strony wysoki zasięg przy dużej ilości mobów to gotowa recepta na spadek TPS.
• tick-inactive-villagers – villagerzy są szczególnie ciężcy, a pluginy często używają ich do sklepów lub systemów NPC. Wyłączenie tickowania nieaktywnych villagerów może bardzo pomóc przy serwerach ze sporymi osadami, ale trzeba przetestować, czy pluginy używające villagerów do handlu nadal działają jak trzeba.
• merge-radius – łączenie itemów i exp-orbów. Im większy promień, tym mniej entity do przetwarzania, co kochają serwery z dużą ilością dropu (np. serwery typu „drop SMP” z custom lootem). Trzeba jednak uważać z pluginami, które bazują na dokładnej liczbie itemków na ziemi.
• view-distance i entity-tracking-range – zasięg widzenia i śledzenia entity. W połączeniu z pluginami typu minigry czy custom bossy czasem lepiej zmniejszyć globalny zasięg, a w krytycznych miejscach (np. w arenie) używać dedykowanych światów z innymi ustawieniami.

Na jednym z serwerów skyblock wystarczyło obniżyć entity-activation-range i delikatnie zwiększyć merge-radius, aby farmsy z 100+ mobami nie rozjeżdżały TPS przy każdym podejściu gracza. Żaden plugin nie został usunięty – po prostu świat „nie krzyczał” o uwagę tak wielu entity naraz.

paper.yml – dodatkowe hamulce i ulepszenia pod pluginy

Paper dodaje własny zestaw opcji, które mocno wpływają na interakcję świata z pluginami. Wiele mechanizmów optymalizacyjnych jest właśnie tutaj i bywa, że jeden checkbox w paper.yml zmienia zachowanie kilku wtyczek jednocześnie.

Najbardziej newralgiczne rzeczy to m.in.:

• Asynchroniczne ładowanie i zapisywanie chunków – przy pluginach intensywnie korzystających z IO (logger-y, działki, custom-world) asynchroniczne operacje na chunkach znacząco redukują „przycięcia” przy teleportach czy szybkiej jeździe elytrą.
• Limity i priorytety tasków – Paper wprowadza dodatkowe mechanizmy ograniczania tego, ile rzeczy może dziać się w jednym ticku (np. max-tick-time dla tile-entity i entity). Jeśli plugin wchodzi w konflikt z tym limitem, może to wskazać miejsce do optymalizacji po jego stronie.
• Opcje pod redstone i mechanikę farm – redukcja częstotliwości aktualizacji redstone’a, tłoków itp. ma ogromne znaczenie, jeśli pluginy dodają automaty (np. automatyczne farmy, maszyny). Gdy plugin oczekuje 100% vanilla zachowania, zbyt agresywne „cięcia” redstone’a mogą powodować błędy – to trzeba testować.
• Mechanizmy ochrony przed lagującymi pluginami – Paper potrafi logować ostrzeżenia, kiedy dana wtyczka blokuje główny wątek zbyt długo. Włączenie i przejrzenie tych logów przed grzebaniem w configach bywa znacznie szybszą drogą do winowajcy.

Konfigurując paper.yml, wygodnie jest robić małe kroki. Zmieniasz jedną–dwie opcje, restart, krótki test przy obciążeniu, dopiero potem kolejne ruchy. Gwałtowna zmiana całej sekcji redstone+moby jednocześnie sprawi, że trudno ci będzie stwierdzić, co faktycznie pomogło.

Konfiguracja pluginów a praca ticka: taski, eventy i harmonogramy

Jak pluginy „wchodzą” w każdy tick

Silnik Paper/Bukkit działa w rytmie 20 ticków na sekundę (w idealnych warunkach). Większość pluginów podłącza się do tego rytmu na dwa sposoby: nasłuchując eventów (np. niszczenie bloku, ruch gracza) i uruchamiając zaplanowane taski (co X ticków). Jeśli każdy plugin „chce coś zrobić” w tym samym momencie, tick się wydłuża, TPS spada i gracz czuje ścinkę.

Wyobraź sobie tick jako minutę na kasie w sklepie. Jeśli w tej jednej minucie do okienka podbiegnie dziesięć osób z ogromnym koszykiem, kolejka zaraz stanie. Konfiguracja pluginów to w praktyce zarządzanie tym, ile „klientów” przychodzi w danym ticku.

Dobrym uzupełnieniem będzie też materiał: Kiedy warto przejść z Bukkita na Paper i jak zrobić to bezboleśnie — warto go przejrzeć w kontekście powyższych wskazówek.

Rozsądne ustawianie interwałów tasków

Wiele pluginów ma w configu coś w rodzaju check-interval, save-interval, scan-period itp. To zwykle oznacza zadanie, które chodzi cyklicznie po świecie, bazie danych lub danych graczy. Domyślne wartości często są ustawione „bezpiecznie” (często), żeby wszystko było responsywne, ale spokojnie da się je wydłużyć, nie psując rozgrywki.

Kilka praktycznych zasad:

• Rzeczy wizualne (efekty, animacje) można spokojnie opóźnić – gracz nie zauważy, że efekt pojawił się po 0,5 zamiast po 0,2 sekundy.
• Zapisy do bazy lub pliku (autosave) wystarczy robić co kilka minut, a nie co 30 sekund, o ile plugin ma mechanizmy bezpiecznego zamykania serwera.
• Skany świata (szukanie określonych bloków, cleanup itemów) lepiej podzielić na mniejsze porcje: zamiast jednego ciężkiego skanu co 60 sekund – mniejsze skany co 5–10 sekund obejmujące tylko część chunków.

Na jednym z serwerów skyblock wystarczyło zwiększyć interwał zapisu działek z 30 do 180 sekund i przesunąć cięższe skany wycieków z regionów na godziny nocne. Gracze nic nie odczuli, a wykres CPU przestał wyglądać jak sinusoida.

Unikanie zbyt częstych eventów „na wszystko”

Niektóre pluginy lubią nasłuchiwać bardzo ogólnych eventów, typu: PlayerMoveEvent, BlockPhysicsEvent, EntityDamageEvent – i sprawdzać w nich dziesiątki warunków. To normalne, ale gdy kilka wtyczek robi to samo, każdy krok gracza staje się małą burzą mózgów dla serwera.

Jeśli masz dostęp do configu, wypatruj opcji ustawień „zakresu działania”:

• czy plugin musi działać w każdym świecie, czy tylko w jednym/dwóch?
• czy konkretne funkcje można wyłączyć w regionach albo wymusić tylko dla określonych rang?
• czy plugin oferuje tryb „light” lub wyłączenie części bardziej zaawansowanych sprawdzeń?

Często minimalne zawężenie obszaru działania (np. tylko świat survival, bez spawn i event) usuwa pół problemu, bo liczba uruchomień eventów spada radykalnie.

Asynchroniczne taski – kiedy pomagają, a kiedy szkodzą

Asynchroniczność brzmi jak złoty lek na laga: „wrzućmy to na osobny wątek i będzie szybciej”. Niestety w Bukkit/Paper to połowa prawdy. Silnik Minecrafta nie jest z natury w pełni thread-safe – większość operacji na świecie musi dziać się na głównym wątku ticka. Dlatego asynchron wykorzystuje się głównie do:

• operacji na bazie danych i plikach,
• cięższych obliczeń (np. analizy regionów, statystyki),
• komunikacji sieciowej (API, sieci serwerów).

Jeśli plugin pozwala w configu przełączyć tryb działania na „async” dla zadań IO, zwykle warto to rozważyć. Pod jednym warunkiem: trzeba upewnić się, że ta asynchroniczność dotyczy rzeczywiście bazy/plików, a nie losowego grzebania w blokach i entity z innego wątku.

Kilka praktycznych wskazówek:

• Asynchroniczne logowanie, zapisywanie statystyk, ekonomii – zwykle bardzo pomaga. Główny wątek nie stoi, czekając na dysk.
• Asynchroniczne generowanie raportów lub analiz (np. kto ile zniszczył bloków) – dobry kandydat na osobny wątek.
• Modyfikacje świata, entity, inventory – jeśli plugin robi to asynchronicznie, może powodować błędy trudne do zreplikowania, łącznie z crashami. Takie wtyczki albo aktualizuje się do wersji przyjaznej Paper, albo wymienia.

Jeśli zauważasz w logach ostrzeżenia o dostępie z innego wątku (Paper jest w tym bezlitosny), przejrzyj configi – często twórcy dają możliwość wyłączenia trybów async albo przerzucenia cięższych operacji na harmonogram na głównym wątku w mniejszych porcjach.

Dzielenie ciężkich zadań na „kawałki”

Najwygodniej jest zlecić pluginowi, by „zrobił wszystko naraz”: przeskanował region, policzył itemy, sprawdził flagi działek. Problem w tym, że to jedno zadanie potrafi „zjeść” pół ticka. Lepszy efekt daje podejście porcjowane – trochę jak jedzenie ciasta na kawałki zamiast na raz.

Jeśli plugin oferuje w configu takie opcje, szukaj parametrów typu:

• max-operations-per-tick / max-blocks-per-tick – ile elementów plugin może przetworzyć na jeden tick,
• chunk-per-cycle / regions-per-task – ile chunków/regionów bierze na jedno „podejście”,
• ustawienia kolejek (queue) – czy plugin może rozkładać operacje na kilka ticków.

Na jednym z serwerów survival problemem był plugin czyszczący nieużywane działki. Zamiast skanu wszystkich działek raz dziennie, ustawiono limit kilkudziesięciu działek na minutę. Cały proces trwał dłużej, ale zniknęły jednosekundowe przycinki.

Zarządzanie światami, chunkami i entity w konfiguracji – współpraca Paper + pluginy

Światy jako „strefy wydajności”

Jeśli serwer ma kilka światów (survival, spawn, eventy, skyblock, resource), można potraktować je jak różne strefy ruchu drogowego. Na autostradzie (resource) pozwalasz na więcej „hałasu” – generowanie, farmy, moby. W centrum miasta (spawn) wszystko ma być lekkie i przewidywalne.

W praktyce oznacza to dwa ruchy:

• różne ustawienia światów w paper.yml/spigot.yml (jeśli używasz per-world configów przez pluginy lub forki),
• per-world konfiguracje pluginów (większość dużych wtyczek – działki, questy, minigry – to posiada).

Przykład: świat spawn – wyłączasz tam naturalny spawn mobów (Bukkit), limitujesz ilość entity dekoracyjnych (ramki, armor standy), a pluginy do ekonomii i minigier ustawiasz tak, by działały tylko tam i w jednym dodatkowym świecie eventowym. W survivalu odwrotnie – mniej „gadżetów”, za to pełnia mechanik gry.

Kontrola chunków – kiedy naprawdę trzeba, żeby wszystko było załadowane

Chunk załadowany to chunk, który „kosztuje” CPU i pamięć. Pluginy potrafią podtrzymywać chunk przy życiu przez różne mechanizmy: spawnery, NPC, block-entity (skrzynie, lejki), a nawet sztucznie „chunkloadery”. Jeśli kilka systemów robi to samo, świat puchnie.

Do przeglądu użyj dwóch narzędzi:

• mapa online/menedżer regionów (np. Dynmap, BlueMap) – pokaże, gdzie są duże skupiska budowli i farm,
• pluginy do statystyk chunków – liczą ilość entity, tile-entity, czas ticka na chunk.

Następnie przejrzyj configi pluginów:

• pluginy od działek/schematek – czy trzymają chunk załadowany, gdy nikogo nie ma w pobliżu?
• pluginy z NPC – czy NPC wymuszają chunkload, czy „śpią”, gdy świat jest pusty?
• maszyny/farmy z pluginów technicznych – czy oferują tryb „offline”, który nie wymaga załadowanego chunku?

Czasem wystarczy wyłączyć podtrzymywanie chunków dla kilku farm na odległym świecie, by TPS-y w godzinach szczytu wróciły do normy.

Limity entity – globalne vs pluginowe

Paper i Spigot umożliwiają ustawianie globalnych limitów entity (spawn, aktywacja, tickowanie). Część pluginów dokłada swoje, bardziej szczegółowe – np. maksymalna liczba mobów w obszarze działki, arena minigry z limitem potworów, „cap” dla zwierząt na gracza.

Jeśli te dwa światy nie są zgrane, pojawiają się dziwne efekty: plugin próbuje spawnować moby, ale globalny limit już został osiągnięty, więc „nic się nie dzieje”. Z perspektywy gracza mechanika wydaje się zepsuta, a serwer i tak dokłada sobie pracy przez nieudane próby spawnu.

Dobry schemat działania:

1. Najpierw ustaw rozsądne limity globalne w bukkit.yml/spigot.yml (ilość mobów, aktywacja, merge itemów).
2. Później w pluginach dopasuj limity tak, aby były niższe niż globalne (czyli plugin kontroluje „lokalnie” ilość mobów, zanim system dojdzie do globalnego maksimum).
3. Na koniec przetestuj areny/eventy, gdzie specjalnie potrzebujesz większych ilości mobów – tam warto mieć osobne światy z inną konfiguracją.

Na jednym serwerze PvE wystarczyło zmniejszyć lokalne limity mobów na działkach w pluginie działkowym, żeby globalny limit przestał być osiągany co chwilę. Gracze nadal mieli „wystarczająco dużo” potworów do expienia, a serwer odetchnął.

Entity specjalne: armor standy, ramki, zwierzaki

Wiele serwerów jest „zabijanych” nie przez potwory, ale przez dekoracje i pupile. Armor standy z custom modelami, ramki, zwierzaki z pluginów kosmetycznych – to wszystko są entity. Każde z nich tickuje, ma kolizję, potrafi brać udział w eventach.

Jeśli masz pluginy kosmetyczne, przejrzyj ich configi pod kątem:

• limitów na gracza (ile petów, ilu NPC asystentów, ile hologramów),
• wygaszania entity po czasie nieaktywności gracza (pet wraca do „pokeballa”, hologram znika),
• opcji łączenia hologramów lub przerzucenia części z nich na mapy/tablice zamiast entity.

Dobrym ruchem jest też włączenie logowania lub inspekcji entity (np. komendy typu /lagg chunk, /tpsentity w narzędziowych pluginach), żeby zobaczyć, kto i gdzie ma „zoo”. Potem można tam podziałać konfiguracją lub polityką serwera.

Profilowanie serwera: jak znaleźć pluginy, które naprawdę hamują Paper/Bukkit

Wbudowane raporty Paper – szybka diagnoza bez dodatkowych narzędzi

Paper ma kilka przydatnych komend diagnostycznych. Jeśli serwer ma spadki TPS, zacznij od wbudowanych narzędzi zamiast na chybił trafił wyłączać pluginy. To jak podpięcie auta pod komputer, zanim zaczniesz wymieniać pół silnika.

Podstawowe rzeczy, które warto znać:

• /tps – aktualny i uśredniony TPS, czas trwania ticków, informacje o obciążeniu.
• /mspt (lub podobna komenda, zależnie od wersji) – ms per tick, ile realnie trwa pojedynczy tick.
• /timings on, krótkie obciążenie, potem /timings report – generuje link z dokładnym raportem (eventy, taski, pluginy).

Przy robieniu timingsów warto odtworzyć typowe obciążenie: godzina szczytu, areny w użyciu, gracze na spawnie. Raport z pustego serwera rzadko pokaże cokolwiek sensownego.

Czytanie raportu timings – na co patrzeć w praktyce

Raport timings potrafi być przytłaczający, ale do wyłapania problematycznych pluginów wystarczy kilka kolumn. Skup się na:

• łącznym czasie wykonania (Total time) danego eventu/tasku,
• udziale procentowym w czasie ticka (Pct of tick),
• liczbie wywołań na sekundę (lub na raport).

Jeśli widzisz, że jakiś plugin ma drobne zadanie, które uruchamia się setki razy na sekundę i zjada kilka procent ticka – to pierwszy kandydat do korekty configu. Jeszcze bardziej podejrzanie wygląda pojedynczy task, który ma bardzo mało wywołań, ale za to ogromny czas jednego wykonania.

Do kompletu polecam jeszcze: Maksymalna wydajność serwera Minecraft na Paper krok po kroku — znajdziesz tam dodatkowe wskazówki.

Kilka typowych przykładów z timingsów:

• ciężki PlayerMoveEvent lub BlockBreakEvent – wtyczki zabezpieczające, działki, loggery; trzeba ograniczyć ich zakres świata lub funkcje,
• task „save-all” pluginu ekonomii działający co kilkadziesiąt sekund – zmiana interwału i/lub przerzucenie na async pozwala odetchnąć,
• ogromny czas w sekcji „Chunk Load/Save” – skupić się na pluginach intensywnie używających IO, regionów i sprawdzić ich ustawienia.

Zewnętrzne profilery i narzędzia serwerowe

Gdy wbudowane timingsy nie wystarczają, przydają się zewnętrzne narzędzia. Nie trzeba od razu odpalać pełnego profilera Javy, czasem wystarczy kilka prostych dodatków i monitorów systemowych.

Pomocne są m.in.:

• menedżery zasobów na maszynie (htop, monitor systemowy) – pokazują skoki CPU, IO, pamięci,
• pluginy typu „lag monitor” – wysyłają ostrzeżenia, kiedy tick przekracza określony czas i wskazują, co wtedy się działo,
• profilery JVM (YourKit, VisualVM, Flight Recorder) – dla bardziej technicznych adminów, gdy trzeba zobaczyć, które metody „palą” CPU.

Dla większości serwerów community wystarczą jednak timingsy + rozsądne testy obciążeniowe. Pełne profilery przydają się głównie wtedy, gdy problem wynika z konkretnego buga w pluginie lub niestandardowych modyfikacji.

Metoda „po kolei” – bez chaosu w wyłączaniu pluginów

Czasem, mimo raportów, winowajca nadal nie jest oczywisty. Zamiast wyłączać wszystko naraz, lepiej zastosować metodę „po kolei” – ale z głową:

1. Zrób kopię świata i configów na serwer testowy.
2. Podziel pluginy na grupy: core (niezbędne do startu), rozgrywka (działki, ekonomia, minigry), kosmetyka (pet-y, efekty), narzędzia/admin.
3. Wyłącz jedną grupę naraz, przeprowadź krótki test obciążeniowy, wygeneruj timings.
4. Jeśli różnica jest duża – zawęź szukanie do pluginów z tej grupy, wyłączając pojedynczo lub po kilka.

Taka metoda jest nudniejsza niż „wyłącz wszystko, co wygląda podejrzanie”, ale pozwala zachować porządek. Gracze też mniej cierpią, bo nie znikają im nagle wszystkie mechaniki na głównym serwerze bez wyjaśnienia.

Współpraca z twórcami pluginów

Kiedy znajdziesz plugin, który wyraźnie hamuje serwer, nie zawsze pierwszą opcją musi być jego wyrzucenie. Jeśli wtyczka jest aktywnie rozwijana, często wystarczy:

• przekazać autorowi link do raportu timings z opisem sytuacji,
• zapytać na kanale wsparcia o rekomendowaną konfigurację pod duże serwery,
• zaktualizować do wersji dev, w której problem bywa już częściowo rozwiązany.

Często autorzy wtyczek mają gotowe zestawy ustawień „low performance” lub wskazówki typu: „jeśli masz ponad X graczy, wyłącz opcję Y i zmniejsz interwał Z”. Takie informacje rzadko trafiają do oficjalnych opisów, ale na Discordzie czy GitHubie pojawiają się regularnie.

Testy przed wdrożeniem – staging nie tylko dla dużych sieci

Nawet mały serwer z kilkudziesięcioma graczami skorzysta na prostym środowisku testowym. Druga instancja serwera na tej samej maszynie (lub innej), kopia pluginów i światów – i można sprawdzić, jak nowe ustawienia zachowują się pod wykreowanym obciążeniem.

Jak to wykorzystać w praktyce:

Najczęściej zadawane pytania (FAQ)

Jakie pluginy najbardziej obniżają TPS na serwerze Paper/Bukkit?

Najczęściej serwer „katują” pluginy, które non stop coś skanują lub logują: rozbudowane logger-y bloków, antycheaty z dziesiątkami checków co tick, stare pluginy do regionów skanujące teren, rozbudowane systemy questów sprawdzające stan świata co sekundę. Każdy taki dodatek dokłada swoje zadania do każdego ticka.

Drugą grupą są wtyczki generujące mnóstwo entity albo chunków: automatyczne farmy-maszyny, losowe teleporty, generator-y świata z dziwnymi biome’ami, rozbudowane minigry w głównym świecie. Jeśli plugin masowo tworzy moby, dropi itemy lub ciągle ładuje nowe chunk-i, TPS prędzej czy później spadnie.

Jak sprawdzić, który plugin powoduje lagi TPS na serwerze Paper?

Najprościej użyć wbudowanych narzędzi: na Paper komenda /timings report generuje raport, w którym widać, które pluginy i eventy zajmują najwięcej czasu w ticku. Jeśli jeden plugin nagle wyskakuje na szczyt listy z dużym procentem obciążenia, masz pierwszego podejrzanego.

Dobrym nawykiem jest też testowanie „na żywo”: na kopii serwera wyłączasz po kolei cięższe wtyczki (lub grupami), obserwujesz TPS i czas ticka, a potem stopniowo je włączasz z powrotem. To trochę jak odpinanie bezpieczników w domu – szybko widać, który obwód robi zwarcie.

Jak ustawić paper.yml i spigot.yml, żeby odciążyć entity i chunki?

Podstawowy krok to obniżenie zasięgu symulacji i ograniczenie entity. W praktyce oznacza to zmniejszenie simulation-distance w paper.yml i korektę zasięgów wyszukiwania oraz aktywności mobów w spigot.yml. Gracz nadal wszystko widzi, ale serwer mniej „myśli” za jego plecami.

Warto też:

• ustawić limity ilości mobów na chunk i world,
• skrócić czas życia leżących itemów (o ile gameplay na to pozwala),
• ustawić agresywniejsze „culling” entity, czyli usypianie tych, które są daleko od graczy.

Dobrze ustawiony Paper potrafi utrzymać 20 TPS z tym samym zestawem wtyczek, przy którym domyślny config ledwo zipie.

Czy więcej RAM i mocniejszy procesor rozwiąże problemy z lagami bez optymalizacji pluginów?

Dodatkowy RAM i lepszy CPU pomagają, ale jeśli konfiguracja pluginów jest kompletnie chaotyczna, to i tak będziesz gasić pożary. Serwer Minecraft jest głównie jednowątkowy – jeśli jeden tick jest przeładowany zadaniami z wtyczek, nawet szybki procesor tylko trochę opóźni katastrofę.

Sprzęt daje „sufit możliwości”, a konfiguracja decyduje, czy faktycznie do tego sufitu dobijasz. Często na sensownym hostingu da się wyciągnąć stabilne 19–20 TPS tylko przez sprzątnięcie listy pluginów, wyłączenie dubli i przykręcenie najcięższych opcji, bez ruszania maszyny.

Jak wybierać pluginy, żeby nie zabić wydajności serwera survival?

Zacznij od listy funkcji, a nie od katalogu pluginów. Spisz, czego naprawdę potrzebujesz: regiony, ekonomia, rangi, prosty anti-cheat, podstawowe komendy (home, tpa, spawn). Dopiero do tej listy dobieraj konkretne wtyczki. Dzięki temu nie lądujesz z pięcioma „kombajnami”, które robią to samo na trzy różne sposoby.

Unikaj dublowania kategorii: jedno economy, jeden główny plugin do czatu, jeden system regionów. Jeśli potrzebujesz dodatkowych funkcji, szukaj lekkich „mostków” lub dodatków zamiast instalować drugi pełny system. Każdy kolejny plugin łapiący te same eventy (np. niszczenie bloku) to dodatkowe milisekundy w ticku.

Jak rozpoznać, czy plugin jest dobrze zoptymalizowany przed instalacją?

Na start rzuć okiem na kilka rzeczy: częstotliwość aktualizacji, obecność changelogów, reakcje autora na zgłoszenia lagów w komentarzach oraz to, czy plugin ma wsparcie dla Paper/Spigot (a nie tylko „gołego” Bukkita). Jeśli od dawna nie było aktualizacji, a ostatnie recenzje narzekają na spadki TPS, to czerwone światło.

Pomaga też prosta praktyka: testuj na osobnym serwerze. Podłącz kilka znajomych, zrób scenariusz obciążenia (np. latanie elytrą, kopiowanie regionów, używanie funkcji pluginu), odpal /timings i zobacz, jak wtyczka zachowuje się pod presją. Lepiej spędzić godzinę na testach niż później tydzień na ratowaniu produkcyjnego serwera.

Co lepiej wyłączyć w pluginach i konfiguracji, zamiast dokładać kolejne optymalizatory?

Najmniejszym kosztem zyskujesz na wyłączeniu zbędnego logowania i statystyk, które i tak nikt nie czyta: szczegółowe logi każdego bloku, bardzo dokładne logi czatu, debug-mode włączony „na zawsze”. Każdy taki wpis na dysk to dodatkowe I/O, które potrafi przyblokować główny wątek.

Dobrym kandydatem do odchudzenia są też:

• zbyt częste taski „co 1 tick”, które spokojnie mogą działać co 10–20 ticków,
• mało używane moduły w dużych pluginach (często da się je wyklikać w configu),
• nadmiarowe checki w anti-cheacie, szczególnie te najcięższe obliczeniowo.

Zamiast dokładać kolejną „magiczna wtyczkę do optymalizacji”, lepiej po prostu wyciszyć to, co niepotrzebnie hałasuje w tle.

Najważniejsze wnioski

• Wydajność serwera to efekt współpracy czterech filarów: sprzętu, silnika (Bukkit/Spigot/Paper), dobranego zestawu pluginów oraz ich konfiguracji; zaniedbanie któregokolwiek z nich kończy się lagami, niezależnie od „mocnego” hostingu.
• Największe „pożeracze” TPS to entity, chunki, operacje dyskowe oraz baza danych – im więcej mobów, generowania świata, zapisów na dysk i zapytań SQL w głównym wątku, tym łatwiej serwer spada poniżej 20 TPS.
• Paper daje zdecydowanie najszersze możliwości optymalizacji: dodatkowe haki dla pluginów, lepszą kontrolę nad entity i chunkami oraz dziesiątki opcji w paper.yml, dzięki czemu ten sam zestaw wtyczek może działać znacznie lżej niż na „gołym” Bukki‑cie.
• Konfiguracja – pliki paper.yml, spigot.yml, bukkit.yml plus configi najcięższych pluginów – potrafi diametralnie zmienić odczuwalną płynność; jeden serwer na tym samym sprzęcie może dusić się przy 12 TPS albo trzymać stabilne 20 TPS, wyłącznie dzięki zmianie ustawień.
• Źródłem problemów są często konkretne wtyczki i ich taski co tick (logger, regiony, anti-cheat), dlatego trzeba regularnie analizować timings i logi, a potem: ograniczać częstotliwość zadań, przerzucać zapisy na tryb asynchroniczny i wyłączać zbędne funkcje.
• Dobór pluginów powinien wynikać z celu serwera (survival, skyblock, minigry), a nie z listy „modnych” dodatków; im bardziej spójny i przemyślany zestaw, tym mniej konfliktów, skanów całych światów i nadmiarowych obliczeń w każdym ticku.