Výkon serveru FiveM a resmon

Když server FiveM lagguje, příčinou jsou téměř vždy jeden nebo dva resources a najdeš je třemi nástroji: resmon 1 v konzoli F8 na klientu ukáže, kolik skripty stojí na počítači každého hráče, profiler record v konzoli serveru ukáže, kolik stojí na hlavním vlákně serveru, a hitch warningy spolu s grafem ticků v txAdminu říkají, kdy se to děje. Víc paměti málokdy něco změní a víc jader změní málo, protože práce, na které záleží, běží na jednom vlákně. Tento návod vysvětluje, jak číst jednotlivé nástroje, co čísla znamenají, jaké vzory kódu se ve výsledcích pořád objevují a v jakém pořadí postupovat, abys opravil příčinu, a ne si ji jen koupil z cesty.

Dva druhy lagu a proč záleží na tom, který máš#

Hráči říkají „server lagguje“ o dvou různých problémech a ty potřebují různé nástroje.

Náklady na straně klienta jsou čas snímku na počítači samotného hráče. Každý klientský skript běží uvnitř snímku hry. Resource, který dělá příliš mnoho v každém snímku, snižuje FPS všem, ale jen dokud je pro ně aktivní. Příznaky: nízké nebo nerovnoměrné FPS, horší na určitých místech (u značky práce, uvnitř interiéru se spuštěným skriptem), nezávislé na tom, kolik lidí je online. Server přitom může být naprosto zdravý.

Náklady na straně serveru jsou čas na hlavním vlákně FXServeru. Serverové skripty, obsluhy událostí a časovače tam všechny běží postupně, takže jedna pomalá obsluha zdrží všechno, co čeká za ní - včetně zpracování, které drží hráče v synchronizaci. Příznaky: rubber-banding, skákající vozidla, dveře a inventáře reagující se zpožděním, příkazy s / odpovídající sekundu, postižení všichni najednou. FPS je v pořádku.

Existuje i třetí věc, která vypadá jako obojí a není ani jedno: síť. Ztráta paketů mezi jedním hráčem a serverem způsobí rubber-banding jen jemu, zatímco všichni ostatní jsou spokojení. Pokud si stěžuje jen jeden člověk, začni u latence, jitteru a ztráty paketů, ne u svých skriptů.

resmon: kolik stojí každý resource klienta#

Otevři ve hře konzoli F8 a napiš:

resmon 1

resmon 0 ji zase zavře. Překryvná vrstva vypíše každý běžící resource s CPU časem, který spotřeboval za snímek v milisekundách, a s pamětí, kterou drží na klientu. Seřaď podle CPU času a minutu to sleduj, zatímco děláš běžné věci - chodíš, nasedáš do auta, otevíráš inventář - protože cena často závisí na tom, co hráč dělá.

Jak číst čísla: při 60 FPS má hra na vytvoření snímku asi 16,7 ms a většinu z toho potřebuje sama hra. Resource, který je nečinný - nic na obrazovce, hráč nikde poblíž jeho funkce - by měl ukazovat 0.00 nebo 0.01 ms. HUD, minimapa nebo hlasový resource, které opravdu kreslí v každém snímku, mohou být na několika setinách. Cokoli, co v klidu přesahuje asi 0.10 ms, dělá práci, kterou dělat nemusí, a cokoli pravidelně nad 0.5 ms je skutečný problém samo o sobě. Deset resources po 0.2 ms je dvě milisekundy z každého snímku pryč, než hráč vůbec něco udělal.

Paměť v resmonu je halda Lua každého resource. Hodnota, která během půl hodiny stále stoupá a nikdy neklesne zpět, je únik - tabulky, do kterých se přidává a nikdy se nečistí, obvykle cache klíčovaná něčím, co se pořád mění. Velké, ale ploché číslo je jen resource, který drží hodně dat, a je méně zajímavé.

Omezení je, že resmon měří jen klientské skripty. Resource může být na klientu skoro zdarma a přesto být tím, který ničí tvůj server, takže tady nekonči.

Strana serveru: hitch warningy a profiler#

FXServer vypíše varování, když jedno z jeho vláken trvá mezi tiky mnohem déle, než by mělo:

[ citizen-server-impl] server thread hitch warning: timer interval of 412 milliseconds[ citizen-server-impl] sync thread hitch warning: timer interval of 187 milliseconds[ citizen-server-impl] network thread hitch warning: timer interval of 158 milliseconds

Čti je podle vlákna. Server thread je místo, kde běží tvoje resources v Lua, JavaScriptu a C#; zasekávání tam je téměř vždy skript. Sync thread obsluhuje stav OneSync - entity, jejich pozice a kdo je vlastní - a zasekávání tam obvykle znamená příliš mnoho entit nebo něco, co spamuje změny stavu. Network thread odesílá a přijímá pakety; zasekávání tam na jinak zdravém hostingu ukazuje na velmi velká data v událostech nebo přetížený stroj.

Občasné zasekání při startu nebo při restartu velkého resource je normální. Stálý pramínek, zatímco jsou hráči online, je to, co je třeba opravit. Poznamenej si čas každého z nich a co se právě dělo ve hře - zaseknutí pokaždé, když někdo otevře obchod, je už z poloviny diagnóza. Oddělování těchto řádků od zbytku výstupu řeší čtení konzole.

Abys zjistil, který resource je způsobil, použij vestavěný profiler z konzole serveru:

profiler record 500

Zaznamená dalších 500 ticků serveru. Až skončí, spusť profiler view a FXServer vypíše odkaz, který otevře záznam v časové ose v prohlížeči založeném na Chromu. profiler save zapíše záznam místo toho do souboru, což se hodí, když je konzole vzdálená a chceš si ho prohlédnout později nebo ho poslat tomu, kdo resource napsal. Stejné příkazy profiler fungují i v konzoli F8 na klientu, čímž se dostaneš na jednom klientu hlouběji než s resmonem.

Na časové ose je každý tick blok a uvnitř vidíš, který resource a která funkce spotřebovaly čas. Hledáš široké pruhy: obsluhu jednoho resource, která trvá desítky milisekund, zatímco všechno ostatní zlomky jedné. Nahrávej, zatímco problém nastává - profil klidného serveru ve 4 ráno nic nedokazuje. Pokud lag přichází ve špičkách, nahraj víc ticků, aby špička padla do okna.

Graf výkonu v txAdminu#

txAdmin vede průběžný histogram časů ticků vláken FXServeru a kreslí ho na svém dashboardu. Novější verze umožňují přepínat mezi hlavním, sync a network vláknem. Každý sloupec je časový úsek; barvy ukazují, jaký zlomek ticků spadl do kterého koše délky.

Zdravý server tráví téměř všechny své ticky v nejrychlejším koši, celý den. Hledáš ocas: malý, stálý zlomek pomalých ticků, který se objevuje v určitých hodinách nebo po určité době provozu. Právě tento tvar hráči pociťují jako periodické sekání, ne jako stálý lag, a bez otevření profileru ti řekne dvě užitečné věci - kdy se to děje (porovnej s počtem hráčů a s tím, co se ve hře dělo) a zda se to s uptime zhoršuje, což ukazuje na únik nebo hromadění entit, ne na jednu drahou obsluhu.

txAdmin také restartuje server, jehož hlavní vlákno přestane úplně reagovat. Pokud se to děje opakovaně, dalším krokem je profiler; zvýšení timeoutu zaseknutí jen prodlouží výpadek. Širší nastavení txAdminu je v nastavení serveru FiveM s txAdminem.

Vzory kódu, které se objevují pokaždé#

Profiluj dost serverů FiveM a stejná hrstka chyb vysvětlí většinu spotřebovaného času.

Smyčky, které běží každý snímek bez důvodu

Wait(0) znamená „spusť se znovu v dalším snímku“. Je to správně pro smyčku, která v každém snímku něco kreslí, a špatně pro téměř všechno ostatní. Běžný případ je značka nebo interakční bod kontrolovaný v každém snímku, zatímco hráč je na druhém konci mapy:

-- Costs CPU on every frame, everywhere on the mapCreateThread(function()    while true do        Wait(0)        local coords = GetEntityCoords(PlayerPedId())        if #(coords - shopCoords) < 2.0 then            DrawText3D(shopCoords, "[E] Open shop")        end    endend)

Oprava je spát úměrně vzdálenosti a přejít na každý snímek, jen když je hráč dost blízko, aby na tom záleželo:

CreateThread(function()    while true do        local sleep = 1000        local coords = GetEntityCoords(PlayerPedId())        local dist = #(coords - shopCoords)        if dist < 20.0 then            sleep = 0            if dist < 2.0 then                DrawText3D(shopCoords, "[E] Open shop")            end        end        Wait(sleep)    endend)

Tahle jediná změna posune resource z trvalých 0.1-0.3 ms na 0.00 pro každého, kdo nestojí u obchodu. Knihovny jako ox_lib nabízejí pomocníky pro body a zóny, které to dělají za tebe; použít je je lepší než ručně psát stejnou smyčku ve čtyřiceti resources.

Kontroly vzdálenosti dělané pomalu

#(a - b) na dvou hodnotách vector3 je čistě výpočet v Lua a velmi levný. GetDistanceBetweenCoords je volání nativní funkce s režií předávání dat a starší resources ho volají stokrát za snímek. Jeho nahrazení je mechanická změna s měřitelným výsledkem.

Serverové obsluhy, které dělají příliš mnoho

Na serveru jsou ekvivalentní chyby smyčka přes každého hráče s databázovým dotazem uvnitř, řetěz SetTimeout, který se spouští častěji, než se mění stav, který představuje, a obsluhy, které při každém volání provádějí json.encode velké tabulky. oxmysql je asynchronní, takže pomalý dotaz sám vlákno nezmrazí, ale obsluha, která jich při každé události vyšle padesát, ano - a fronta callbacků vracejících se později dopadne také na hlavní vlákno. Nastavení mysql_slow_query_warning způsobí, že oxmysql vypíše každý dotaz nad prahem; stranu databáze řeší databáze FiveM a oxmysql.

Příliš mnoho vysílání

TriggerClientEvent('name', -1, data) posílá každému hráči. Dělat to jednou za sekundu s velkou tabulkou - kompletní soupis povolání, peníze každého hráče - stojí čas network vlákna i čas klienta na každém počítači. Posílej jen to, co se změnilo, jen hráčům, kteří to potřebují, a pro hodnoty, které čte mnoho klientů, ale zapisuje málo, preferuj state bagy.

Postup, který to najde za jeden večer#

1. Potvrď vrstvu. Zeptej se tří hráčů, jestli jim kleslo FPS, nebo jestli měli rubber-banding. Zkontroluj v konzoli hitch warningy v dobách, které uvádějí.
2. Strana klienta: nech jednoho hráče spustit resmon 1 a udělat screenshot, když je v klidu ve městě, a znovu na místě, kde lagguje. Poznamenej si každý resource nad 0.1 ms.
3. Strana serveru: spusť profiler record 500 ve špičce, zatímco lag je přítomný, potom profiler view. Poznamenej si nejširší resources.
4. Půl, co nepřečteš. Pokud profil ukazuje na jádro frameworku, do kterého volají desítky resources, zastav polovinu nepodstatných resources (stop name v konzoli), patnáct minut sleduj zasekávání a graf v txAdminu, potom je vrať. Zopakuj na polovině, na které záleželo.
5. Oprav nebo nahraď. Většina oprav jsou výše uvedené vzory smyček. Escrowed resources, které upravit nemůžeš, jdou zpět autorovi s tvým profilem, nebo se nahradí.
6. Změř znovu. Stejné podmínky, stejné příkazy. Pokud se číslo nehnulo, změna nezáležela, ať příspěvek na fóru sliboval cokoli.

Udělej to dřív, než změníš tarif. Na serveru s hlavním vláknem omezeným CPU paměť nepomůže vůbec a větší podíl CPU pomůže jen tehdy, když graf CPU v konzoli ukazuje, že skutečně sedíš na limitu. CPU vs RAM pro game servery je delší verze toho argumentu.

Co přispívá stroj#

Příčinou je obvykle kód, ale ne jedinou, a stojí za to vědět, jak vypadá strana hardwaru, abys ji mohl potvrdit nebo vyloučit.

• Podíl CPU. Práci serveru dominuje hlavní vlákno, takže takt záleží víc než počet jader. Druhé jádro přesto pomáhá: sync a network vlákna, obsluha assetů a klient databáze běží jinde. Pokud graf CPU ve špičce sedí na stropu tarifu, ticky se natahují a hitch warningy následují.
• Paměť. Paměť sleduje počet resources a to, co drží, ne počet hráčů. Málokdy je příčinou lagu; když dojde, server se zastaví, což je jiný problém.
• Entity. S OneSync stojí každé vozidlo, ped a objekt, které server sleduje, čas synchronizace. Ambientní populace, opuštěná vozidla, která nikdo nemaže, a props spawnované skripty a nikdy neuklizené se hromadí. Nastavení populace a culling řeší OneSync a sloty pro hráče.
• Streamované assety. Velké balíky vozidel a map stojí disk, šířku pásma a paměť klienta, ne CPU serveru. Pomalé první připojení je problém stahování; zabývají se jím MLO, mapy a streamované assety.

Na RE:NODE konzole kreslí paměť, CPU a disk proti limitům tarifu, takže vidíš, o který z nich se opíráš, než cokoli rozhodneš. CPU je tvrdě omezené na podíl, který jsi koupil: server připíchnutý na 100 % zpomalí a nikdy se kvůli tomu nepozastaví. Pokud paměť dosáhne limitu, kontejner se zastaví a čistě znovu spustí, místo aby se nechal swapovat - txAdmin a tvoje plánované restarty pokračují odtud.

Uptime, úniky a plánované restarty#

FXServer a frameworky na něm se při dlouhém uptime zhoršují. Haldy Lua rostou, počty entit pomalu stoupají, cache se plní. Server, který prvních šest hodin běží dobře a druhý večer sekává, ukazuje hromadění, ne jednu drahou obsluhu, a profiler ukáže mnoho resources, každý o trochu pomalejší, ne jeden široký pruh.

Poctivé opravy jsou najít resource, jehož paměť v resmonu nebo v jeho vlastním logování stoupá, a mezitím restartovat podle plánu. Restart každých šest až dvanáct hodin, oznámený ve hře několik minut předem, je na roleplay serverech běžná praxe; plánovač txAdminu zařídí oznámení i restart a úvaha o volbě hodiny je v článku restartovací plány, které pomáhají. Před každým plánovaným restartem je také správný okamžik na zálohu databáze, protože tam žijí postavy a peníze.

Restart není oprava úniku. Je to strop toho, jak špatný únik může být. Hledej resource dál.

Řešení potíží#

resmon neukazuje nic drahého, ale hráči mají pořád rubber-banding. Je to server nebo síť. Zkontroluj hitch warningy v době stížností a spusť profiler.

Profiler ukazuje jeden resource frameworku, který spotřebuje většinu času. Framework obvykle dělá práci za jiné resources - callbacky, použití předmětů, dohledávání dat hráčů. Podívej se na časové ose o úroveň níž, které obsluhy do něj volají, nebo půl resources, které na něm závisí.

Zasekávání každých pár minut, pravidelné jako hodiny. Něco na časovači: autosave, který zapisuje všechny hráče najednou, smyčka výplat, úloha perzistence vozidel. Rozlož práci mezi hráče, místo abys ji dělal celou v jednom ticku.

Lag jen během prvních minut po restartu. Resources načítají data, všichni se připojují najednou a stahují assety. Uklidní se to; pokud ne, nějaký resource při startu dělá velké synchronní načítání.

Lag se každý den zhoršuje až do restartu. Únik nebo hromadění entit. Sleduj paměť v resmonu a sync vlákno v průběhu provozu.

Jeden resource je drahý a escrowed. Nemůžeš ho upravit. Pošli autorovi svůj profil a screenshot z resmonu. Pokud se to neopraví, jeho nahrazení je levnější než stavět kolem něj server.

FAQ#

Jaká je dobrá hodnota resmonu pro resource FiveM?

V klidu 0.00 až 0.02 ms. Resources, které kreslí v každém snímku, například HUD, mohou rozumně sedět o trochu výš. Resource, který v klidu přesahuje 0.1 ms, plýtvá časem snímku, a ten, který pravidelně překračuje 0.5 ms, je problém sám o sobě.

Ukazuje resmon výkon na straně serveru?

Ne. resmon měří klientské skripty na počítači, kde ho spustíš. Pro server použij hitch warningy v konzoli, profiler record a profiler view a graf ticků v txAdminu.

Spraví lag FiveM větší tarif?

Jen pokud konzole ukazuje, že CPU ve špičce sedí na limitu tarifu. Většina lagu ve FiveM jsou jeden nebo dva resources blokující hlavní vlákno a víc paměti nebo vyšší limit to nechá přesně tak, jak to je. Nejdřív profiluj, pak rozhoduj.

Co znamená „server thread hitch warning“?

Hlavní vlákno serveru, kde běží resources, trvalo mezi tiky mnohem déle než obvykle - číslo říká, jak dlouho. Pár při startu je neškodných; stálý proud, zatímco lidé hrají, znamená, že resource blokuje vlákno a měl by se najít profilerem.

Proč je můj server pomalejší, čím déle běží?

Obvykle roste paměť v resource, který uniká, nebo se hromadí entity bez úklidu. Plánované restarty škodu omezí, ale příčina tam pořád je; sleduj paměť po jednotlivých resources v čase a najdeš ji.

Je Wait(0) vždycky špatně?

Ne. Je to správně pro cokoli, co se musí dít v každém snímku, například kreslení textu nebo značky, na kterou se hráč dívá. Je to špatně ve smyčce, která potřebuje reagovat jen několikrát za sekundu, což popisuje většinu smyček, které ho používají.