Lagi na serwerze Garry’s Mod — jak sprawdzić dodatki, obciążenie i błędy Lua?

Lagi na serwerze Garry’s Mod diagnozuj, porównując objawy graczy z logami oraz wykresami CPU i RAM. Potem sprawdź, czy problem wywołuje konkretna mapa, konstrukcja fizyczna lub dodatek. Sam restart albo zwiększenie pamięci nie wskazuje przyczyny i może dać tylko chwilową poprawę.

W poradniku przejdziesz od rozpoznania rodzaju opóźnienia do testowania dodatków i odczytania błędu Lua. Czynności administracyjne opisujemy dla panelu Vorlantix. Każdy test wykonuj na zabezpieczonej konfiguracji, w uzgodnionym terminie i z możliwością powrotu do działającego zestawu.

Lagi, niski FPS czy problemy z siecią?

Słowo „lagi” bywa używane do kilku różnych objawów. Jeśli tylko jedna osoba widzi mało klatek, nie musi to oznaczać przeciążenia hostingu. Gdy wszystkim jednocześnie opóźniają się działania, trzeba sprawdzić również serwer. Podział klienta i serwera wyjaśnia dokumentacja stanów GModa.

To wskazówki do sprawdzenia, nie gotowa diagnoza. Przeciążony serwer może również pogorszyć odczuwane opóźnienie. Najpierw zapytaj graczy, czy objaw pojawia się w tym samym momencie i przy tej samej czynności.

Krok 1. Zapisz okoliczności i sprawdź klienta

Zanotuj godzinę, nazwę mapy, tryb, liczbę uczestników i ostatnio dodane paczki. Opisz konkretny wyzwalacz: pojazd, duplikację, rozpoczęcie rundy, wejście gracza albo zapis danych. Taki opis jest znacznie bardziej użyteczny niż „czasami zacina”.

Na komputerze gracza możesz w konsoli klienta włączyć:

net_graph 1

To narzędzie pokazuje informacje o sieci i klatkach. Zrób odczyt podczas problemu i porównaj z normalną rozgrywką. Po teście wyłącz nakładkę poleceniem net_graph 0. Opis zmiennej znajdziesz w referencji GModa. Polecenie wpisujesz lokalnie, a nie w konsoli panelu hostingu.

Jeżeli kłopot dotyczy jednego uczestnika, porównaj połączenie kablowe z Wi-Fi, sprawdź pobieranie w tle i obciążenie komputera. Przy samym spadku FPS wykonaj próbę z mniej wymagającą sceną. Nie zmieniaj od razu parametrów całego serwera.

Krok 2. Sprawdź CPU i RAM w Vorlantix

1. Otwórz usługę Garry’s Mod w panelu klienta.
2. W sekcji parametrów odczytaj przydzielone vCPU i RAM.
3. W widoku „Konsola” obserwuj wykresy podczas zwykłej sesji.
4. Odtwórz zgłoszoną czynność i zanotuj zmianę obciążenia.
5. Porównaj wykresy z logiem i dokładną godziną problemu.

Łączny wykres CPU nie pokazuje osobno każdego rdzenia. Niski procent względem całego limitu nie wyklucza ograniczenia w części obliczeń. Z kolei wysoki odczyt podczas pobierania lub uruchamiania nie opisuje automatycznie wydajności późniejszej rozgrywki.

RAM oceniaj względem przydzielonego limitu i trendu kilku sesji. Jeśli pamięć zbliża się do limitu, a proces się zatrzymuje, przekaż log obsłudze do potwierdzenia przyczyny. Duże zużycie samo w sobie nie dowodzi wycieku. Sprawdź, czy po podobnym czasie i obciążeniu wartości się stabilizują.

Nie testuj tylko pustego serwera. Brak graczy może zmieniać wykonywaną pracę: dokumentacja GM:Tick opisuje zachowanie tego hooka przy pustej usłudze. Pomiary powinny obejmować typowe działania ekipy.

Krok 3. Przeczytaj pierwszy istotny błąd Lua

Przykładowy komunikat może wyglądać tak:

[ERROR] addons/przykladowy_dodatek/lua/autorun/server/sv_test.lua:42:
attempt to index field 'Config' (a nil value)

To wymyślony przykład formatu. W swoim logu odczytaj ścieżkę pliku, numer wiersza i treść błędu. Zachowaj również stos wywołań poniżej komunikatu. Instrukcję czytania znajdziesz w poradniku Facepunch o błędach Lua.

nil value nie oznacza automatycznie jednej konkretnej naprawy. Przyczyną może być brak zależności, niewłaściwa kolejność ładowania lub błąd dodatku. Sprawdź pierwszy komunikat po starcie, a nie tylko ostatni z długiej serii.

Pojedynczy błąd może przerwać działanie funkcji, ale nie potwierdza jeszcze źródła lagów. Powtarzający się komunikat skoreluj z objawem i testem dodatku. Nie usuwaj linii kodu ani nie wyciszaj logów wyłącznie po to, żeby konsola wyglądała poprawnie. Autorowi paczki wyślij pełny komunikat i kroki odtworzenia.

Krok 4. Sprawdź fizykę i obiekty na mapie

Ustal, czy pogorszenie zaczyna się po zbudowaniu konkretnej konstrukcji. Przyjrzyj się poruszającym się propom, połączeniom, pojazdom, NPC i botom. Porównaj stan przed ich utworzeniem oraz po usunięciu wyłącznie elementu testowego.

Nie wykonuj globalnego czyszczenia mapy na aktywnej sesji bez uzgodnienia z ekipą. Najpierw zabezpiecz potrzebne konstrukcje. Jeśli usunięcie jednej maszyny daje poprawę, sprawdź zarówno liczbę obiektów, jak i dodatek, który nimi steruje.

Nie zwiększaj tick rate jako pierwszej metody naprawy. Ten parametr ustala docelową częstotliwość aktualizacji, opisaną w dokumentacji parametrów uruchomienia. Wyższy cel nie dostarcza dodatkowej mocy procesora. Zmiany parametrów wykonuj dopiero z pomiarem i jasno określonym celem.

Krok 5. Testuj dodatki z zachowaniem zależności

Najlepiej pracować na kopii środowiska testowego. Jeśli korzystasz z tej samej usługi, zaplanuj przerwę, zapisz listę paczek i wykonaj backup. Nie usuwaj bez kopii dodatków przechowujących dane rozgrywki.

1. Zacznij od ostatnio dodanego lub aktualizowanego dodatku.
2. Sprawdź jego wymagania oraz zgodność z trybem gry.
3. Wyłącz go w źródle instalacji i uruchom proces ponownie.
4. Powtórz tę samą czynność na tej samej mapie, z podobną liczbą graczy.
5. Zapisz wynik i przywróć stan odniesienia przed kolejną próbą.

Przy większym zestawie możesz porównywać grupy dodatków, ale zachowuj całe łańcuchy zależności. Wyłączenie biblioteki przy pozostawieniu korzystających z niej paczek stworzy nowe błędy. Poprawa po usunięciu grupy zawęża podejrzenia; nie wskazuje jeszcze jednego winowajcy.

Sprawdź również, czy dodatek nie jest jednocześnie instalowany z Workshop i ręcznego folderu. Usunięcie z kolekcji nie zastępuje sprawdzenia pozostałych źródeł montowania. Po restarcie potwierdź w logu, jaki zestaw faktycznie został wczytany.

Kiedy warto użyć profilera?

Jeśli testy zawęziły problem do Lua, ale nie pokazują kosztownej funkcji, zaawansowaną opcją jest FProfiler. To osobny dodatek diagnostyczny, nie funkcja panelu Vorlantix. Skorzystaj z instrukcji autora i przeprowadź krótką, kontrolowaną sesję pomiarową na właściwej stronie: serwerze lub kliencie.

Nie traktuj najwyższego wpisu jako automatycznego błędu. Porównaj koszt pojedynczego wywołania, liczbę wywołań i scenariusz testu. Wynik ma pomóc autorowi paczki lub administratorowi, a nie uzasadniać przypadkowe usuwanie fragmentów kodu.

Najczęstsze problemy

Po restarcie jest lepiej, ale problem wraca

Zapisz czas do nawrotu i powiąż go z działaniami graczy, liczbą obiektów oraz trendem pamięci. Regularny restart może maskować przyczynę; nie zastępuje sprawdzenia dodatku lub konstrukcji.

Więcej RAM nie poprawiło płynności

Sprawdź, czy wcześniej rzeczywiście brakowało pamięci. Ograniczenie procesora, fizyki albo sieci wymaga innej zmiany. Porównuj zasoby na tym samym scenariuszu zamiast oceniać pakiet po pojedynczym wejściu.

Wyłączenie dodatku powoduje kolejne błędy

Sprawdź zależności i wróć do działającej kopii. Testuj kompletną grupę powiązanych paczek. Jeśli po zmianie pojawił się nowy błąd startu, nie porównuj jego obciążenia z poprawnie uruchomionym trybem.

Co przekazać obsłudze Vorlantix?

Podaj identyfikator usługi, godzinę ze strefą czasową, mapę, tryb, liczbę graczy i sposób odtworzenia problemu. Dołącz pełny błąd Lua, odczyty obciążenia i wyniki testów. Usuń z materiałów hasła, tokeny oraz dane połączeń, które nie są potrzebne do diagnozy.

Podsumowanie

Diagnozę lagów GModa zacznij od rozróżnienia sieci, FPS i pracy serwera. Porównaj logi z wykresami Vorlantix, przeczytaj pierwszy błąd Lua i odtwórz problem na zabezpieczonej konfiguracji. Dodatki sprawdzaj razem z zależnościami, a fizykę oceniaj na konkretnych konstrukcjach. Zasoby zwiększaj wtedy, gdy pomiary potwierdzają ich brak.