Cómo optimizar un servidor MTA:SA: rendimiento, tickrate y fin del lag

Conéctate a la consola del servidor (vía terminal local o panel) y habilita el monitor de rendimiento interno:

debugscript 3
showperf

El comando showperf muestra el tiempo medio de procesamiento por frame en milisegundos, separado por categoría (sync, scripts, base de datos). Anota los valores con el servidor vacío y con al menos el 50% de la capacidad ocupada.

En el shell de Linux, captura el uso de CPU por thread del proceso:

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

El thread principal (normalmente el primero listado con más CPU) es donde se ejecutan los scripts Lua. Si está al 95-100% y el servidor es multi-core, tienes un cuello de botella single-threaded — común en MTA, que no paraleliza Lua.

Mira el uso de red en tiempo real:

sudo iftop -i eth0 -P -B

Observa el ancho de banda usado por jugador conectado. Un servidor sano usa 8-15 KB/s por jugador en estado normal. Por encima de 25 KB/s indica sync rate demasiado alto o broadcast innecesario en scripts.

Localiza el archivo (normalmente en /home/mta/mods/deathmatch/mtaserver.conf) y ábrelo con el editor de tu preferencia. Busca las secciones de sync.

Configura los intervalos para un servidor de 60-100 jugadores con 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>

Esos valores son el sweet spot para DM y roleplay. Para servidores de racing competitivo, reduce player_sync_interval a 80 y keysync_mouse_sync_interval a 80 — ganas responsividad a costa de ~25% más banda por jugador.

Ajusta el límite de FPS del servidor y la asignación de recursos del simulador físico:

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

fps_limit=0 desactiva el límite en el cliente — esto no afecta directamente al servidor, pero evita que los jugadores se quejen de un cap artificial. server_logic_fps=100 es el valor por defecto y casi nunca hace falta cambiarlo. bandwidth_reduction en “medium” solo vale la pena si tu banda total está reventando.

Reinicia el servidor y vuelve a medir:

sudo systemctl restart mta-server

Repite showperf e iftop tras 10 minutos de operación con jugadores. Los tiempos de frame deben estar consistentemente por debajo de 12ms en el thread principal.

En la consola del servidor, activa el profiler embebido durante 60 segundos con el servidor bajo carga real:

debugscript 3
debug-resources --top 10

La salida lista los 10 resources que más consumen CPU en ms por frame. Concéntrate en los 3 primeros — normalmente responden por el 50%+ del consumo total.

Identifica y elimina setTimer con intervalo corto. Este es el anti-pattern más común:

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

Ese código corre 20 veces por segundo iterando todos los jugadores. En un servidor con 80 jugadores son 1600 iteraciones por segundo solo para ese timer. Sustitúyelo por eventos disparados bajo demanda:

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

Cachea resultados de getElementsByType y similares. Cada llamada recorre el árbol de elementos del 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 es 10-30x más rápido que getElementsByType("player") en un loop apretado.

En la primera carga de la base, activa WAL mode vía SQL:

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

WAL permite lecturas concurrentes con escrituras. synchronous=NORMAL reduce fsync sin comprometer la durabilidad de forma catastrófica — acepta perder el último 1 segundo en caso de crash del servidor. cache_size=-20000 asigna 20 MB de caché a SQLite.

Identifica queries lentas habilitando log temporal:

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

Cualquier query por encima de 50ms bloquea el main thread y es candidata a optimización — añade índices en columnas de búsqueda o paginación en resultados grandes.

Habilita fq_codel como qdisc en la interfaz principal:

sudo tc qdisc replace dev eth0 root fq_codel

fq_codel elimina el bufferbloat, manteniendo la latencia consistente incluso con la banda saturada. La diferencia práctica: los jugadores en hora pico ya no ven el ping subir de 30ms a 200ms cuando el tráfico total crece.

Aumenta los buffers de UDP en el 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

Persístelo en /etc/sysctl.d/99-mta.conf para sobrevivir al reboot. Buffers más grandes absorben ráfagas sin dropear paquetes, que es lo que provoca rubberbanding cuando el link se llena.