Otimizar servidor FiveM: como melhorar performance e tickrate

Entre no servidor como jogador e abra o console com F8. Digite o comando do monitor de resources:

resmon 1

Isso abre a janela do Resource Monitor com modo verbose. As colunas que importam:

• CPU ms — tempo gasto no main thread por tick. Soma de todas as linhas é o orçamento total
• Memory — RAM consumida pelo resource (problema mais raro)
• Streaming — assets baixados pelo resource (relevante pra mapas)

Anote os 5 resources com maior CPU ms. Tire screenshot pra comparação depois.

No console do servidor (SSH ou janela do FXServer), rode o comando que mostra o tick atual:

status

Você vai ver linhas como Server thread hitch warning: frame time of 28ms. Frame time acima de 16.6ms significa que o servidor está perdendo ticks. Anote o valor médio durante 5 minutos de jogo normal.

Abra o txAdmin (porta padrão 40120) e vá em “Performance Chart”. Esse gráfico mostra histórico de tick rate dos últimos 60 minutos. Se você vê quedas regulares em horário de pico, o problema é carga — não bug pontual.

Abra seu server.cfg e localize as linhas de OneSync. A configuração recomendada pra servidores modernos:

set onesync on
set onesync_population true
set onesync_distanceCullVehicles true
sv_enforceGameBuild 2944
sv_maxclients 64

A flag onesync_distanceCullVehicles remove veículos parados longe dos jogadores — reduz drasticamente carga de sincronização. enforceGameBuild trava a versão do jogo pra evitar bugs introduzidos por updates da Rockstar.

Se você está rodando OneSync legacy e quer migrar pra infinity, troque a linha e teste seus recursos:

set onesync infinity

Reinicie o servidor e teste cada script crítico (combate, inventário, garagem). Recursos que dependiam de IDs de network locais podem quebrar — a API do infinity usa state bags e routing buckets em vez disso.

Volte ao resmon e abra os 3 resources com maior CPU ms. Procure no código por padrões problemáticos. O mais comum é loop sem Wait apropriado:

-- RUIM: roda toda frame, queima CPU
CreateThread(function()
  while true do
    local player = PlayerPedId()
    -- lógica aqui
    Wait(0)
  end
end)

Wait(0) significa “rodar a cada frame”. Se a verificação não precisa ser tão frequente, suba pra Wait(500) ou Wait(1000). Diferença prática: um loop com Wait(0) roda 60 vezes por segundo; com Wait(1000) roda 1 vez. Pra checks de proximidade, status de UI ou polling de inventário, 500-1000ms é suficiente.

Procure por queries SQL síncronas em hot paths (eventos chamados frequentemente). Substitua por async:

-- RUIM: bloqueia o thread
local result = MySQL.Sync.fetchAll("SELECT * FROM users WHERE id = ?", {id})

-- BOM: callback assíncrono
MySQL.Async.fetchAll("SELECT * FROM users WHERE id = ?", {id}, function(result)
  -- processa aqui
end)

Sync queries bloqueiam o main thread inteiro enquanto o banco responde — mesmo que demore só 5ms, é 5ms perdido a cada chamada.

Eventos client→server disparados em alta frequência são um dos maiores ofensores. Procure por TriggerServerEvent dentro de loops de jogador e adicione throttling:

-- Antes
CreateThread(function()
  while true do
    TriggerServerEvent("updatePlayerPosition", GetEntityCoords(PlayerPedId()))
    Wait(100)  -- 10 eventos por segundo, por jogador
  end
end)

-- Depois
CreateThread(function()
  while true do
    TriggerServerEvent("updatePlayerPosition", GetEntityCoords(PlayerPedId()))
    Wait(2000)  -- 1 evento a cada 2s — suficiente pra maioria dos casos
  end
end)

Com 50 jogadores, isso é a diferença entre 500 eventos/segundo e 25 eventos/segundo no servidor.

Organize sua pasta stream/ em subdiretórios por categoria — o FXServer indexa mais rápido:

resources/[maps]/meu-mapa/
├── fxmanifest.lua
├── stream/
│   ├── ymap/
│   ├── ytd/
│   └── ydr/

Pastas planas com 5000+ arquivos no mesmo diretório fazem o servidor demorar 10-30 segundos a mais pra iniciar.

Habilite cache asset no server.cfg:

sv_assetCacheEnabled true

Isso permite que clientes mantenham assets em cache entre sessões, reduzindo download repetido — menos pressão de I/O e rede quando jogadores reconectam.

Identifique mapas duplicados ou conflitantes. Use o comando no console do servidor pra listar resources com assets:

list

Procure por dois resources streamando o mesmo ymap (ex: dois MLOs do mesmo prédio). Conflito de streaming causa flickering e às vezes crash. Desabilite o duplicado.

Compare o resmon antes/depois com servidor cheio. Cada resource que você otimizou deve ter caído pelo menos 30%. Soma total dos resources idealmente abaixo de 12ms.

No txAdmin, observe o Performance Chart por 30 minutos em horário de pico. Tick rate deve manter 60 Hz com no máximo 1-2 dips curtos. Frame time médio abaixo de 16.6ms.

Peça feedback de 3-5 jogadores ativos. Pergunte especificamente sobre lag de input em combate e sincronização de veículos. Métrica numérica não captura percepção — jogador percebe stutter de 8ms que o resmon não destaca.