Dla małego serwera Paper zacznij zwykle od 3-4 GB sterty Java, ale nie kupuj pamięci wyłącznie na podstawie liczby slotów. Światy, pluginy, liczba aktywnych graczy, generowanie chunków i częstotliwość garbage collectora trzeba zmierzyć podczas prawdziwej gry.
Najważniejsze konkrety
- 1-5 graczy
- Paper z kilkoma pluginami: zacznij od 3-4 GB Xmx i zmierz użycie podczas wspólnej gry.
- 5-15 graczy
- Najczęstszy punkt startowy to 4-6 GB Xmx, zależnie od świata, pluginów i dystansu symulacji.
- Zapas
- Nie ustawiaj Xmx na pełny limit hostingu; zostaw zwykle 15-25% na JVM, pamięć poza stertą i narzut środowiska.
- Nie tylko RAM
- Niski TPS przy wolnym głównym wątku wymaga szybszego CPU lub optymalizacji, nie kolejnych gigabajtów.
Ile RAM na serwer Minecraft? Tabela punktów startowych
Nie istnieje przelicznik „liczba slotów × RAM”. Sloty są tylko limitem logowania, a pamięć zużywają między innymi załadowane chunki, encje, dane pluginów, pamięć podręczna, generowanie świata i sami aktywni gracze. Poniższe wartości to rozsądne punkty startowe dla Paper, nie gwarancja wydajności.
| Scenariusz | Punkt startowy Xmx | Co sprawdzić pod obciążeniem |
|---|---|---|
| 1-5 graczy, kilka lekkich pluginów | 3-4 GB | Generowanie nowych chunków, teleporty i pierwszy pełny backup |
| 5-15 graczy, typowy Survival | 4-6 GB | Farmy, aukcje, mapy internetowe i godzina największego ruchu |
| 15-30 graczy, rozbudowane pluginy | 6-8 GB | Pauzy GC, liczba światów, encje, placeholdery i bazy danych pluginów |
| Powyżej 30 graczy lub ciężki modpack | 8 GB i więcej po teście | Osobny profil dla szczytu; modpack licz według jego dokumentacji i realnego zestawu modów |
Jeżeli pięciu graczy stoi na spawnie, zużycie będzie inne niż wtedy, gdy każdy leci elytrą w innym kierunku i generuje teren. Dlatego dobór kończy się dopiero po teście odpowiadającym prawdziwemu stylowi gry.
Co faktycznie zużywa pamięć serwera?
Światy i chunki. Każdy załadowany fragment świata przechowuje bloki, encje i dane potrzebne do symulacji. Więcej światów, wysoki view-distance, wysoki simulation-distance i gracze rozrzuceni po mapie zwiększają jednoczesny zestaw danych w pamięci.
Pluginy. Liczba JAR-ów nie mówi wszystkiego. Prosty plugin z komendą może być lekki, a mapa internetowa, system skryptów, rozbudowany antycheat lub źle napisany cache potrafi przechować znacznie więcej danych. Po zmianie zestawu pluginów pomiar trzeba powtórzyć.
Generowanie świata i encje. Nowe chunki obciążają przede wszystkim procesor i dysk, ale powiększają też zbiór aktywnych danych. Farmy z tysiącami przedmiotów, zwierząt lub lejów mogą jednocześnie podnieść MSPT i zużycie pamięci. Więcej RAM nie zwalnia z usunięcia źródła nadmiernej liczby encji.
Xms, Xmx i zapas poza stertą
-Xms ustawia początkowy rozmiar sterty Java, a -Xmx jej maksymalny rozmiar. Aktualna dokumentacja Paper pokazuje prosty start z 4 GB:
java -Xms4G -Xmx4G -jar paper.jar --noguiNa dedykowanej maszynie równe Xms i Xmx dają przewidywalny rozmiar sterty. W ograniczonym kontenerze nadal najważniejsze jest, aby Xmx nie zajmował całego limitu. Proces Java korzysta również z pamięci poza stertą: kodu JVM, buforów bezpośrednich, wątków i bibliotek. Panel hostingu może pokazywać cały proces, a spark tylko wybrane metryki - te liczby nie muszą być identyczne.
Dla limitu 8 GB zacznij zwykle od Xmx 6 GB. Dla 16 GB można testować 12-14 GB. Zostawienie 15-25% limitu zmniejsza ryzyko, że kontener zabije proces mimo wolnego miejsca w samej stercie. Na VPS-ie trzeba dodatkowo zostawić zasoby systemowi, bazie danych i panelowi.
Jak zmierzyć RAM zamiast zgadywać?
Pomiar wykonuj w godzinie największego ruchu albo podczas kontrolowanego testu. Paper 1.21+ zawiera spark. Zacznij od /spark healthreport, a przy lagach zbierz profil:
/spark profiler start --timeout 600Raport ma obejmować moment, w którym gracze generują świat, używają farm i wykonują typowe teleporty. Zapisz liczbę graczy, MSPT, użycie sterty przed oraz po pełnym cyklu garbage collectora i czas przerw GC. Paper wyjaśnia, że rosnąca i opadająca „piła” użycia sterty jest normalna. Sam fakt, że proces wykorzystuje przydzielony RAM, nie oznacza wycieku.
Alarmem jest OutOfMemoryError, zabijanie procesu po przekroczeniu limitu kontenera, bardzo długie lub częste pauzy GC albo użycie, które po kolejnych pełnych cyklach GC stale rośnie przy porównywalnym obciążeniu. Wtedy najpierw ustal, który plugin lub typ danych rośnie. Polecenie /paper heap tworzy duży zrzut do analizy i nie powinno być pierwszym odruchem na produkcji.
Kiedy problemem jest CPU, a nie RAM?
Serwer może mieć 20 GB wolnej pamięci i nadal lagować. Główna pętla gry musi zakończyć tick w 50 ms, aby utrzymać 20 TPS. Jeśli spark pokazuje wysokie MSPT przez generowanie chunków, plugin, sztuczną inteligencję mobów lub farmę, zwiększenie Xmx nie skróci tej pracy.
- Niski TPS, wolna sterta: szukaj pracy głównego wątku, wolnego rdzenia CPU, pluginów, encji i chunków.
- Dobry TPS, błąd OOM: sprawdź limit kontenera, Xmx, pamięć poza stertą i rosnące dane pluginów.
- Długie pauzy co pewien czas: porównaj wykres GC, zapis świata, backupy i zadania okresowe.
- Lag jednego gracza: sprawdź ping i trasę sieciową; RAM serwera zwykle nie jest przyczyną.
Jak ograniczyć zużycie bez psucia rozgrywki?
Zacznij od usunięcia nieużywanych światów i pluginów oraz aktualizacji dodatków z potwierdzonym problemem. Ustaw world border i wygeneruj teren przed premierą, aby gracze nie tworzyli wielu nowych chunków jednocześnie. Dostosuj view-distance i simulation-distance małymi krokami, mierząc wpływ na MSPT i doświadczenie graczy.
Nie kopiuj gotowej konfiguracji „optymalizacyjnej” bez sprawdzenia zmian w mechanice. Ograniczenie mobów, zasięgu symulacji lub częstotliwości ticków może poprawić metrykę kosztem farm i zasad Survival. Wprowadzaj jedną grupę ustawień, zapisuj wynik i zachowuj możliwość cofnięcia.
Przykład: hosting z limitem 8 GB
- Rezerwujesz 2 GB na narzut JVM, bufory i bezpieczny margines kontenera.
- Ustawiasz
-Xmx6G; Xms dobierasz do środowiska, np. 4-6 GB. - Uruchamiasz test z docelową liczbą graczy, generowaniem terenu i typowymi pluginami.
- Zbierasz healthreport oraz profil, a wynik porównujesz z MSPT i logami.
- Jeśli sterta ma zapas, lecz MSPT przekracza 50, nie kupujesz RAM w ciemno - diagnozujesz pracę głównego wątku.
Własny serwer uruchomisz według poradnika instalacji Paper, a interpretację raportu znajdziesz w instrukcji diagnozy spark. Referencją dla zachowania pamięci pozostaje dokumentacja rozwiązywania problemów PaperMC.
Plan działania krok po kroku
- 1
Ustal limit pamięci hostingu i odejmij 15-25% zapasu; otrzymaną wartość potraktuj jako górny punkt startowy dla Xmx.
- 2
Uruchom serwer z kontrolowaną wartością Xmx i odtwórz typowe obciążenie: gracze, teleporty, generowanie świata, farmy i eventy.
- 3
Zbierz /spark healthreport oraz profil podczas szczytu, sprawdzając stertę, garbage collector, MSPT i główny wątek.
- 4
Zwiększ pamięć dopiero przy realnej presji na stertę lub OOM; przy niskim TPS bez presji na RAM popraw pluginy, encje, chunki albo CPU.
