Jak zrychlit FiveM server: resmon, profiler a nejčastější chyby

Když FiveM server „laguje“, první reakcí bývá koupit větší tarif. Většinou to ale nepomůže: za zpožděním obvykle stojí jeden nebo několik skriptů, které zbytečně zatěžují hlavní vlákno serveru nebo klienta hráčů. Tento článek ukazuje, jak zjistit, kde problém je, pomocí nástrojů, které FiveM a txAdmin nabízejí, a jaké chyby ve skriptech se objevují nejčastěji.

Proč server laguje: server vs. klient

Serverová část FiveM (FXServer) zpracovává většinu práce skriptů v hlavním vlákně. Když jeden tick trvá déle, než by měl, server nestíhá a v konzoli se objeví varování o hitchi (hitch warning). Hráči to poznají jako zpožděné reakce, desynchronizaci nebo „teleportující se“ vozidla — a to u všech najednou. Protože jde o jedno vlákno, víc jader procesoru nepomůže; rozhoduje výkon jednoho jádra a hlavně to, kolik práce na vlákno skripty nakládají.

Druhý typ problému je na straně klienta: nízké FPS nebo záseky u hráčů, zatímco server běží v pořádku. Za tím bývají klientské skripty s náročnými smyčkami nebo těžké streamované assety. Než začnete cokoli optimalizovat, zjistěte, o který typ jde — mají jiné příčiny i jiné nástroje.

resmon: monitor resources na klientovi

Nejrychlejší první krok je vestavěný monitor resources. Ve hře otevřete konzoli klávesou F8 a zadejte:

resmon 1

Zobrazí se tabulka resources s časem procesoru v milisekundách a pamětí, kterou každý z nich na vašem klientovi zabírá. Pozor: resmon ukazuje klientskou stranu, ne server. Sledujte hlavně resources, které mají vysoký čas i ve chvíli, kdy se nic neděje — stojíte na místě, nemáte otevřené žádné menu. Jako hrubé komunitní pravidlo platí, že skript v nečinnosti by měl mít čas blízký nule a hodnoty, které trvale drží kolem desetin milisekundy a výš, stojí za prozkoumání. Není to přesná hranice; porovnávejte hlavně skripty mezi sebou.

Profiler na serveru

Pro serverovou stranu má FiveM vestavěný profiler. V konzoli serveru (v txAdminu nebo v panelu) spustíte záznam určitého počtu snímků, oficiální dokumentace doporučuje začít s 500:

profiler record 500
profiler status
profiler view
profiler saveJSON zaznam.json

profiler status ukáže, jestli záznam ještě běží. profiler view na serveru vypíše odkaz, který ručně otevřete v prohlížeči Chrome, a saveJSON uloží záznam do souboru, který lze později načíst v nástrojích pro vývojáře Chrome (záložka Performance). V časové ose uvidíte, které resources a funkce zabírají čas v jednotlivých tickách. Nahrávejte ve chvíli, kdy problém opravdu nastává — ideálně při plném serveru. Stejné příkazy fungují i v klientské konzoli F8. Podrobnosti jsou v dokumentaci profileru.

Grafy výkonu v txAdminu

Dashboard txAdminu zobrazuje výkon serveru a počet hráčů v čase. Díky tomu uvidíte, jestli se problémy objevují jen ve špičce, postupně narůstají od posledního restartu, nebo začaly po přidání konkrétního skriptu. Poznamenávejte si, kdy jste co měnili — bez toho se příčina hledá mnohem hůř.

Nejčastější chyby ve skriptech

• Smyčky s Wait(0) — běží každý snímek. Na klientovi jsou někdy nutné (vykreslování markerů, ovládání), ale často se používají i tam, kde stačí kontrola jednou za stovky milisekund. Dobrý vzor: pokud je hráč daleko od zóny, čekejte déle, a na Wait(0) přejděte až v její blízkosti.
• Dotazování místo událostí — skript v cyklu neustále zjišťuje stav (job, peníze, vozidlo), místo aby reagoval na událost, kterou framework při změně pošle.
• Databázové dotazy ve smyčkách — dotaz pro každého hráče v cyklu nebo při každém ticku. Data načtěte jednou, držte je v paměti a zapisujte hromadně.
• Chybějící indexy — tabulky, ve kterých se hledá podle identifikátoru hráče nebo vlastníka, bez indexu na daném sloupci. S rostoucím počtem řádků se takové dotazy zpomalují.
• Příliš mnoho resources a duplicity — dva skripty dělající totéž, staré verze vedle nových, nepoužívané resources, které se pořád spouštějí.
• Neoptimalizované MLO a streamované assety — velké textury a modely zatěžují hlavně klienty hráčů (paměť, načítání, FPS), ne procesor serveru.

-- Místo stálého Wait(0) čekejte podle vzdálenosti
CreateThread(function()
    while true do
        local sleep = 1000
        local dist = #(GetEntityCoords(PlayerPedId()) - zoneCoords)
        if dist < 10.0 then
            sleep = 0
            -- vykreslení markeru, kontrola klávesy
        end
        Wait(sleep)
    end
end)

Základy ladění databáze

Knihovna oxmysql umí upozornit na pomalé dotazy. Práh v milisekundách nastavíte convarem mysql_slow_query_warning a dočasně můžete zapnout i výpis dotazů jen pro vybrané resources přes mysql_debug:

set mysql_slow_query_warning 150
set mysql_debug ["podezrely_skript"]

Když víte, který dotaz je pomalý, zkontrolujte, jestli sloupce ve WHERE mají index, jestli dotaz nenačítá zbytečně celé tabulky (SELECT * u velkých tabulek) a jestli se nevolá častěji, než je nutné. Staré záznamy (logy, historie transakcí) pravidelně promazávejte nebo archivujte. Ladicí výpis po skončení vypněte — sám o sobě zaplňuje konzoli.

Pravidelné restarty a aktuální artifacts

Řada serverů plánuje restarty jednou až několikrát denně; txAdmin je umí nastavit s upozorněním pro hráče. Restart uvolní paměť, kterou si špatně napsané skripty postupně drží, ale je to obezlička, ne oprava — pokud výkon mezi restarty rychle klesá, hledejte příčinu profilerem. Udržujte také aktuální artifacts: novější buildy přinášejí opravy, jen po aktualizaci otestujte své skripty. Jak změnit verzi v našem panelu, popisuje návod FiveM artifacts. Před většími zásahy si udělejte zálohu — u nás ji spouštíte sami v panelu (základy panelu).

Hardware má svůj podíl: protože rozhoduje výkon jednoho jádra, u našich FiveM tarifů používáme procesory AMD Ryzen 9 5900X a NVMe SSD, s MySQL databází na stejném stroji. vCore je u nás limit na sdíleném fyzickém procesoru — vyšší počet vCore tedy sám o sobě nezrychlí hlavní vlákno. Co dalšího u hostingu sledovat, shrnuje článek Jak vybrat FiveM hosting, a volbu frameworku srovnání ESX vs QBCore vs Qbox.

Shrnutí

Nejdřív zjistěte, jestli trpí server, klient, nebo databáze. Na klientovi použijte resmon 1, na serveru profiler record a profiler view, v txAdminu sledujte vývoj výkonu v čase a u databáze zapněte varování oxmysql o pomalých dotazech. Nejčastěji pomůže opravit smyčky s Wait(0), nahradit dotazování událostmi, vytáhnout databázové dotazy ze smyček, doplnit indexy a odstranit zbytečné resources. Pravidelné restarty a aktuální artifacts jsou dobrý základ, ale skutečnou příčinu nenahradí.