Jak naprawić lagi serwera FiveM i komunikat 'server thread hitch warning'?

Widzisz w konsoli swojego serwera FiveM ciągle server thread hitch warning: timer interval of XXX milliseconds, a gracze skarżą się na lagi i rubber banding? To znak, że wątek serwera nie nadąża. Z tego artykułu dowiesz się, co oznacza ten komunikat, jak za pomocą resmon namierzyć ciężkie zasoby i jak rozprawić się z czterema największymi winowajcami.

Co oznacza 'server thread hitch warning'?

FXServer wykonuje rdzeń Twojego serwera — synchronizację graczy, eventy i większość logiki skryptów — na jednym głównym wątku (svMain). Ten wątek pracuje w krótkich tickach. Gdy jeden tick trwa znacznie dłużej niż planowano, na przykład 250 milisekund zamiast kilku, serwer zapisuje hitch warning ze zmierzonym czasem. Podczas takiego przycięcia wszystko staje jednocześnie: gracze cofają się do poprzedniej pozycji, pojazdy zamierają, a eventy docierają z opóźnieniem.

Ponieważ cała ta praca odbywa się na jednym wątku, decydująca jest wydajność pojedynczego wątku CPU — nie liczba rdzeni ani ilość RAM-u. W praktyce przyczyną zwykle nie jest jednak wolna maszyna, lecz jeden zasób, który blokuje wątek. Ten artykuł dotyczy konkretnie FiveM; lagi na serwerze Minecraft działają zupełnie inaczej i mają osobny artykuł o optymalizacji.

Krok 1: Namierz ciężkie zasoby za pomocą resmon

1. Połącz się z serwerem, otwórz konsolę klienta klawiszem F8 i wpisz resmon 1. Pojawi się okno monitora zasobów.
2. Patrz na kolumnę CPU msec: pokazuje, ile milisekund dany zasób kosztuje na klatkę. Zostaw okno otwarte na chwilę podczas gry.
3. Interpretacja wartości: porządny zasób pozostaje poniżej 0,10 ms. Skrypt utrzymujący się stale powyżej 1,00 ms jest ciężki; skoki o kilka milisekund wskazują winowajcę wprost.
4. Resmon mierzy Twojego klienta. Sam wątek serwera sprofilujesz w zakładce Console w panelu MC-Node: wpisz profiler record 500, poczekaj na zakończenie nagrania i wpisz profiler view. Pod wyświetlonym linkiem zobaczysz dla każdego zasobu, które funkcje wstrzymują tick; w txAdmin wykresy na dashboardzie również pokazują czasy ticków.
5. Brak wyraźnego skoku? Zatrzymuj podejrzane zasoby tymczasowo poleceniem stop nazwazasobu w konsoli i sprawdzaj, czy warningi znikają. Wykluczając za każdym razem połowę zasobów, znajdziesz winowajcę nawet bez profilera.

Krok 2: Rozpraw się z czterema największymi winowajcami

1. Skrypty z ciasnymi pętlami — Pętla typu while true do ... Citizen.Wait(0) end wykonuje się w każdym ticku, nawet gdy nie ma nic do zrobienia. Zwiększ czas oczekiwania, np. do Citizen.Wait(1000), dla kontroli, które nie muszą działać bez przerwy, i spraw, by kod reagował na eventy, zamiast stale odpytywać. Jeśli zaszyfrowany (escrow) lub porzucony skrypt wciąż jest ciężki, zastąpienie go utrzymywaną alternatywą jest niemal zawsze lepszym wyborem.
2. Zbyt duże tekstury pojazdów (YTD) — Auta addon z teksturami 4K lub 8K pożerają pamięć streamingu: gracze doświadczają przycięć, texture loss i długiego pobierania. Zmniejsz tekstury maksymalnie do 2K, usuń nieużywane warianty liverek i podchodź krytycznie do paczek ważących setki megabajtów. Jak instalować pojazdy lekko i porządnie, przeczytasz w poradniku aut addon.
3. Blokujące zapytania do bazy danych — Synchroniczne zapytanie wstrzymuje wątek serwera do czasu odpowiedzi bazy. Używaj aktualnego asynchronicznego wrappera, np. oxmysql, zastąp przestarzałe skrypty mysql-async i załóż indeksy na często używanych tabelach, takich jak users i owned_vehicles. Zapisuj dane graczy zbiorczo, a nie przy każdej drobnej zmianie. Dane logowania do bazy znajdziesz w zakładce Databases.
4. Zbyt wiele encji — Każdy zespawnowany pojazd, prop i ped musi być synchronizowany w każdym ticku; tysiące porzuconych pojazdów wyraźnie to podraża. Uruchom skrypt cleanup, który po kilku minutach usuwa puste pojazdy, ogranicz skrypty spawnujące i uważaj na mapy stawiające ogromne ilości propów — zobacz też poradnik MLO i map custom.

Kiedy to naprawdę sprzęt jest wąskim gardłem?

Klasyczna pułapka to zrzucanie wszystkiego na hosting, podczas gdy jeden skrypt zjada 90% czasu klatki — profiler pokazuje to bezlitośnie. Ale bywa też odwrotnie. Resmon jest czysty, profiler rozkłada czas ticka równo na wiele drobnych zadań bez wyraźnego skoku, a warningi pojawiają się dopiero przy dużej liczbie graczy? Wtedy dobijasz do limitu pojedynczego wątku CPU. Więcej RAM-u ani dodatkowe sloty tego nie rozwiążą; pomoże już tylko sprzęt o wyższym taktowaniu na rdzeń.

Częste komunikaty i sytuacje

• Hitch warningi podczas startu — Przy (re)starcie serwer ładuje wszystkie zasoby naraz; kilka warningów jest wtedy normalne. Problemem są tylko komunikaty, które wracają podczas gry.
• sync thread hitch warning lub network thread hitch warning — Te warianty zwykle wskazują na warstwę synchronizacji: zbyt wiele encji lub graczy. Posprzątaj encje (krok 2, punkt 4) i sprawdź, czy OneSync Infinity jest włączony.
• Przycięcia o stałych porach — Jeśli przycięcie wraca dokładnie co pięć lub dziesięć minut, winne jest niemal zawsze zadanie okresowe: pętla zapisu, która zapisuje wszystkich graczy naraz, albo backup w godzinach szczytu. Rozłóż zapisywanie w skryptach w czasie, a backupy zaplanuj na noc w zakładkach Schedules i Backups.
• Rubber banding bez hitch warningów w konsoli — Wtedy problem leży prawdopodobnie po stronie klienta lub sieci gracza. Poproś dotkniętych graczy o sprawdzenie własnych fps i resmon; częstą przyczyną są zbyt ciężkie YTD.
• Warningi nie znikają po wszystkich krokach — Zaraz po przycięciu wykonaj nagranie profilera poleceniem profiler record 500 i zachowaj wynik; dzięki temu znacznie szybciej ustalisz przyczynę.

Potrzebujesz pomocy?

Z resmon i profilerem znajdziesz niemal każdą przyczynę lagów serwera w kilka minut. Jeśli utkniesz, otwórz ticket przez naszą stronę pomocy i podaj dokładny komunikat z zakładki Console oraz swoje obserwacje z resmon lub profilera.