Lagi na serwerze FiveM: od OneSync po ciężkie skrypty

Nic nie rujnuje wieczoru roleplay tak szybko jak przycinający serwer: teleportujące się auta, ekwipunek otwierający się po kilku sekundach, NPC zamrożeni na chodniku. Dobra wiadomość: lagi w FiveM prawie zawsze mają konkretną przyczynę. Zła wiadomość: rzadko siedzi ona tam, gdzie szukasz jej najpierw.

Jedno rozróżnienie na start oszczędzi Ci godzin szukania. Niski FPS u graczy to problem klienta: ciężkie mapy, za dużo propów, słabe komputery. Rubberbanding, wolne eventy i akcje dochodzące po sekundach to zwykle strona serwera — i to jest ta część, którą jako administrator masz w swoich rękach.

Najpierw mierz, potem zgaduj

Największy błąd, jaki możesz popełnić, to wyłączanie zasobów od razu, bo ktoś na Discordzie krzyknął, że skrypt X jest ciężki. Zacznij od liczb. txAdmin, standardowy panel FiveM, pokazuje na dashboardzie wykres wydajności: ile czasu serwer potrzebuje na jeden tick. Jeśli wykres trzyma się zieleni, proces serwera jest zdrowy, a problem leży raczej po stronie klientów lub sieci. Jeśli widzisz piki pokrywające się ze skargami graczy, masz pewność, że trzeba szukać po stronie serwera.

Zaglądaj też do konsoli serwera. FiveM sam zgłasza, gdy tick trwa za długo, tzw. hitch warnings, razem z liczbą milisekund, które tick pochłonął. Pojedynczy hitch przy starcie to norma; konsola pełna hitch warnings w godzinach szczytu to konkretny trop.

Na koniec zapisuj, KIEDY występują lagi. Tylko wieczorem przy wielu graczach online? Wtedy coś źle się skaluje z liczbą graczy — pomyśl o eventach odpalanych per gracz albo piętrzących się zapytaniach do bazy. Widoczne już przy pięciu osobach? Wtedy jeden zasób lub zapytanie jest strukturalnie wolne, i to właściwie dobra wiadomość: takie znajdziesz szybciej.

OneSync: więcej graczy, więcej pracy dla serwera

OneSync przenosi synchronizację encji — pojazdów, NPC, obiektów — z klientów na serwer. Dzięki temu możesz wyjść znacznie ponad klasyczny limit slotów, a serwer przejmuje kontrolę nad tym, co widzi każdy gracz: encje daleko poza zasięgiem są cullowane i przestają być synchronizowane.

To w większości zysk, ale pamiętaj, co oddajesz w zamian. Cała ta praca synchronizacyjna ląduje na procesorze serwera i rośnie z każdym dodatkowym graczem. Serwer, który przy trzydziestu osobach chodzi płynnie, przy sześćdziesięciu może uderzyć w sufit, choć nie zmienił się ani jeden skrypt. Poza tym niektóre wiekowe skrypty z epoki sprzed OneSync zachowują się dziwnie: zakładają, że każda encja istnieje dla wszystkich, a z cullingiem to już nieprawda.

Wyłączanie OneSync nie jest więc żadnym poważnym trikiem anty-lagowym, cokolwiek twierdzą niektóre fora. Obowiązuje za to zasada: im wyższa liczba slotów, tym bardziej liczą się wydajność single-core i porządnie napisane skrypty.

Namierzanie ciężkich skryptów

Zdecydowana większość lagów po stronie serwera pochodzi ze źle napisanych zasobów. Tak znajdziesz winowajców:

• resmon: w konsoli F8 wpisz komendę resmon. Widzisz, ile milisekund na klatkę kosztuje każdy zasób. Wszystko, co stale ma wysoki wynik, choć nic się nie dzieje, zasługuje na krytyczne spojrzenie.
• Profiler: po stronie serwera FiveM ma wbudowany profiler. Komendą profiler record 500 nagrywasz pięćset ticków, a profiler view pokazuje per zasób i per funkcja, gdzie wisi czas.
• Metoda połówkowa: nie chce Ci się bawić profilerem? Na serwerze testowym wyłącz połowę zasobów i sprawdź, czy lag znika. Powtórz z podejrzaną połową. W kilka rund masz sprawcę.

Przy resmon uważaj, co właściwie mierzysz: na kliencie widzisz głównie, ile zasób kosztuje Twoją własną grę, podczas gdy profiler na serwerze pokazuje, co znosi proces serwera. Skrypt może wyglądać niewinnie po stronie klienta i mimo to zatykać tick serwera — albo odwrotnie. Mierz więc po obu stronach, zanim wyciągniesz wnioski.

Klasyczni grzesznicy: pętle kręcące się co klatkę bez czasu oczekiwania, skrypty bez przerwy iterujące po WSZYSTKICH graczach lub encjach oraz eventy wysyłane do wszystkich klientów przy każdej drobnej akcji. Nawet popularne płatne skrypty nie są na to odporne — oceniaj po pomiarach, nie po reputacji czy cenie.

Ważna, choć niewygodna prawda: czasem rozwiązanie nie jest przyjemne. Ulubiony skrypt, który ewidentnie rujnuje Twój tickrate, trzeba zaktualizować, wymienić albo przepisać. Nie ma zmiennej serwera, która zrekompensuje źle napisany kod.

Baza danych jako cichy hamulec

Prawie każdy serwer roleplay wisi na bazie MySQL przez konektor taki jak oxmysql. Jeśli otwieranie ekwipunku albo zapisywanie graczy jest wolne, a wykres wydajności pozostaje zielony, szukaj tutaj.

• Wolne zapytania: włącz slow query log w MySQL i zobacz, które zapytania wystają ponad resztę. Często po prostu brakuje indeksu na kolumnie, po której stale się wyszukuje, jak identyfikator gracza.
• Za dużo zapytań: niektóre skrypty przy każdej drobnej zmianie zapisują całą postać albo cały ekwipunek. Przy dziesięciu graczach tego nie zauważysz, przy pięćdziesięciu — owszem.
• Odległość: jeśli baza działa w innej lokalizacji niż serwer gry, przy każdym zapytaniu płacisz opóźnieniem sieci. Trzymaj je blisko siebie, najlepiej na tej samej maszynie lub w tej samej sieci, i na szybkich dyskach typu NVMe.
• Czekające skrypty: niektóre starsze skrypty blokująco czekają na odpowiedź bazy, zanim ruszą dalej. Każde wolne zapytanie od razu zatrzymuje wtedy kawał serwera. Nowsze konektory i skrypty robią to porządniej, więc aktualizacja przestarzałych zasobów opłaca się podwójnie.

Sprzęt: wygrywa szybkość single-core

Ciężka praca synchronizacyjna i skryptowa serwera FiveM działa w dużej mierze na jednym wątku. Procesor z wysokim taktowaniem i mocnym single-core zrobi więc dla Twojego tickrate'u więcej niż góra dodatkowych rdzeni. Pamięć decyduje głównie o tym, ile zasobów i graczy pomieścisz, a szybkie dyski pomagają bazie danych i czasom ładowania.

W MC-Node serwery FiveM działają na własnym sprzęcie z dyskami NVMe i ochroną DDoS w centrum danych Previder w Hengelo — czyli niski ping dla graczy z Europy Zachodniej. Wszystkie pakiety możesz anulować co miesiąc, więc zaczynasz małym i skalujesz dopiero, gdy pomiary tego zażądają:

Uczciwie mówiąc: mocniejszy pakiet nie naprawi źle napisanych skryptów. Ale jeśli z posprzątanym serwerem wciąż strukturalnie dobijasz do sufitu, upgrade to logiczny krok. Porównaj opcje w pakietach FiveM od MC-Node i przeskocz o rozmiar wyżej — dzięki miesięcznemu okresowi wypowiedzenia nic Cię nie wiąże.

Twój plan działania w skrócie

1. Potwierdź wykresem txAdmin i hitch warnings, że problem naprawdę leży po stronie serwera.
2. Uruchom resmon i profiler w godzinach szczytu, a nie o trzeciej w nocy na pustym serwerze.
3. Weź się za najcięższy zasób: aktualizacja, wymiana albo przepisanie.
4. Sprawdź bazę pod kątem wolnych zapytań i brakujących indeksów.
5. Skrypty i baza w porządku, a wciąż się blokujesz? Dopiero wtedy odpowiedzią jest sprzęt.

Kto działa w tej kolejności, rozwiązuje większość lagów w jeden wieczór — i ma pewność, że ewentualny upgrade to nie drogi plaster, lecz świadomy wybór.