Helios1993 | 2020-11-20 11:28:21 UTC | #1
Nie jestem autorem poradnika, jedynie go odświeżam oraz zmieniam w nim kilka rzeczy. Robię to ze względu na ciągle zmieniającą się grę. Ten poradnik będzie aktualizowany gdy tylko coś się zmieni. Autorem poradnika jest @logixdev, link do oryginału - https://forum.lvlup.pro/t/obszerny-poradnik-dotyczacy-optymalizacji-serwerow-minecraft-1-13/14662/
:zap: Obszerny i kompleksowy poradnik dotyczący optymalizacji serwerów Minecraft
:point_down: Spis treści:
:closedlockwith_key: Jeśli szukasz informacji o zabezpieczeniu swojego serwera, sprawdź inny mój poradnik stale aktualizowany o nowe treści: Kompleksowy poradnik dotyczący bezpieczeństwa serwerów Minecraft .
1. Wprowadzenie
Minecraft jest grą napisaną w języku Java. W celu zoptymalizowania działania należy dołożyć wszelkich starań do kodu klienta gry oraz silnika serwera, aby działała ona wydajnie. Ze względu na otwartość świata w grze i mnogość funkcji często jest to trudne, również jeśli chodzi o serwery. Utrzymanie dużego publicznego serwera wymaga odpowiedniej wiedzy technicznej i mocy obliczeniowej serwera. Ale w tym poradniku postaram się pokazać, że z tej specyfikacji maszyny, którą być może już posiadasz można, a nawet trzeba wycisnąć znacznie więcej!
Serwery oparte na starszych wersjach gry (tj. poniżej 1.13) wymagały mniej zasobów i po prostu działały znacznie lepiej. Dziś na najnowszej wersji utrzymanie dużej ilości graczy na pojedynczej instancji serwera jest praktycznie niemożliwe na znanych silnikach Spigot/PaperSpigot bez ich patchowania, czyli zaawansowanej modyfikacji. Ale spokojnie! Są na to rozwiązania, które możesz wykonać bez większego problemu sam i realnie wpłynąć na wydajność Twojego serwera. Wszystko piszę z perspektywy człowieka z ośmioletnim doświadczeniem w prowadzeniu dużych serwerów Minecraft (+400 osób).
Warto rozgraniczyć też na początku typy lagów, bo często jedno określenie używane jest błędnie do różnych problemów:
2. Wybór specyfikacji serwera i sztywne liczenie zasobów?
Temu tematowi poświęcę nieco mniej uwagi, bo skupiamy się na tym, co możemy zrobić, aby zoptymalizować serwer na tym co już masz. Oczywiście z całego serca polecam usługi hostingu, na którego forum się znajdujesz i mówię to obiektywnie, serio! Z doświadczenia wiem, że znane hostingi serwerów Minecraft stosują tzw. overselling, czyli upychają na jednej maszynie zbyt dużo serwerów klientów przez co są one przeciążone i nie działają płynnie.
:thinking: No dobra, ale oferta jest szeroka, co tu wybrać?
:fr: Oferta FR jest nieco tańsza w odniesieniu do ilości pamięci RAM. Ping będzie większy o około ~ 20-25ms, ale przy serwerze Minecraft ma to małe znaczenie. Dopiero przy pingu wyższym niż 100ms np. na serwerach PvP może być odczuwalna różnica wpływająca na jakość rozgrywki.
:poland: Oferta PL ma mocniejsze procesory (a CPU jest często ważniejsze niż RAM!), szybsze dyski oraz niższy ping.
Ja na publicznej sieci serwerów korzystam z lokalizacji FR i jestem zadowolony. W 99% przypadków Ty też będziesz.
Im więcej vCPU, czyli wątków procesora przypisanych dla Twojej maszyny tym lepiej.
Kiedyś utarł się trochę mit z wyliczaniem pamięci RAM na gracza. Najpierw było to sztywno 64MB, potem nieco więcej. Pamiętajmy, że zapotrzebowanie na pamięć jest zmienne i zależne od np. ilości i typu pluginów, skryptów czy zachowania graczy, dlatego warto zostawić sobie jakiś zapas.
:exclamation: Uwaga! Pamiętaj, żeby nie przypisywać całej dostępnej pamięci RAM na Twoim VPS do serwera Minecraft. System oraz inne usługi na nim uruchomione (jak np. Apache, TeamSpeak 3) również jej potrzebują. Sprawdź zużycie pamięci komendami top lub htop i dostosuj ją odpowiednio. Jeśli masz VPS z 4GB RAM z systemem Ubuntu 18.04 i oprócz jednej instancji serwera Minecraft serwer Apache (swoją drogą możesz zmienić na serwer nginx, który jest mniej zasobożerny), to przypisz do 3GB RAM serwerowi Minecraft, nie więcej! Pamiętajmy też o tym, że zużywanie maksymalnej przypisanej ilości pamięci RAM przez serwer w wielu sytuacjach nie jest powodem do niepokoju, bowiem maszyna wirtualna JVM rezerwuje sobie tę pamięć, a w razie potrzeby zwalnia.
:warning: Pamiętaj, że korzystanie z serwera VPS wymaga wiedzy na temat konfiguracji systemu Linux. Więcej znajdziesz w sekcji poradników na forum .
:speech_balloon: Pss! Jeśli chcesz zamówić swój serwer VPS z 10% rabatem, możesz użyć kodu CRAFTCODE.PL.
3. Zoptymalizowana linia startowa dla serwera Minecraft
Uruchamiając serwer Minecraft korzystamy z technologii Java (najczęściej JDK w wersji 8 lub 11). Wersja 11 może być nieco wydajniejsza od 8, ale za to niektóre pluginy nie są jeszcze z nią kompatybilne. Do uruchomienia serwera możemy użyć prostej komendy, ale lepiej jest użyć dodatkowych, zalecanych flag. Usprawniają one ogólne działanie serwera, ładowanie chunków i są dostosowane pod najnowsze wersje gry.
Dokładna zalecana linia startowa:
java -Xms10G -Xmx10G -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:G1HeapWastePercent=5 -XX:G1MixedGCCountTarget=4 -XX:InitiatingHeapOccupancyPercent=15 -XX:G1MixedGCLiveThresholdPercent=90 -XX:G1RSetUpdatingPauseTimePercent=5 -XX:SurvivorRatio=32 -XX:+PerfDisableSharedMem -XX:MaxTenuringThreshold=1 -Dusing.aikars.flags=https://mcflags.emc.gs -Daikars.new.flags=true -jar paperclip.jar nogui
Tworzymy plik o nazwie np. start.sh w folderze z serwerem i wklejamy powyższą zawartość. Pamiętamy też o nadaniu uprawnień do wykonywania się skryptu komendą chmod +x start.sh. W argumencie Xms oraz Xmx zmieniamy przypisaną ilość pamięci do serwera (z zachowaniem reguł opisanych w poprzednim punkcie). Xms to początkowa ilość, Xmx maksymalna. Nazwę naszego pliku z silnikiem zmieniamy po argumencie -jar. Serwer uruchamiamy komendą ./start.sh.
:thinking: Co dokładnie robią te flagi? Włączają implementację GC pod nazwą G1GC. Służą zminimalizowaniu negatywnych skutków czasu trwania procesu GC, w którym uwalniana jest pamięć (usuwane są niepotrzebne już obiekty). Parametry te mają na celu możliwe zmniejszenie tzw. pause time, który jest odczuwalny w postaci zwyczajnego laga.
Źródło: https://aikar.co/2018/07/02/tuning-the-jvm-g1gc-garbage-collector-flags-for-minecraft/
4. Wybór silnika
Skoro flagi startowe dla silnika mamy już omówione, to pora zastanowić się nad jego wyborem. Pod uwagę bierzemy w zasadzie trzy dostępne publicznie. Czwartym jest Velocity, ale to tak naprawdę nie silnik, a proxy, które spina nam serwery oparte na jednym z trzech silników.
Dlaczego nie ma tu CraftBukkita? Bo jego wsparcie jest już bardzo kiepskie i w zasadzie każdy korzysta jedynie z trzech wymienionych poniżej.
5. Przydatne wtyczki (pluginy) na serwerach, jakie i ile wgrywać, by nie zwariować?
Najpopularniejsze i zarazem najpotrzebniejsze pluginy to:
To na tyle z absolutnych podstaw. Generalnie każdy serwer rządzi się swoimi prawami i potrzebuje inną ilość pluginów. Pamiętajmy jednak, aby korzystać z wtyczek ze sprawdzonych źródeł i autorów (np. korzystanie z pluginów z wycieków ze znanych stron nie jest dobrą opcją). Nie wgrywajmy też masy pluginów, których funkcje się pokrywają.
Istnieją również pluginy do obsługi wielu wersji np. ProtocolSupport czy ViaVersion. Możemy ich używać, ale pamiętajmy, że mogą wpływać na problemy z kompatybilnością u graczy grających na np. starszych wersjach gry. Warto zwrócić też uwagę na formy zapisu danych w pluginach. Rozróżniamy typ zapisu lokalnego w formie plików YAML/JSON i w tym przypadku jeśli metoda jest odpowiednio napisana może być wydajna. Tak samo ma się sprawa przy bazach danych. MySQL, SQLite czy Redis to najpopularniejsze z nich, mają swoje wady i zalety, ale warto zwrócić uwagę na czas dostępu do bazy (jeśli nie jest hostowana lokalnie) oraz klasę od zarządzania bazą w pluginie, na ile jest zoptymalizowana, czy wykonuje zapis asynchronicznie itp. Chwilowy lag na serwerze przy wykonywaniu konkretnych komend może mieć związek właśnie z niezoptymalizowanym zaspiem. Pamiętajmy też o regularnym aktualizowaniu pluginów, gdyż są łatane wszystkie błędy mogące powodować wycieki pamięci itp.
6. A co z tymi skryptami… Lagują czy nie lagują?
Wojna o plugin Skript i to czy jego używanie jest dobre dla serwera czy nie trwa od wielu lat. Nie chcę otwierać tej puszki pandory i powiem tyle. Jeden czy drugi skrypt o podstawowej funkcjonalności jak wywoływanie komend z wiadomością nie zabije nam całkowicie serwera. Ale korzystanie z wielu bardzo rozbudowanych skryptów, które są źle napisane (every tick, on any move, źle zrobione pętle lub brak czyszczenia zmiennych) już nie jest dobrym rozwiązaniem. Jak we wszystkim ważny jest więc zdrowy rozsądek. Problemem Skripta jest przetwarzanie danych w głównym wątku serwera, brak wielowątkowości. Na większych serwerach zdecydowanie nie polecam używać tego pluginu.
7. Timingi, czyli co laguje mój serwer
Zanim przejdziemy do części o konfiguracji silnika warto wspomnieć o timingach, czyli potężnym narzędziu wbudowanym w każdy silnik oparty o Spigota. Pozwala na uzyskanie podstawowych informacji na temat działania naszego serwera. Nie jest to narzędzie idealne, pełny obraz mogą dać jedynie pełnoprawne profilery, ale warto na początku zainteresować się tym narzędziem, bo jest wbudowane w silnik, szybkie i proste w użyciu.
Warto wspomnieć coś o TPS. Czym one są? Główna pętla gry wykonuje 20 cykli (tzw. ticków) w ciągu sekundy i wtedy mamy 20 TPS, wszystko gra. Jeśli jednak coś laguje nasz serwer, to obliczenia nie są w stanie być w takim czasie zrealizowane i wtedy owa ilość spada. Aby sprawdzić ich ilość używamy komendy /tps posiadając uprawnienia operatora na serwerze.
Przejdźmy teraz do rzeczy. Jak wykonać timingi na serwerze?
/timings on./timings paste.Odczytywanie informacji zawartych w timingach to już dość skomplikowana sprawa. Obszerny opis jest dostępny w języku angielskim pod tym adresem: https://www.spigotmc.org/wiki/timings/
Skracając sprawę do najważniejszych kwestii. Rzeczą, która najczęściej laguje serwery są tzw. entities, czyli np. zwierzęta lub potwory. Jeśli są one problemem, należy zmniejszyć ich spawnowanie w pliku bukkit.yml.
Warto też zwrócić uwagę na sekcje z pluginami, czy jakieś konkretne działania, komendy, wydarzenia w pluginie nie pochłaniają zbyt dużo wspomnianych ticków. U góry timingów widzimy też ogólne statystyki takie jak średnia ilość TPS, graczy.
:information_source: Najważniejsze dane w wygenerowanym rapocie i co one oznaczają dla serwera:
Dla pluginów widzimy następujące dane:
Dla konkretnych wtyczek możemy dostrzec następujące dane:
Prostym i dość skutecznym (choć nie zawsze!) sposobem znajdowania lagów jest obserwacja kolumny Pct Tick. Jeśli widzimy tam dużą liczbę np. dla eventu PlayerMoveEvent, to znaczy, że jakiś plugin, który odpowiada za wykonywanie akcji podczas poruszania się gracza jest źle zoptymalizowany.
8. Optymalizacja plików konfiguracyjnych serwera
Kluczem do sprawnie działającego serwera jest właśnie ustawienie opcji konfiguracyjnych silnika. W zależności od trybu, efektu, który chcemy osiągnąć te opcje mogą się różnić, ale podam uśrednione wartości, których warto użyć, aby zoptymalizować nasz serwer nawet o 300%! Wszystkie omawiane pliki znajdują się w głównym folderze serwera. Możemy wygodnie je edytować przy użyciu edytora np. Sublime Text lub NotePad++.
:point_down: PLIK KONFIGURACYJNY BUKKIT.YML
spawn-limits
domyślnie: monsters:70, animals:10, water-animals:15, water-ambient: 20, ambient: 15
zoptymalizowane: monsters:40, animals:8, water-animals:3, water-ambient: 5, ambient:1
Ograniczenie ilości spawnowania mobów.
Wpływ na wydajność średni.
Jeśli w timingach entity powodują lagi, można zmniejszyć te wartości jeszcze bardziej.
chunk-gc.period-in-ticks
domyślnie: 600
zoptymalizowane: 400
Szybsze odładowywanie chunków, może podwyższyć ilość TPS.
Wpływ na wydajność średni.
ticks-per
domyślnie: animal-spawns: 400 monster-spawns: 1, water-spawns: 1, water-ambient-spawns: 1, ambient-spawns: 1
zoptymalizowane: animal-spawns: 600 monster-spawns: 4, water-spawns: 8, water-ambient-spawns: 8, ambient-spawns: 16
Jak często serwer ma próbować spawnować potwory.
Wpływ na wydajność średni.
Opcję auto-save pozostaw domyślnie, czyli na 6000, chyba, że masz osobny skrypt/plugin, który wykonuje za Ciebie cykliczne zapisywanie świata, wtedy ustaw 0.
:point_down: PLIK KONFIGURACYJNY SPIGOT.YML
mob-spawn-range
domyślnie: 8
zoptymalizowane: 4-8 (w zależności od ustawienia view-distance)
Definiuje maksymalną liczbę spawnowanych mobów w obrębie gracza na chunk.
Wpływ na wydajność mały.
nerf-spawner-mobs
domyślnie: false
zoptymalizowane: true
Włączając to ustawienie moby ze spawnerów nie będą miały żadnej inteligencji.
Wpływ na wydajność duży.
entity-activation-range
domyślnie: animals:32, monsters:32, misc:16
zoptymalizowane: animals:24, monsters:24, misc:8
Funkcja zmienia odległość w jakiej moby od gracza zaczynają się poruszać.
Wpływ na wydajność średni.
tick-inactive-villagers
domyślnie: true
zoptymalizowane: false
Czy niezaładowani osadnicy mają mieć AI.
Wpływ na wydajność ogromny.
merge-radius
domyślnie: item:2.5, exp:3.0
zoptymalizowane: item:4.0, exp:6.0
W jakiej odległości od siebie przedmioty i doświadczenie pozostawione na ziemi mają się łączyć.
Wpływ na wydajność średni.
arrow-despawn-rate
domyślnie: 1200
zoptymalizowane: 300
Jak szybko mają znikać wystrzelone strzały.
Wpływ na wydajność średni.
max-entity-collisions
domyślnie: 8
zoptymalizowane: 2
Jak sama nazwa mówi, definiuje ilość kolizji z różnymi rzeczami.
Wpływ na wydajność mały.
:point_down: PLIK KONFIGURACYJNY PAPER.YML
dla osób korzystających z silnika Paper.
max-auto-save-chunks-per-tick
domyślnie: 24
zoptymalizowane: 6
Zmieniamy jak wiele chunków serwer może zapisać w ciągu jednego ticka.
Wpływ na wydajność bardzo duży.
optimize-explosions
domyślnie: false
zoptymalizowane: true
Nie wymaga większego tłumaczenia. Optymalizujemy algorytm eksplozji.
Wpływ na wydajność średni.
mob-spawner-tick-rate
domyślnie: 1
zoptymalizowane: 2
Zmieniamy częstotliwość odświeżania spawnerów.
Wpływ na wydajność średni.
disable-chest-cat-detection
domyślnie: false
zoptymalizowane: true
Wyłączamy możliwość siadania kotów na skrzynkach.
Wpływ na wydajność mały.
container-update-tick-rate
domyślnie: 1
zoptymalizowane: 2-3
Jak często mają się odświeżać skrzynki.
Wpływ na wydajność średni.
grass-spread-tick-rate
domyślnie: 1
zoptymalizowane: 2-4
Zmienia ustawienie jak szybko ma rozrastać się trawa.
Wpływ na wydajność mały.
despawn-ranges
domyślnie: soft: 32, hard: 128
zoptymalizowane: soft: 24, hard: 96
Ustawienie jak daleko muszą znajdować się od nas moby, by zniknęły.
Wpływ na wydajność średni.
hopper.disable-move-event
domyślnie: false
zoptymalizowane: true
Ustawienie te określa czy hoppery mają wywoływać event przeniesienia przedmiotu z hoppera do innego klocka. Jeśli masz jakikolwiek plugin korzystający z InventoryMoveItemEvent to nie zmieniaj tego. Jeśli nie wiesz to też nie ruszaj.
Wpływ na wydajność: Wysoki
non-player-arrow-despawn-rate
domyślnie: -1
zoptymalizowane: 40
Ustawienie jak szybko znikają strzały wystrzelone nie przez gracza.
Wpływ na wydajność mały.
creative-arrow-despawn-rate
domyślnie: -1
zoptymalizowane: 40
Ustawienie jak szybko znikają strzały wystrzelone na trybie gry kreatywnym. Wpływ na wydajność mały.
keep-spawn-loaded
domyślnie: true/false
zoptymalizowane: zależne od sytuacji
Jeśli gracze często migrują między mapami i co za tym idzie spawnami, to true, jeśli nie, to false.
prevent-moving-into-unloaded-chunks
domyślnie: false
zoptymalizowane: true
Zapobieganie wchodzeniu na niezaładowane chunki.
Wpływ na wydajność średni.
use-faster-eigencraft-redstone
domyślnie: false
zoptymalizowane: true
Znacznie optymalizuje wszystkie mechanizmy z użyciem czerwonego proszku.
Wpływ na wydajność bardzo duży.
viewdistances.no-tick-view-distance
Opcja dzięki której możemy bardzo zoptymalizować nasz serwer. Domyślne ustawienie -1 wyłącza ją, ale możemy ją odpowiednio dostosować w odniesieniu do wcześniej ustawionej opcji view-distance.
A co ona właściwie robi? Zmienia dla gracza sposób wyświetlania świata dalej od niego, a konkretnie nie ładuje np. AI mobów, dzięki czemu znacznie optymalizuje ładowanie mapy i przez to cały serwer. Więcej o tym w języku angielskim przeczytasz tu .
`alt-item-despawn-rate’
Przyspiesza usuwanie wybranych przedmiotów z ziemi, np. cobblestone, dirt czy netherrack.
disable-pillager-patrols
domyślnie: false
zoptymalizowane: true
Wyłącza patrole pillagerów.
Wpływ na wydajność: średni.
:point_down: PLIK KONFIGURACYJNY SERVER.PROPERTIES
view-distance
Na pewno nie zostawiamy domyślnej wartości czyli 10. W zależności od potrzeb wybieramy od 3 do 8. Jest to odległość w chunkach generowania się mapy dla gracza.
network-compression-threshold
Domyślnie jest to 256. Jeśli mamy serwer spięty przez proxy hostowany lokalnie (co ważne), to wpisujemy -1, a jeśli zwykły serwer, to ustawienie 512 może pomóc. Jest to ograniczenie wielkości pakietu przed jego kompresją.
Na podstawie własnego doświadczenia i poradników anglojęzycznych m.in. tego oraz tego .
9. Pregenerowanie całej mapy przed startem serwera
Często popełnianym błędem przez początkujących administratorów serwera jest start serwera z brakiem tzw. bordera czyli ograniczenia mapy i brakiem wygenerowania całej mapy. Gdy wchodzi większa ilość graczy na serwer i każdy zaczyna w innym rejonie generować chunki, to nawet najsilniejsza maszyna może tego nie wytrzymać. Dlatego używamy pluginu WorldBorder, aby najpierw ustawić ograniczenie mapy, a potem ją wygenerować. Gdy tak się stanie, graczowi wysyłane są jedynie już wygenerowane struktury, więc serwer zużywa znacznie mniej mocy obliczeniowej.
Aby ustawić border mapy używamy komendy /wb set 5000 stojąc na środku świata, gdzie liczba to promień mapy w ilości kratek od miejsca, w którym stoimy. Następnie, aby rozpocząć generowanie mapy wpisujemy /wb fill oraz /wb fill confirm i czekamy aż proces zostanie zakończony. Link do pluginu: https://www.spigotmc.org/resources/worldborder-1-15.80466/
Są też dostępne inne pluginy na najnowszych wersjach 1.14+ takie jak FastChunkPregenerator czy ChunkMaster . Ten pierwszy w przypadku korzystania z silnika PaperSpigot oferuje asynchroniczność, ale niektórzy zgłaszali z nim pewne problemy (np. brak generowania struktur), więc wybierz rozważnie i jeśli zależy Ci na sprawdzonym rozwiązaniu, to wybierz WorldBorder!
10. Pluginy optymalizujące - czy należy z nich korzystać?
Jest wiele różnych pluginów “optymalizujących” typu clearlag czy mobstacker, ale czy powinno się z nich korzystać? Odpowiedź brzmi NIE. Pluginy tego typu mogą bardziej obciążyć serwer niż mu pomóc. Gdyby takie sposoby działały, silniki typu paper czy tuinity już dawno by to dodały. A co z pluginami typu villageroptimiser czy entitytrackerfixer? Także nie są potrzebne, tuinity radzi sobie wystarczająco dobrze. Mogą wam jednak pomóc pluginy farm limiter oraz viewdistancetweaks.
11. Kopie zapasowe serwera
Warto zautomatyzować proces wykonywania kopii zapasowych serwera. W razie awarii możemy łatwo wgrać taką kopię i cofnąć się do stanu, kiedy wszystko działało poprawnie. Do robienia kopii możesz użyć tego pluginu: https://www.spigotmc.org/resources/serverrestorer.48853/
:information_source: Poradnik o robieniu kopii zapasowej serwera na zewnętrzny serwer FTP/SFTP autorstwa @DBanaszewski pod tym adresem .
12. Panel zarządzania serwerem
Nie wszyscy lubią się z konsolą systemu Linux. Mi akurat przypadł do gustu taki sposób administrowania serwerem, pełna dowolność, ale dla ułatwienia zarządzania można zainstalować jeden z gotowych paneli. Najpopularniejsze z nich to Pterodactyl oraz PufferPanel. Możemy w nim wykonywać większość akcji czy właśnie śledzić zużycie zasobów w formie wykresów. :slightlysmilingface: Dla bardziej zaawansowanych użytkowników fajną opcją jest też system Grafana do generowania graficznych opracowań zużycia zasobów.
Poradnik autorstwa @DoreK o instalacji jednego z przytoczonych paneli: Instalacja panelu Pterodactyl i uruchomienie serwera Spigot na VPS KVM .
13. Instalacja SWAP na serwerze jako dodatkowego buforu pamięci
Czym jest SWAP? To niejako przedłużenie dostępnej pamięci RAM. Jeśli mamy niski pakiet serwera (np. 4GB KVM FR) i zaczyna nam go brakować, to wtedy dysk może nam posłużyć jako dodatkowy bufor pamięci trzymając dane w plikach tymczasowych. Dyski SSD są szybkie, a NVMe jeszcze szybsze, dzięki czemu cała operacja może przejść dosyć sprawnie i w awaryjnych sytuacjach dużego zapotrzebowania uratować nasz serwer od lagów i w konsekwencji crasha spowodowanego np. błędem out of memory.
A więc teraz pora na poradnik w poradniku, czyli jak utworzyć plik swap na serwerze Ubuntu 18.04?
sudo swapon -s. Jeśli nic nam się nie pokaże, to znaczy, że możemy przejść dalej, bo funkcja nie jest uaktywniona.sudo fallocate -l 4G /swapfile oraz chmod 600 /swapfile.sudo mkswap /swapfile.sudo swapon /swapfile.sudo swapon -s./swapfile none swap sw 0 0.vm.swappiness=10.sudo sysctl -p.14. Automatyczny restart serwera w nocy
Dobrą praktyką jest robienie regularnego restartu serwera. Pomaga to oczyścić pamięć, odciążyć na moment VPS. W szczególności serwery oparte o najnowsze wersje gry przetrzymują pewne dane w pamięci (często same pluginy też to robią w postaci np. HashMap czy ArrayList, co samo w sobie nie jest złe, ale jeśli jest źle napisane przez developera pluginu, to już pojawia się problem) warto więc taki restart wykonać. Można do tego użyć metody podanej przez @riko.dev w tym temacie na forum .
15. Obciążenie łącza, ping do serwera, ataki
Zdarza się, że lagi spowodowane są nie błędną konfiguracją serwera, a maszyny pod kątem sieci, chwilowych problemów z łączem u operatora czy atakiem DDoS (chwilowym wzrostem pingu i lagiem do momentu odfiltrowania). Starsze wersje mają też mnóstwo luk bezpieczeństwa, ale i na tych nowszych można się ich doszukać, dlatego warto dobrze zabezpieczyć serwer, aby zapewnić mu stabilność (sprawdź osobny poradnik umieszczony na początku tego tematu).
Aby sprawdzić zużycie łącza na serwerze możesz użyć pakietu nload. Zainstaluj go przy użyciu komendy apt install nload, a następnie uruchom poleceniem nload. Możemy też wykonać SpeedTest używając w tym celu oficjalnego repozytorium SpeedTest CLI .
16. Podsumowanie
Jak widzicie dostosowanie serwera tak, aby działał sprawnie wymaga wielu zabiegów, ale warto przynajmniej większość z nich wykonać, aby cieszyć się płynną grą. Wiele dużych serwerów działa na ostatniej dobrze zoptymalizowanej wersji 1.12.2 i z pluginem ViaVersion akceptuje połączenia z nowszych klientów i to też jakieś rozwiązanie, ale niezależnie od użytej wersji, silnika czy trybu te porady są w dużej mierze uniwersalne.
adminek153 | 2020-11-20 11:25:18 UTC | #2
SystemZ | 2020-11-20 11:27:38 UTC | #3
Zamykamy ze względu na duplikację treści.
Wystarczy wskazać swoje spostrzeżenia autorowi w poście pod oryginalnym tematem, w końcu jest na tym samym forum :slight_smile:
W razie czego istnieje też możliwość edycji przez wiele osób poprzez tryb wiki.