Ile pamięci RAM potrzebuje serwer Minecraft?

Uruchamiasz serwer dla znajomych na komputerze z 8 GB RAM. Łatwo wpisać -Xmx8G w pliku startowym: skoro RAM-u jest 8, niech Java też używa 8. Potem przypominasz sobie o Windowsie, przeglądarce, a jeśli zamierzasz grać na tym samym komputerze — także o kliencie Minecraft. Jeszcze nikt nie zdążył się zalogować, a system już nie ma gdzie rozdzielić pamięci. Czasem problem nie leży w serwerze, lecz właśnie w tej jednej linijce.

Na wyniki „Zalecany Java heap” i „Wymagana łączna pamięć RAM” w kalkulatorze patrz osobno. Pierwszego używasz do -Xmx. Drugi mówi, ile RAM powinno znajdować się w komputerze lub wynajętym serwerze. Bez rozdzielenia tych dwóch wartości nie odpowiedziałbym po prostu, że „8 GB wystarczy”. Sama liczba graczy nie wystarcza do takiego wniosku.

Dziesięciu graczy nie zawsze oznacza takie samo obciążenie

Spotkanie przy spawnie a rozproszenie po mapie

W polu liczby graczy wpisuj nie liczbę zarejestrowanych kont, lecz liczbę osób, które będą grały jednocześnie. Gdy 10 osób buduje bazę w pobliżu spawnu, korzystają głównie z tych samych chunków. Sytuacja zmienia się, gdy rozlatują się Elytrą w cztery strony świata. Serwer z jednej strony ładuje nowe obszary, a z drugiej generuje teren, którego nikt wcześniej nie widział. Dziesięciu graczy na początku wieczoru nie musi więc powodować takiego samego obciążenia RAM jak tych samych dziesięciu pod koniec rozgrywki.

Podczas obliczeń patrzę na sposób gry całej grupy. Jeśli wszyscy przebywają głównie w jednym wspólnym obszarze, właściwy będzie wybór „Przeważnie w tym samym obszarze”. Jeśli w świecie Survival każdy rozchodzi się do własnej bazy, bardziej pasuje „W różnych obszarach / nie wiem”. Jeśli dodatkowo dużo eksplorujecie, zaznacz również tę opcję. Kalkulator dodaje wtedy 25 procent do obciążenia związanego z chunkami. Sztuczne zwiększenie liczby graczy do dwudziestu tylko po to, by zachować zapas bezpieczeństwa, ukrywa rzeczywiste źródło różnicy.

Sprawdź również odległość renderowania i symulacji w pliku server.properties. Odległość renderowania określa obszar wysyłany do gracza. Odległość symulacji określa natomiast zakres, w którym działają moby i zdarzenia gry. Po pierwszym otwarciu formularz ustawia odpowiednio 8 i 6 chunków. W obliczeniach dla współczesnych wersji decydująca jest większa z tych dwóch wartości. Jeśli odległość renderowania wynosi 8, a symulację zwiększysz z 6 do 7, wynik RAM może pozostać bez zmian. Tego samego nie można jednak powiedzieć o obciążeniu ticków. W profilu „1.17 i starsze” narzędzie nie uwzględnia odległości symulacji.

Nie oceniaj obciążenia wyłącznie po liczbie pluginów

Dla Paper, Purpur i Spigot podajesz liczbę pluginów oraz ich średnie obciążenie. W przypadku Fabric, Forge i NeoForge do obliczeń wchodzi liczba modów. W Vanilla kalkulator nie korzysta z żadnego z tych dodatkowych pól. Nie traktuj opcji „lekki / średni / ciężki” jako zmierzonego zużycia RAM przez każdy plugin z osobna. Dziesięciu małych pluginów do zarządzania uprawnieniami nie można stawiać na równi z jednym pluginem renderującym mapę w tle.

Przy instalacji modpacka najpierw szukam zalecenia dotyczącego heapu podanego przez paczkę dla serwera. Jeśli je znajdziesz, wpisz je w sekcji „Użyj zalecenia RAM modpacka”. Narzędzie nie zejdzie poniżej tej wartości. Nie przenoś tutaj zaleceń dotyczących klienta. Mówimy o dwóch oddzielnych procesach gry. Jeśli nie potrafisz oszacować obciążenia paczki, porównaj obok siebie wyniki dla „średniego” i „ciężkiego” obciążenia. Różnica między nimi daje więcej informacji o tym, czy potrzebny będzie większy pakiet hostingowy, niż sama liczba modów.

Którą liczbę wpisać w którym miejscu kalkulatora?

Jeśli konfigurujesz nowy serwer, wybierz „Oblicz zapotrzebowanie na RAM”. Jeśli chcesz sprawdzić posiadany komputer, wybierz „Sprawdź mój komputer”. W obu przypadkach obliczenia dotyczące samego serwera są takie same. Najłatwiej przeoczyć wartości początkowe formularza: domyślnie wybrane jest Paper i 10 pluginów. Jeśli w konfiguracji nie masz żadnych pluginów, ustaw 10 na zero. Następnie wpisz wersję, odległość renderowania i w razie potrzeby odległość symulacji zgodnie z ustawieniami własnego serwera. Jeśli planujesz rozbudowane farmy, redstone, mapę internetową lub dodatkowe światy, przejdź do ustawień zaawansowanych. W przeciwnym razie nie zaznaczaj opcji tylko dlatego, że pojawiło się pole wyboru.

Początkowy zapas roboczy wynosi 25 procent. W ustawieniach zaawansowanych możesz zmienić go w zakresie od 10 do 100 procent. Gdy wyłączysz te ustawienia, dodatkowe obciążenia zostaną usunięte z obliczeń, a zapas wróci do 25 procent. Jeśli w jednej próbie zobaczysz 6 GiB, a w drugiej 9 GiB, najpierw sprawdź, które przełączniki były włączone. Zapisz też przy wyniku użyte dane wejściowe. Dzięki temu przy szukaniu źródła różnicy nie trzeba będzie zaczynać od początku.

8 GB to około 7,45 GiB. Jeśli oferta hostingu podaje GB, wybierz w formularzu GB. Jeśli maszyna wirtualna lub container może wykorzystać tylko część fizycznej pamięci RAM, wpisz właśnie tę część jako dostępny limit. Łatwo uznać, że wszystko się zgadza, bo „wpisałem 8 i wyszło 8”. Jeśli jednak po obu stronach wybrałeś różne jednostki, porównanie od początku będzie przesunięte. Jest to szczególnie istotne, gdy wynik znajduje się blisko granicy połowy GiB.

Dwa wyniki RAM widoczne na ekranie

Nie traktuj wartości heap jako całkowitej pojemności maszyny

Java heap to maksymalna ilość pamięci, jaką serwer może wykorzystać na obiekty Java. Łączna pamięć RAM obejmuje również miejsce dla systemu operacyjnego i pamięci używanej przez Javę poza heapem. Kalkulator rezerwuje na to dodatkowe użycie Javy co najmniej 1 GiB. Jeśli 15 procent heapu jest większe, używa tej wartości, a następnie zaokrągla wynik w górę do najbliższych 0,5 GiB. Jeśli na ekranie widzisz 3,5 GiB heapu, wygenerowane -Xmx3584M oznacza tę samą wartość. Wybierając pakiet hostingowy, nie traktuj wartości -Xmx jako całkowitego RAM-u pakietu.

Wypróbuj następującą konfigurację: Paper dla 10 graczy, współczesna wersja, 8 chunków odległości renderowania, 6 chunków odległości symulacji oraz 10 pluginów o średnim obciążeniu. Przy wyłączonych ustawieniach zaawansowanych i Chunky narzędzie podaje 3,5 GiB heapu oraz 6,5 GiB całkowitej pamięci RAM. Na maszynie z Linuxem bez środowiska graficznego i 8 GiB pamięci wymagania mieszczą się w dostępnej pamięci, jeśli nie rezerwujesz dodatkowego zapasu dla innych aplikacji. Teraz uwzględnij Windows i klienta Minecraft działającego na tym samym komputerze. Po wpisaniu 1 GiB dla innych aplikacji i 4 GiB dla klienta całkowite zapotrzebowanie wzrasta do 13,5 GiB. Maszyna z 8 GiB już tutaj nie wystarcza. Nie dodaliśmy nawet jednego pluginu do Paper. RAM zużywają inne procesy.

Funkcja sprawdzania komputera rezerwuje 2 GiB dla Linuxa bez środowiska graficznego, 3 GiB dla Linuxa ze środowiskiem graficznym oraz 4 GiB dla Windows i macOS. W przypadku containera nie dodaje udziału systemu operacyjnego hosta. Jeśli wewnątrz działają inne usługi, ich zużycie RAM trzeba wpisać w sekcji „Inne aplikacje”. Gdy maszyna nie spełnia wymagań, kalkulator nie zmniejsza automatycznie heapu. Wyraźnie pokazuje brakującą ilość pamięci.

Przejście z Vanilla na modpack

Ponownie przyjmijmy 10 graczy i ustawienia 8/6 chunków. W Vanilla wynik to 3 GiB heapu i 6 GiB całkowitej pamięci RAM. Po dodaniu do Paper 10 pluginów o średnim obciążeniu wartości wzrastają do 3,5 i 6,5 GiB. Przykład Fabric z 50 modami o średnim obciążeniu daje 5 i 8 GiB, natomiast przykład Forge — 6 i 9 GiB. Nie interpretowałbym tego jako stwierdzenia, że „Fabric jest zawsze lżejszy od Forge”. Gdy zmieniają się mody zawarte w paczce, zmienia się również porównanie. Liczby pokazują jedynie, jak kalkulator zachowuje się przy tych samych danych wejściowych.

W przykładzie z Paper, jeśli gracze pozostają w tym samym obszarze, zobaczysz 3 GiB heapu i 6 GiB całkowitej pamięci RAM. Jeśli rozproszą się i zaczną odkrywać nowy teren, będzie to 4 i 7 GiB. W obu scenariuszach graczy nadal jest 10. Dlatego nie polegam wyłącznie na poradach typu „tyle RAM na jednego gracza”. Po dodaniu rozbudowanych farm, mapy internetowej, niestandardowego generowania świata i dwóch dodatkowych aktywnych światów ten sam wynik rośnie do 6 GiB heapu oraz 9 GiB całkowitej pamięci RAM. Zamiast włączać wszystkie cztery opcje naraz i patrzeć tylko na końcową wartość, testuj je pojedynczo. Wtedy zobaczysz, które obciążenie najbardziej podnosi wynik.

Obliczenia Chunky a pomiar działającego serwera

W Chunky najpierw wybierasz nazwę świata, punkt centralny, kształt i promień. Dla kwadratu powierzchnia wynosi 4 × promień², a dla koła π × promień². Ponieważ jeden chunk zajmuje 16 × 16 bloków, kalkulator dzieli powierzchnię przez 256. Jeśli środek to 0, 0, a promień kwadratu wynosi 3000 bloków, otrzymasz 140 625 chunków. Jeśli połowa została już wygenerowana, pozostaje 70 313. Po zwiększeniu promienia do 6000 otrzymasz 562 500 chunków. Dodanie 3000 bloków nie oznacza dwukrotnie większej pracy. Powierzchnia rośnie czterokrotnie. Sprawdź jeszcze raz liczbę wpisaną w polu promienia.

Po włączeniu Chunky zalecany heap przykładowego serwera Paper rośnie do 4 GiB, a całkowita pamięć RAM do 7 GiB. Aby oszacować miejsce na dysku i czas, możesz wykonać krótki test generowania. Jeśli wpiszesz 10 000 nowych chunków, wzrost rozmiaru folderu o 256 MiB i czas 300 sekund, dla pozostałych 140 625 chunków zobaczysz szacunkowo około 3,52 GiB miejsca na dysku oraz 1,17 godziny. Prędkość nie musi pozostawać stała przez cały proces generowania świata. Nie uwzględniaj w pomiarze kopii zapasowych ani plików mapy internetowej. Przed wysłaniem polecenia jeszcze raz przeczytaj nazwę świata i promień. Jedno dodatkowe zero wpłynie zarówno na czas, jak i zużycie dysku.

Uruchomiłeś serwer, gracze się rozproszyli, a TPS spadł. Nie zwiększaj od razu -Xmx. TPS to liczba aktualizacji gry na sekundę, natomiast MSPT oznacza liczbę milisekund potrzebnych na wykonanie jednej aktualizacji. Obie wartości możesz sprawdzić poleceniem /spark tps. Jeśli wykonasz profil Spark podczas dużego obciążenia, zobaczysz, czy czas zużywany jest na generowanie świata, czy na plugin. Presję Garbage Collection możesz dodatkowo odczytać z danych GC. Jeśli serwer wyłącza się z błędem OOM, pierwszymi rzeczami do sprawdzenia są limit RAM i -Xmx. Jeśli TPS spada mimo wolnej pamięci, najpierw zajrzałbym do wyników profilera. Dopiero później rozważałbym większy pakiet RAM.