Ile RAM potrzeba dla serwera Minecraft

Pytanie "ile ramu przydzielić pod serwer" zadawane jest częściej niż jakiekolwiek inne. I odpowiedź prawie zawsze jest jedna: "zależy od sytuacji". Ale to nie jest pomoc, tylko wymówka. Rozłóżmy to po ludzku - z liczbami, tabelami i konkretnymi rekomendacjami.

Podstawowe wymagania: vanilla vs mody

Serwer Minecraft na czystej vanilli w 1.20+ przy starcie zjada około 1-1.5 GB pamięci operacyjnej. To bez ani jednego gracza - po prostu ładowanie świata, spawn-chunki, podstawowe systemy.

Paper/Spigot optymalizują zużycie i przy tych samych warunkach mieszczą się w 800 MB - 1.2 GB. Różnica nie ogromna, ale rośnie z obciążeniem.

Forge z 30-50 modami startuje od 2-3 GB. Ciężkie modpacki typu All the Mods 9 lub FTB Revelation spokojnie proszą 4-6 GB tylko na start. Fabric gdzieś pośrodku - startowe zużycie bliższe Paperowi, ale z modami typu Create czy Sodium obciążenie rośnie odczuwalnie.

Pierwsza zasada: licz od startowego zużycia, a nie od zera. Serwer, któremu potrzeba 2 GB na start, przy 20 graczach wymagać będzie zupełnie innych liczb niż ten, który startuje z 800 MB.

Obliczenie RAM na gracza

Uniwersalnej formuły nie ma, ale są sprawdzone przybliżone wartości.

Dla Paper/Spigot:

Każdy gracz dodaje około 50-80 MB do zużycia
Załadowane chunki to główny konsument, około 10-15 MB na chunk w pamięci
Standardowy view-distance=10 oznacza 441 chunków na gracza (21x21)
Przy view-distance=6 to tylko 169 chunków - różnica prawie 3 razy

Dla Forge/Fabric z modami:

Na gracza idzie od 100 do 300 MB w zależności od modpacka
Mody z własnymi światami (RFTools Dimensions, Compact Machines) mogą ostro zwiększyć zużycie
Tile-entity od technicznych modów (Applied Energistics, Mekanism) są bardzo żarłoczne

Tabela rekomendacji

Graczy	Paper/Spigot	Forge (lekki)	Forge (ciężki)	Fabric + mody
1-5	2-3 GB	4-5 GB	6-8 GB	3-4 GB
5-15	3-5 GB	5-7 GB	8-10 GB	4-6 GB
15-30	5-7 GB	7-10 GB	10-14 GB	6-8 GB
30-50	7-10 GB	10-14 GB	14-18 GB	8-12 GB
50-100	10-14 GB	-	-	12-16 GB
100+	14-20 GB	-	-	-

Forge z ciężkimi modpackami źle się skaluje powyżej 30 graczy. To nie ograniczenie RAM - to jednowątkowość Javy. Ale o tym dalej.

Te liczby są dla standardowych ustawień. Jeśli zmniejszyłeś view-distance do 6, wyłączyłeś entity-tracking dla mobów poza 48 blokami i skonfigurowałeś Paper na agresywne wyładowywanie chunków - można zmniejszyć o 20-30%.

Dlaczego więcej RAM nie zawsze oznacza lepiej

Wielu myśli: "kupię 32 GB, przydzielę wszystko pod serwer, będzie latać". W praktyce tworzy to problem gorszy niż brak pamięci - długie pauzy garbage collectora.

Java używa garbage collectora (GC) do czyszczenia nieużywanej pamięci. Przy standardowym G1GC, który jest używany w Minecraft, collector okresowo przechodzi przez całą przydzieloną pamięć i usuwa obiekty, do których nikt się nie odwołuje.

Im większa kupa (heap) - tym dłużej trwa to przejście. Przy 32 GB major GC może zajmować 2-5 sekund. W tym czasie serwer zamiera. TPS spada. Gracze widzą lagi. Wszystko stoi, póki GC nie skończy pracy.

Przy 8-12 GB pauzy GC zwykle mieszczą się w 50-150 ms - gracze nawet nie zauważają. To kluczowy moment: lepiej mieć wystarczająco pamięci, niż nadmiarowo dużo.

Zasada: przydzielaj o 15-25% więcej niż realnie zużywa serwer pod szczytowym obciążeniem. Nie 2-3 razy więcej.

Flagi Aikar: co to i po co

Aikar (deweloper Papera) zebrał zestaw flag JVM, które optymalizują pracę G1GC konkretnie pod serwery Minecraft. To nie magia - to konfiguracja parametrów garbage collectora pod specyfikę obciążenia.

Dla serwerów z 8 GB i mniej:

java -Xms8G -Xmx8G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=30 \
  -XX:G1MaxNewSizePercent=40 \
  -XX:G1HeapRegionSize=8M \
  -XX:G1ReservePercent=20 \
  -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=15 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar server.jar

Dla serwerów z 12 GB i więcej:

java -Xms12G -Xmx12G \
  -XX:+UseG1GC \
  -XX:+ParallelRefProcEnabled \
  -XX:MaxGCPauseMillis=200 \
  -XX:+UnlockExperimentalVMOptions \
  -XX:+DisableExplicitGC \
  -XX:+AlwaysPreTouch \
  -XX:G1NewSizePercent=40 \
  -XX:G1MaxNewSizePercent=50 \
  -XX:G1HeapRegionSize=16M \
  -XX:G1ReservePercent=15 \
  -XX:G1MixedGCCountTarget=4 \
  -XX:InitiatingHeapOccupancyPercent=20 \
  -XX:G1MixedGCLiveThresholdPercent=90 \
  -XX:G1RSetUpdatingPauseTimePercent=5 \
  -XX:SurvivorRatio=32 \
  -XX:+PerfDisableSharedMem \
  -XX:MaxTenuringThreshold=1 \
  -jar server.jar

Co robią kluczowe flagi:

-Xms i -Xmx takie same - przydziela całą pamięć od razu. JVM nie marnuje zasobów na rozszerzanie kupy
G1NewSizePercent=40 - zwiększa młode pokolenie. Minecraft tworzy masę krótkożyjących obiektów (pakiety, ticki, współrzędne), i duży young gen pozwala zbierać je tanio
G1HeapRegionSize=16M - zwiększone regiony dla dużych kup. Zmniejsza overhead na zarządzanie
MaxGCPauseMillis=200 - docelowy czas pauzy. GC będzie się starać w niego zmieścić, ale to nie gwarancja
InitiatingHeapOccupancyPercent=20 - zaczynać tłową zbiórkę wcześnie, żeby nie dochodzić do emergency collection
AlwaysPreTouch - przy starcie fizycznie przydzielić całą pamięć. Usuwa opóźnienia przy pierwszym dostępie do stron

Ważne: -Xms i -Xmx muszą być takie same. Jeśli ustawisz -Xms2G -Xmx8G, JVM będzie ciągle zmieniać rozmiar kupy, co powoduje dodatkowe opóźnienia.

Paper vs Forge vs Fabric: zużycie pamięci

Paper/Spigot/Purpur

Najoszczędniejsze. Paper agresywnie optymalizuje chunki, byty i tile. Kluczowe ustawienia wpływające na RAM:

paper.yml > max-auto-save-chunks-per-tick - ogranicza jednoczesne zapisywanie
spigot.yml > view-distance - główna dźwignia zarządzania pamięcią
paper.yml > delay-chunk-unloads-by - jak szybko wyładowywać nieużywane chunki

Przy prawidłowej konfiguracji Paper w 6 GB normalnie obsługuje 30 graczy.

Forge

Serwery Forge zjadają więcej pamięci z powodu modów. Każdy mod dodaje swoje klasy, rejestry, tile-entity. Kilka konkretnych przykładów:

Applied Energistics 2 z dużą siecią ME - do 500 MB dodatkowo
Mekanism z pełnym łańcuchem produkcji - 200-400 MB
Tworzenie niestandardowych wymiarów (RFTools) - do 1 GB na wymiar
Dynmap/BlueMap - 500 MB-2 GB w zależności od wyrenderowanego obszaru

Fabric

Fabric sam w sobie jest lekki - w zasadzie jest to loader modów. Zużycie zależy całkowicie od zainstalowanych modów. Lithium i Starlight zmniejszają zużycie. Create i techniczne mody zwiększają. Średnio Fabric jest o 15-25% oszczędniejszy od Forge przy porównywalnym zestawie modów.

Swap i OOM-killer

Swap

Swap (plik wymiany) to przestrzeń dyskowa, którą system używa jako "zapasową" pamięć. Dla serwera Minecraft swap to katastrofa. Kiedy JVM zaczyna używać swapu, wydajność spada 100-1000 razy w porównaniu do RAM.

Rekomendacje:

Nie licz na swap jako źródło pamięci dla serwera
Trzymaj swap dla procesów systemowych, ale skonfiguruj swappiness:

# Obecna wartość
cat /proc/sys/vm/swappiness

# Ustaw niski swappiness (preferować RAM, nie swap)
sudo sysctl vm.swappiness=10

# Zachowaj przy restarcie
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

Przy swappiness=10 system będzie używać swap tylko w ostateczności. To znaczy, że proces Javy zostanie w RAM, a nie pojedzie na dysk.

OOM-killer

Kiedy systemowi zupełnie brakuje pamięci, jądro Linux uruchamia OOM-killera, który zabija proces z największym zużyciem RAM. Zwykle to twój serwer Minecraft.

Oznaki działania OOM-killera:

# Sprawdzić, czy proces był zabijany
dmesg | grep -i "out of memory"
dmesg | grep -i "oom-kill"

# Zobaczyć obecny OOM-score procesu
cat /proc/$(pidof java)/oom_score

Ochrona przed OOM:

Nie przydzielaj serwerowi więcej niż 80% dostępnego RAM na maszynie
Zostaw 1-2 GB dla systemu, cache dyskowego i innych procesów
Jeśli na VPS 8 GB - przydzielaj serwerowi maksimum 6 GB

Przykład: VPS z 16 GB RAM. System i podstawowe serwisy zjadają ~1 GB. Cache dyskowy prosi ~1-2 GB. W sumie pod Minecraft można oddać 12-13 GB.

Monitoring RAM przez spark

spark to profiler dla serwerów Minecraft, który pokazuje realne zużycie pamięci w szczegółach. Zainstaluj go jako plugin (Paper) lub mod (Forge/Fabric).

Podstawowe komendy:

/spark health         - ogólne informacje o serwerze
/spark heapdump       - pełny dump kupy do analizy
/spark heapsummary    - krótkie podsumowanie zużycia pamięci
/spark gc             - statystyki garbage collectora

Na co zwracać uwagę:

Częstotliwość GC: jeśli minor GC dzieje się co 2-3 sekundy - wszystko normalnie. Jeśli major GC częściej niż raz na minutę - pamięci mało lub young gen za mały.

Czas pauz GC: minor GC powinien mieścić się w 10-50 ms. Major GC - w 100-300 ms. Jeśli major GC zajmuje więcej niż 500 ms - kupa za duża albo ustawienia GC nieoptymalne.

Heap usage po GC: jeśli po major GC używane jest więcej niż 80% kupy - pamięci realnie nie wystarcza. Czas zwiększyć lub zoptymalizować.

Top konsumentów: heapsummary pokaże, jakie obiekty zajmują najwięcej miejsca. Często to chunki, Entity, TileEntity lub dane pluginów/modów.

Automatyczny monitoring:

/spark health --memory

Ta komenda pokazuje obecne zużycie, szczytowe za sesję i średnie. Zapisuj wskazania przy szczytowym online - to jest twój realny punkt odniesienia do przydziału RAM.

Kiedy potrzebne jest więcej CPU, a nie RAM

To częsty błąd: serwer lagaje, administrator dodaje RAM, ale nic się nie zmienia. Bo problem był w procesorze.

Serwer Minecraft jest jednowątkowy w głównej pętli tickowej. Jeden tick = 50 ms (20 TPS). Jeśli tick nie zdąży w 50 ms - TPS spada. A RAM nie ma tu nic do rzeczy.

Symptomy braku CPU:

TPS poniżej 20, ale RAM używany na 50-60%
spark profiler pokazuje, że główny czas jest w entityTick, chunkTick lub pluginTick
Dodawanie RAM nie wpływa na TPS

Symptomy braku RAM:

Częste i długie pauzy GC
TPS okresowo spada do 0-5 na sekundę-dwie, potem wraca
spark gc pokazuje major GC co 10-30 sekund
Serwer crashuje z OutOfMemoryError

Co robić, jeśli problem jest w CPU:

Przejść na hosting z szybszym jednordzeniowym procesorem (częstotliwość taktowania ważniejsza od liczby rdzeni)
Zmniejszyć view-distance (to zmniejsza i obciążenie CPU, i RAM)
Optymalizować pluginy/mody - niektóre są bezbożnie ciężkie w pętli tickowej
Używać Paper/Purpur zamiast Spigot - wiele operacji wyniesionych do asynchronicznych wątków

Praktyczne rady

Zacznij od małego. Postaw 4 GB, obserwuj przez spark tydzień. Zwiększaj o 2 GB, jeśli trzeba
-Xms = -Xmx. Zawsze. Bez wyjątków
Nie zapominaj o systemie. JVM nie jest jedynym procesem na maszynie
View-distance to najpotężniejsza dźwignia. Zmniejszenie z 10 do 7 oszczędza do 40% RAM
Pregeneruj świat. Generacja chunków na żywo to droga operacja i po CPU, i po RAM
Restartuj raz na dobę. Serwery Javy mają skłonność do wycieków pamięci przez pluginy. Dzienny restart o 5 rano przy minimalnym online to norma
Monitoruj, nie zgaduj. spark jest darmowy. Używaj go