Como otimizar servidor MTA:SA: performance, tickrate e fim do lag

Conecte no console do servidor (via terminal local ou painel) e habilite o monitor de performance interno:

debugscript 3
showperf

O comando showperf exibe o tempo médio de processamento por frame em milissegundos, separado por categoria (sync, scripts, banco). Anote os valores em servidor vazio e com pelo menos 50% da capacidade ocupada.

No shell do Linux, capture uso de CPU por thread do processo:

top -H -p $(pgrep -f mta-server64)

A thread principal (geralmente a primeira listada com mais CPU) é onde scripts Lua executam. Se ela está em 95-100% e o servidor é multi-core, você tem um gargalo single-threaded — comum em MTA, que não paraleliza Lua.

Veja o uso de rede em tempo real:

sudo iftop -i eth0 -P -B

Note a banda usada por jogador conectado. Um servidor saudável usa 8-15 KB/s por jogador no estado normal. Acima de 25 KB/s indica sync rate alto demais ou broadcast desnecessário em scripts.

Localize o arquivo (normalmente em /home/mta/mods/deathmatch/mtaserver.conf) e abra com editor de sua preferência. Procure as seções de sync.

Configure os intervalos pra um servidor de 60-100 jogadores com objetivo de gameplay fluido:

<player_sync_interval>100</player_sync_interval>
<light_sync_interval>1500</light_sync_interval>
<camera_sync_interval>500</camera_sync_interval>
<ped_sync_interval>400</ped_sync_interval>
<unoccupied_vehicle_sync_interval>1000</unoccupied_vehicle_sync_interval>
<keysync_mouse_sync_interval>100</keysync_mouse_sync_interval>
<keysync_analog_sync_interval>100</keysync_analog_sync_interval>

Esses valores são o sweet spot pra DM e roleplay. Pra servidores de racing competitivo, reduza player_sync_interval pra 80 e keysync_mouse_sync_interval pra 80 — você ganha responsividade ao custo de ~25% mais banda por jogador.

Ajuste o limite de FPS do servidor e a alocação de recursos do simulador físico:

<fps_limit>0</fps_limit>
<server_logic_fps>100</server_logic_fps>
<bandwidth_reduction>none</bandwidth_reduction>

fps_limit=0 desabilita o limite no cliente — isso não afeta o servidor diretamente mas evita que jogadores reclamem de cap artificial. server_logic_fps=100 é o padrão e quase nunca precisa mudar. bandwidth_reduction em “medium” só vale se sua banda total está estourando.

Reinicie o servidor e meça de novo:

sudo systemctl restart mta-server

Repita showperf e iftop após 10 minutos de operação com jogadores. Os tempos de frame devem estar consistentes abaixo de 12ms na thread principal.

No console do servidor, ative o profiler embutido por 60 segundos com o servidor sob carga real:

debugscript 3
debug-resources --top 10

A saída lista os 10 resources que mais consomem CPU em ms por frame. Foque nos 3 primeiros — eles geralmente respondem por 50%+ do consumo total.

Identifique e elimine setTimer com intervalo curto. Esse é o anti-pattern mais comum:

setTimer(function()
    for _, player in ipairs(getElementsByType("player")) do
        local money = getPlayerMoney(player)
    end
end, 50, 0)

Esse código roda 20 vezes por segundo iterando todos os jogadores. Em servidor com 80 jogadores, são 1600 iterações por segundo só pra esse timer. Substitua por eventos disparados sob demanda:

addEventHandler("onPlayerMoneyChange", root, function()
end)

Cache resultados de getElementsByType e similares. Cada chamada percorre a árvore de elementos do servidor:

local cachedPlayers = {}

addEventHandler("onPlayerJoin", root, function()
    table.insert(cachedPlayers, source)
end)

addEventHandler("onPlayerQuit", root, function()
    for i, p in ipairs(cachedPlayers) do
        if p == source then
            table.remove(cachedPlayers, i)
            break
        end
    end
end)

Iterar cachedPlayers é 10-30x mais rápido que getElementsByType("player") em loop apertado.

No primeiro carregamento do banco, ative WAL mode via SQL:

executeSQLQuery("PRAGMA journal_mode=WAL")
executeSQLQuery("PRAGMA synchronous=NORMAL")
executeSQLQuery("PRAGMA cache_size=-20000")

WAL permite leituras concorrentes com escritas. synchronous=NORMAL reduz fsync sem comprometer durabilidade catastroficamente — aceita perder o último 1 segundo em caso de crash do servidor. cache_size=-20000 aloca 20 MB de cache pro SQLite.

Identifique queries lentas habilitando log temporário:

local startTime = getTickCount()
local result = executeSQLQuery("SELECT * FROM accounts WHERE last_login > ?", os.time() - 86400)
local elapsed = getTickCount() - startTime
if elapsed > 50 then
    outputDebugString("Query lenta: " .. elapsed .. "ms")
end

Qualquer query acima de 50ms bloqueia a main thread e é candidata a otimização — adicione índices em colunas de busca ou paginação em resultados grandes.

Habilite fq_codel como qdisc na interface principal:

sudo tc qdisc replace dev eth0 root fq_codel

fq_codel elimina bufferbloat, mantendo latência consistente mesmo com a banda saturada. A diferença prática: jogadores no horário de pico não veem mais ping subir de 30ms pra 200ms quando o tráfego total cresce.

Aumente os buffers de UDP no kernel:

sudo sysctl -w net.core.rmem_max=8388608
sudo sysctl -w net.core.wmem_max=8388608
sudo sysctl -w net.core.netdev_max_backlog=5000

Persista em /etc/sysctl.d/99-mta.conf pra sobreviver a reboot. Buffers maiores absorvem rajadas sem dropar pacotes, que é o que causa rubberbanding quando o link enche.