Serwer Palworld ciągle się wysypuje: jak zdiagnozować i naprawić

Krótka wersja

Serwer dedykowany Palworld ma od dawna istniejący wyciek pamięci. Zużycie RAM rośnie stale, przez cały czas, gdy serwer działa, mniej więcej proporcjonalnie do liczby graczy online i liczby Palsów na świecie, i nigdy nie jest zwalniane. W końcu proces wyczerpuje przydzieloną mu pamięć i system operacyjny go zabija. Z zewnątrz wygląda to jak losowa awaria, dlatego tak wielu ludzi najpierw obwinia hosta.

Operatorzy serwerów konsekwentnie opisują przebieg tego zjawiska: świat dla czterech graczy z około 80 Palami zwykle rośnie z około 3 GB do ponad 8 GB w ciągu czterech godzin, a zajęty serwer społecznościowy dla 16 graczy może dojść do 12 GB w pół godziny. Te liczby zależą od twojego świata, ale wzorzec pozostaje ten sam. Jeśli twoje awarie przychodzą według mniej więcej stałego harmonogramu, a nie losowo, to jest wyciek.

Dwie awarie, które nie wyglądają na crash

Awaria z wyłożeniem się procesu to łatwy przypadek: proces umiera i wszystko, co go pilnuje, to zauważa. Dwie awarie, które generują najwięcej zagmatwanych zgłoszeń do pomocy, zostawiają proces przy życiu, a wszystkie kontrole stanu przechodzą. Zdiagnozowaliśmy obie na podstawie 22 godzin próbek co minutę z serwera klienta 16GB i wyglądają tak:

Żadna z tych awarii nie jest wyciekiem pamięci. Awaria wyładowania świata wystąpiła trzy razy w ciągu dwóch godzin na serwerze zużywającym poniżej 2.3GB, więc nie jest to ani wyciek, ani limit RAM. Kosztowne jest to, że zwykły health check, czyli sprawdzenie, czy proces gry działa, przechodzi w obu stanach, więc nic nie restartuje serwera i może on leżeć martwy godzinami, gdy śpisz.

Upewnij się, że to pamięć, zanim cokolwiek zmienisz

Otwórz wykres zasobów w panelu i obserwuj RAM w trakcie sesji. Wyciek pamięci ma sygnaturę, której trudno pomylić:

• RAM rośnie niemal prostą linią od chwili startu serwera i nigdy nie spada po wyjściu graczy.
• Crash następuje, gdy ta linia osiąga sufit twojego planu, a nie w konkretnym wydarzeniu w grze.
• Nie ma żadnego użytecznego komunikatu o błędzie. Proces po prostu znika, bo system operacyjny go zabił, a nie gra zdecydowała się wyjść.
• Restart serwera całkowicie to naprawia, ale tylko na kilka godzin.

Jeśli zamiast tego serwer pada za każdym razem w tej samej chwili albo kończy się po kilku sekundach od startu, przejdź do ostatniej sekcji. To inne problemy z innymi rozwiązaniami.

Rozwiązanie 1: restart według harmonogramu

To nieefektowna odpowiedź, ale skuteczna. Ponieważ wyciek rośnie liniowo, a restart czyści wszystko, zaplanowany restart resetuje licznik, zanim sufit zostanie osiągnięty. Doświadczeni operatorzy restartują zwykle co trzy do sześciu godzin na zajętym publicznym serwerze i raz lub dwa razy dziennie na małym prywatnym.

Restart serwera Palworld trwa około minuty, a świat jest najpierw zapisywany, więc koszt dla graczy jest mały. Wybierz porę, gdy twoja grupa zwykle jest offline, ogłoś ją na Discordzie i problem przestaje być problemem. Na Flux możesz zrestartować z panelu jednym kliknięciem, a ponieważ restart łapie też oczekującą aktualizację gry, pełni rolę twojej rutyny łatania.

Jedna pułapka warta znajomości, jeśli hostujesz samodzielnie lub u innego dostawcy: zaplanowany skrypt restartu w standardowym obrazie serwera Palworld prosi serwer o najpierw zapis i odmawia wyłączenia, jeśli zapis się nie uda. Na serwerze, który przecieka, zamarza lub nie ma świata, czyli dokładnie takim, dla którego istnieje nocny restart, to właśnie zapis się nie udaje. Restart po cichu nic nie robi w dokładnie te noce, w których był potrzebny, a logi pokazują, że się wykonał. Sprawdź, czy twój naprawdę się zrestartował, zamiast zakładać, że tak.

Poprawka 2: wyłącz najeźdźców Palów

Najazdy generują fale wrogich Palów, które serwer trzyma w pamięci długo po zakończeniu najazdu. Ich wyłączenie to najbliższe, co Palworld ma do społecznościowego obejścia wycieku, a operatorzy konsekwentnie raportują, że RAM rośnie potem mniej więcej o połowę wolniej.

W PalWorldSettings.ini ustaw bEnableInvaderEnemy=False i zrestartuj. Tracisz najazdy na bazy, co niektóre grupy będą żałować, a wiele nie, a w zamian w przybliżeniu podwajasz czas między restartami. Edytuj plik z edytora konfiguracji w panelu; nie trzeba otwierać terminala.

Poprawka 3: ogranicz to, co rośnie

Wyciek rośnie wraz z ilością świata, który trzeba trzymać w pamięci, więc ograniczenie tego, ile mogą tworzyć gracze, go spowalnia. Dwa ustawienia wykonują większość pracy:

Gildia, która ma zaparkowane po 50 pracujących Palsów w każdej z kilku baz, trzyma w RAM dużą ilość trwałej symulacji, a każdy z tych Palsów dokłada się do wycieku. Ograniczenie liczby pracowników to nie tylko poprawka pamięci: to najważniejsza dźwignia obciążenia CPU serwera Palworld, więc zwykle jednocześnie poprawia lag.

Rozwiązanie 4: zostaw zapas

Żadne z powyższych nie zatrzymuje wycieku, tylko go spowalniają. Pozostałą zmienną jest to, ile miejsca ma serwer przed sufitem, a to zależy od rozmiaru twojego planu. Jeśli prowadzisz 16 graczy na 8 GB, prosisz wyciek, żeby zabił cię w ciągu godziny, bez względu na to, jak dobrze skonfigurujesz świat.

Te plany już zakładają serwer, który przecieka, a nie teoretycznie bezczynny. Jeśli wywala się na planie odpowiadającym liczbie graczy, zwykle przyczyną jest mocno rozbudowany świat, a dwa ustawienia powyżej zrobią więcej niż kolejny plan. Jeśli jesteś o jeden poziom poniżej liczby graczy, przejdź wyżej. Zmiana RAM na Flux nie rusza zapisu świata.

Jak utrzymać serwer Palworld online 24/7

Wszystko powyższe spowalnia awarie. Nic z tego nie sprawi, że serwer, który już uległ awarii, wróci do życia, a właśnie to odróżnia serwer, który działa przez większość czasu, od takiego, który działa cały czas. Coś musi zauważyć problem i zareagować, kiedy śpisz.

Tę lukę zamyka nasz obraz serwera Palworld, dlatego budujemy własny, zamiast wysyłać standardowy. Co minutę sprawdza serwer od środka kontenera pod kątem rzeczy, które gracz faktycznie zauważy: czy gniazdo sieciowe się nie zapycha, czy API administracyjne odpowiada, czy świat jest załadowany i działa, oraz czy plik zapisu nadal jest na dysku. Jeśli odpowiedź brzmi nie, restartuje serwer. Nie trzeba niczego włączać ani szukać żadnego ustawienia.

Powściągliwość jest równie ważna jak wyzwalacz, bo monitor, który restartuje zdrowe serwery, jest gorszy niż brak monitora:

• Potrzebuje tego samego werdyktu trzy razy z rzędu, co minutę, zanim podejmie działanie. Jedna zła próbka to nie błąd.
• Nigdy nie działa na serwerze, którego wcześniej nie widział działającego, i nigdy w pierwszych minutach po starcie. Wczytanie dużego świata zajmuje czas, a pętla restartów nie pomaga serwerowi, który wstał zepsuty.
• Ogłasza restart w grze i odlicza 60 sekund, z przypomnieniami przy 30 i 10 sekundach, a następnie pobiera jedną ostatnią próbkę. Serwer, który odzyskał sprawność podczas odliczania, zostaje w spokoju, a odliczanie zostaje odwołane na głos.
• Nigdy nie zapisuje. W każdym stanie, który dochodzi aż do tego miejsca, świat w pamięci jest już utracony lub zamrożony, a prośba do zepsutego serwera o zapis grozi nadpisaniem twojego ostatniego dobrego zapisu tą pustką. Restart kosztuje cię minuty od ostatniego autozapisu, które przepadły już w chwili awarii.

Nocny restart na tym obrazie też jest naprawiony. Ostrzega graczy, zapisuje tylko wtedy, gdy świat jest nadal załadowany i faktycznie działa, prosi serwer o zamknięcie, a potem przestaje prosić: po okresie łaski kończy proces, a nowy serwer wstaje kilka sekund później. Nigdy po cichu nie pomija restartu.

Warto zrobić jedną rzecz samemu: ustaw hasło administratora w zakładce Ustawienia serwera. Sprawdzenia gniazd i plików zapisu działają zawsze, ale kontrole wykrywające niezaładowany świat rozmawiają z API administratora, a serwer bez hasła odrzuca te wywołania. Celowo nigdy nie traktujemy odrzuconego wywołania jako martwego serwera, bo robienie tego restartowałoby zdrowe światy co kilka minut, więc skutek pozostawienia pola pustym to cichsza ochrona, a nie głośniejsza.

Kiedy to nie wyciek pamięci

Pada kilka sekund po starcie, zaraz po aktualizacji gry

Pocketpair wydaje aktualizacje klienta i serwera razem, a serwer wciąż na poprzedniej wersji będzie odrzucał połączenia albo się wywróci, gdy tylko dołączy zaktualizowany klient. Zaktualizuj serwer, gdy tylko pojawi się łatka klienta, zamiast czekać na zgłoszenie od graczy. Na Flux restart pobiera aktualny obraz, więc to jedno kliknięcie.

Pada w tym samym miejscu za każdym razem

Awaria, która powtarza się dokładnie, na przykład za każdym razem, gdy konkretny gracz się loguje albo świat dociera do określonego obszaru, wskazuje na uszkodzony zapis, a nie na pamięć. Przywróć najnowszy backup wykonany przed rozpoczęciem tego zachowania. Trzymaj backupy według harmonogramu właśnie z tego powodu: zapisu, którego nie możesz cofnąć, możesz stracić.

Serwer w ogóle nie startuje

Jeśli serwer nigdy nie wstał, to problem z konfiguracją albo portem, a nie awaria. Sprawdź, czy UDP 8211 jest portem, pod który wybierają się gracze, i czy PalWorldSettings.ini jest poprawny, bo jedna źle sformatowana linia zatrzyma wczytanie pliku. Przewodnik konfiguracji przeprowadzi cię przez oba.

Lista kontrolna, którą możesz przejść krok po kroku

1. Ustal, jaka jest awaria. Prosty wzrost RAM aż do sufitu to wyciek. Serwer działa, ale nie da się do niego dołączyć, to zawieszenie. Da się dołączyć, ale nie ma świata, to niezaładowany świat. Każdy z tych przypadków wymaga innego rozwiązania.
2. Ustaw bEnableInvaderEnemy=False w PalWorldSettings.ini i zrestartuj serwer.
3. Ogranicz BaseCampWorkerMaxNum do rozsądnej wartości dla swojej grupy, a BaseCampMaxNum do liczby graczy.
4. Zaplanuj restart co trzy do sześciu godzin na zajętym serwerze albo raz dziennie na prywatnym.
5. Upewnij się, że RAM twojego planu odpowiada liczbie graczy, a jeśli nie, przejdź na wyższy poziom.
6. Włącz automatyczne backupy, żeby uszkodzony zapis był niedogodnością, a nie końcem świata.
7. Ustaw hasło administratora, aby sprawdzenia wykrywające niezaładowany świat mogły dotrzeć do twojego serwera.
8. Upewnij się, że coś restartuje serwer, gdy przestaje odpowiadać, a nie tylko gdy padnie. Na Flux jest to wbudowane w obraz serwera.

Przejdź przez to w tej kolejności, a większość raportów o awariach Palworld ustanie. Pozostaje ograniczenie silnika gry, którego nikt nie załata za ciebie. Pytanie nie brzmi więc, jak zapobiec każdej awarii, tylko jak szybko serwer wraca do działania po jednej z nich.