Pular para o conteúdo
Nesta página

Documentação / Operar o servidor

Descobrir o que causa lag

Quando o servidor trava ou os jogadores perdem FPS, o fivedock perf aponta os recursos por trás disso, até o arquivo e a linha. Ele lê o profiler do próprio FXServer, então nada muda no servidor.

Deixe o agente usar o profiler

O FXServer só deixa um recurso iniciar o profiler se o server.cfg permitir. O bloco que o painel entrega ao conectar um servidor já tem estas linhas. Em um servidor conectado antes, adicione-as e reinicie o recurso fivedock:

server.cfg
add_ace resource.fivedock command.profiler allow
add_ace resource.fivedock command.record allow
add_ace resource.fivedock command.saveJSON allow

fivedock_check no console do servidor diz se o profiler está liberado. Sem estas linhas, o relatório ainda conta comandos e mede o FPS, e diz quais linhas faltam.

Meça o servidor

Rode enquanto o servidor está com lag, em uma máquina que faz backup dele (fivedock servers add). O agente grava 10 segundos, ou de 3 a 20 com --seconds, conta os comandos de cada recurso, mede o jogo de cada jogador e lê os scripts de cliente e as páginas de UI que os jogadores baixam. --json imprime o mesmo relatório para scripts.

shell
fivedock perf my-city
fivedock perf my-city --seconds 20

Leia o relatório

Um relatório de um servidor que um job de lixeiro trava a cada poucos segundos, e cujo pack de emotes registra um comando por emote:

fivedock perf my-city
my-city  profiled 10 s · 214 players online
  server thread  late by 3.8 ms on average, 212 ms at worst in the last minute

Server  198 ticks, the slowest took 212 ms
  resource          total   per tick  worst tick
  jobs_garbage   1,236 ms     6.2 ms      205 ms
  hud              412 ms     2.1 ms      6.3 ms
  oxmysql           96 ms     0.5 ms       14 ms
  emotes            12 ms     0.1 ms      0.4 ms

Where exactly  the threads, events and exports that took longest
  jobs_garbage     611 ms  thread · server/main.lua:88-131 · 3× · worst 203 ms
  jobs_garbage     598 ms  thread · server/main.lua:12-40 · 198× · worst 6.1 ms
  hud              380 ms  event hud:sync · server.lua:52-77 · 1,420× · worst 4.2 ms
  oxmysql           88 ms  export · dist/build.js:310 · 402× · worst 14 ms

Commands  on the server, and in the game of 3 sampled players
  resource     server  players
  emotes            –    2,034
  admin_menu       61       12
  hud               9        4
  total           248    2,310
  A command per emote or item adds up fast. Check whether that resource needs them all.

Players  207 of 214 answered · 5 players in the pause menu or loading, left out
  FPS          24 for the slowest tenth · 47 median · 71 for the fastest tenth
  1% low       19 median · 64 players had a frame over 50 ms
  around them  980 objects · 310 peds · 180 vehicles (median)
  slowest
    Player 112   13 fps  1% low 4 · 9 frames over 50 ms · 4,210 objects  at 1693, 3245
    Player 17    16 fps  1% low 6 · 7 frames over 50 ms · 3,980 objects · a UI open  at 1702, 3251

Where exactly, in players’ games  the client functions that cost most, in the game they cost most
  hud              3.8 ms  thread · client/status.lua:14 · 9 players
  jobs_garbage     2.4 ms  thread · client/bags.lua:52 · 4 players
  phone            0.9 ms  NUI getMessages · client/nui.lua:88 · 2 players
  hud              0.6 ms  event hud:updateStatus · client/main.lua:120 · 12 players
  Measured in 31 traced resources, per frame.

Entities scripts made  in a player’s own game, the most any one of them had
  jobs_garbage  2,940 objects
  hud           12 objects
  A script that spawns props or peds and never deletes them slows every frame after.

Client loops that never sleep  each runs on every frame, in every player’s game
  hud         2  client/status.lua:14 · client/minimap.lua:41
  A while true do whose only Wait is Wait(0), or a setTick. resmon 1 in F8 shows what each costs.

UI pages  each loads in every player’s game on join and stays loaded
  phone      41.8 MiB  video ui/wallpapers/live.mp4 · endless animation ×4 ui/assets/index.css:1 · backdrop blur ×6 ui/assets/index.css:1
  hud         0.6 MiB  endless animation html/hud.css:212
  An endless animation, a backdrop blur or a video makes the game’s browser repaint every frame while it shows.

Streamed to every player  the heaviest packs, from the last asset scan
  [cars]       2.4 GiB · 23 texture dictionaries over 16 MiB
  sandy_mlo  479.7 MiB · 2 texture dictionaries over 16 MiB
  fivedock optimize <folder> shows what shrinking them saves, and --apply does it.

  Escrowed, so their client code could not be read: vehicle_shop

Exact cost per client resource  only a player’s own profiler can see it
  Ask Player 112 to type these two lines in F8:
    profiler record 500
    profiler saveJSON lag.json
  It saves into FiveM Application Data › citizen. fivedock perf --file lag.json reads it.

Stalls the agent caught  each one recorded for 10 s after it happened
  21:04  212 ms stall  then jobs_garbage took 203 ms in one tick
         jobs_garbage · server/main.lua:88-131

FPS drops the agent caught  players below 40 fps and well under their usual, newest first
  21:12  Player 112   58 → 14 fps  jobs_garbage
         jobs_garbage spawned 1,800 objects in the minute before
  20:51  Player 17    71 → 22 fps
         driving at 170 km/h, so the game streams fast
  20:30  Player 64    66 → 19 fps  phone
         phone started in the minute before · a UI had focus · the phone UI has a video and an endless animation
Server
Os recursos que mais usaram tempo de script durante a gravação. per tick é o custo médio por frame do servidor, worst tick o frame mais lento. Acima de 50 ms, os jogadores sentem como uma travada.
Where exactly
Esse tempo dividido em threads, handlers de eventos e exports, com o arquivo, as linhas, quantas vezes cada um rodou e a execução mais lenta. Uma thread que roda todo tick e custa milissegundos a cada vez geralmente espera pouco demais entre as voltas.
Commands
Os comandos de cada recurso, no servidor e no jogo de três jogadores. Um recurso com centenas deles costuma registrar um comando por emote ou item.
Players
O FPS do décimo mais lento dos jogadores, a mediana e o décimo mais rápido, o 1% low deles (o FPS dos quadros mais lentos) e quantos tiveram um quadro acima de 50 ms, o que há ao redor deles, e os cinco jogadores mais lentos com onde estão. Jogadores no menu de pausa ou ainda carregando ficam de fora. Se os lentos estão no mesmo lugar, veja o que é streamado ali.
Where exactly, in players’ games
Nos recursos com o profiler do cliente, as funções que mais custam por quadro, no jogo em que mais custam, com o arquivo, a linha e em quantos jogos apareceram. Sem o profiler, o relatório diz como adicionar.
Entities scripts made
Props, peds e veículos que os scripts de cliente de um recurso criaram no jogo de um jogador, o máximo que qualquer um deles teve. Centenas vindas de um só recurso costumam significar que ele os cria e nunca apaga.
Client loops that never sleep
Loops de cliente que acordam a cada quadro e nunca podem dormir: um while true do cuja única espera é Wait(0), ou um setTick. Loops que saem, que às vezes esperam mais ou que só rodam em debug ficam de fora. resmon 1 no console F8 de um jogador mostra quanto cada um custa.
UI pages
A página de UI de cada recurso carrega no jogo de cada jogador ao entrar e continua carregada. O relatório aponta as pesadas e o que faz o navegador do jogo redesenhar enquanto elas aparecem: animações CSS infinitas, desfoque de fundo (backdrop blur) e vídeo, com o arquivo e a linha, além de imagens acima de 1 MiB e páginas carregadas de outro site.
Streamed to every player
Os pacotes streamados mais pesados e seus dicionários de texturas acima de 16 MiB, do último scan de assets do agente. fivedock optimize reduz essas texturas.
Stalls the agent caught
As travadas que o agente gravou sozinho, da mais recente para a mais antiga.
FPS drops the agent caught
As quedas que a vigilância de FPS registrou, da mais recente para a mais antiga, cada uma com o que mudou no jogo daquele jogador. Com a vigilância desligada, o relatório diz como ligar.

Travadas que ele grava sozinho

Quando a thread do servidor para por 150 ms ou mais, o agente grava sozinho os 10 segundos seguintes, no máximo uma vez a cada 15 minutos, e guarda as três últimas até o recurso reiniciar. Se a travada não voltou durante a gravação, o relatório diz isso em vez de culpar o que estava rodando.

As quedas de FPS que ele registra sozinho

Com essas linhas, o agente vigia o FPS de cada jogador. O jogo deles lê o contador de quadros uma vez por segundo, então vigiar não custa nada em nenhum quadro. Quando um jogador fica abaixo do piso e bem abaixo do próprio FPS de costume por cinco segundos, o agente registra um aviso player.low_fps na Black Box: até quanto caiu, de quanto, e o que mudou no jogo dele logo antes. Pode ser um recurso que criou props ou peds, um que acabou de iniciar, uma UI com foco ou dirigir rápido demais para o streaming acompanhar. Um jogador é registrado no máximo uma vez a cada dez minutos.

server.cfg
set fivedock_fps_watch 1
set fivedock_fps_floor 40

fivedock_fps_floor é o piso, 40 FPS se você não mudar. Ligar ou desligar a vigilância no console vale em até 30 segundos, sem reiniciar. Filtre a Black Box por player.low_fps para ver todas as quedas; fivedock perf lista as dez últimas.

Veja a função do cliente por trás do FPS de cada jogador

O FiveM guarda os tempos de cada recurso dentro do jogo, fora do alcance dos scripts. fivedock trace coloca um pequeno profiler em cada recurso que dá para ler: uma linha no topo do manifesto e um fivedock_trace.lua ao lado. Ele fica parado até que fivedock perf ou a vigilância de FPS peça, e então mede por alguns segundos cada thread, handler de evento, callback de NUI e comando desse recurso. Recursos com escrow, protegidos pelo Skalp ou ofuscados ficam como estão, e a lista diz por quê.

shell
fivedock trace C:\FXServer\server-data\resources
fivedock trace C:\FXServer\server-data\resources --apply

Reinicie o servidor para os jogadores carregarem. A partir daí, o relatório e cada aviso player.low_fps apontam o recurso, o arquivo, a linha e quantos milissegundos por quadro custou. No Windows, o app faz o mesmo em Ferramentas, Profiler do cliente. Para tirar, com cada manifesto de volta byte a byte:

shell
fivedock trace C:\FXServer\server-data\resources --remove --apply

O FPS de um jogador

O que um script custa no jogo de um jogador só aquele jogo vê. Quando um jogador está com FPS baixo, peça que ele grave no F8 e te mande o arquivo:

F8
profiler record 500
profiler saveJSON lag.json

fivedock perf --file lê do mesmo jeito que uma gravação do servidor:

shell
fivedock perf --file lag.json

Para a medição, os jogadores recebem algumas linhas com o agente. Quando você pede, o jogo deles conta quadros por três segundos, anota se está pausado, carregando ou com uma UI aberta, conta os props, peds e veículos ao redor com o recurso que criou cada um, lista os comandos registrados e reúne o que o profiler do cliente mediu onde você o adicionou. Não lê mais nada nem envia nada por conta própria, a menos que você ligue a vigilância de FPS.

O que ele não vê

  • Uma travada que volta com menos frequência do que dura uma gravação. Rode fivedock perf --seconds 20 quando ela estiver para acontecer, ou deixe o agente pegá-la.
  • O tempo fora dos scripts: a rede, o servidor de banco de dados ou o streaming do próprio jogo. Um script que trava esperando o banco aparece, sim, como tempo dele.
  • O tempo dentro de um recurso sem o profiler do cliente: com escrow, protegido pelo Skalp, ofuscado ou escrito em JavaScript ou C#. A gravação de F8 de um jogador ainda mostra esses.
  • O que o código faz só às vezes. O relatório julga os loops e as páginas de UI lendo os arquivos, não cronometrando, então um loop pesado só de vez em quando não aparece, e o código de recursos com escrow não pode ser lido. O relatório cita esses recursos pelo nome.