Como Otimizar Servidor SA-MP: Performance, Tickrate e Desync

Servidores SA-MP com 50 ou mais jogadores simultâneos costumam acumular três sintomas previsíveis: queda de tickrate quando há combate intenso, desync em perseguições de carro e travamento momentâneo quando muitos jogadores entram ao mesmo tempo. Na maioria dos casos, o gargalo não está na CPU do host — está em loops mal escritos no gamemode, plugins desatualizados e parâmetros conservadores no server.cfg que nunca foram revistos depois do deploy inicial.

Este guia é para você que administra um servidor SA-MP ou open.mp em produção, tem acesso SSH ao host e sabe recompilar gamemode em Pawn. Tempo estimado de execução completa: 90 a 120 minutos, incluindo medições antes e depois. Cada seção é independente — você pode aplicar só as partes relevantes ao seu cenário.

A diferença entre um servidor que aguenta 200 slots em horário de pico e outro que trava com 60 raramente é hardware. É configuração.

Pré-requisitos

Verifique o estado atual antes de mudar qualquer coisa. Registre estes números — sem baseline, você não tem como provar que a otimização funcionou:

Ajustar server.cfg

O server.cfg é o lugar mais barato para ganhar performance — mudanças aqui não exigem recompilar nada e podem reduzir desync em minutos. A maioria dos servidores roda com valores padrão herdados de tutoriais de 2014 que não fazem mais sentido em hardware moderno.

cd /home/samp/server
nano server.cfg

sleep 5
lagcompmode 1
playertimeout 10000
stream_distance 300.0
stream_rate 1000
maxnpc 0
onfoot_rate 30
incar_rate 30
weapon_rate 30

systemctl restart samp-server

tail -n 50 server_log.txt

Auditar o gamemode em Pawn

A maior fonte de lag em servidores SA-MP estabelecidos é código antigo no gamemode — especialmente loops for(new i = 0; i < MAX_PLAYERS; i++) que rodam dentro de timers de 100ms. Cada um desses loops, multiplicado pela frequência do timer, pode consumir mais CPU do que todos os plugins juntos.

grep -rn "MAX_PLAYERS" gamemodes/*.pwn | grep -v "Iter_"

// Antes — itera sobre 1000 slots mesmo com 50 jogadores
for(new i = 0; i < MAX_PLAYERS; i++)
{
    if(IsPlayerConnected(i))
    {
        // logica
    }
}

// Depois — itera apenas sobre conectados
foreach(new i : Player)
{
    // logica
}

grep -rn "SetTimer" gamemodes/*.pwn

Atualizar plugins essenciais

Plugins SA-MP têm impacto direto no consumo de CPU e na latência percebida. Versões antigas de streamer e sscanf podem custar até 10 vezes mais por chamada que as versões atuais — e quase todo servidor estabelecido roda com binários compilados há 5 ou mais anos.

cd /home/samp/server/plugins
ls -la

plugins streamer sscanf mysql Pawn.RakNet YSF

Tuning de rede no host

O sistema operacional do host tem parâmetros de kernel que afetam diretamente a latência de UDP — protocolo usado pelo SA-MP. Os valores default do Linux são otimizados para TCP de longa duração, não para o pattern de muitos pacotes pequenos e frequentes do SA-MP.

sudo nano /etc/sysctl.d/99-samp.conf

net.core.rmem_max = 26214400
net.core.wmem_max = 26214400
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.netdev_max_backlog = 5000
net.ipv4.udp_mem = 8388608 12582912 16777216

sudo sysctl -p /etc/sysctl.d/99-samp.conf

sysctl net.core.rmem_max

Verificação

Confirme as melhorias com medições objetivas. Sem números antes e depois, é impossível distinguir otimização real de placebo.

Conecte 30 a 50 jogadores reais ou bots de teste durante 30 minutos e registre:

htop

CPU consumida pelo processo samp03svr deve estar abaixo de 40% em um core durante carga normal. Memória deve estar estável — crescimento contínuo indica vazamento no gamemode, geralmente em variáveis dinâmicas não desalocadas.

Para latência percebida pelos jogadores, use o comando /ping em jogo ou observe a coluna PING no /players. Pings consistentes abaixo de 80ms para jogadores brasileiros indicam rede saudável. Variação maior que 30ms entre amostras indica jitter — problema de rota, não de servidor.

Resolução de problemas

Servidor crasha após atualizar plugins

Recompile o gamemode com os includes correspondentes às novas versões dos plugins. Assinaturas de funções mudam entre releases — chamar uma função antiga com argumentos novos causa erro de stack que derruba o processo. Verifique o crashlog em crashinfo.txt na raiz do servidor.

CPU continua alta após refatoração

Rode o Profiler em homologação por 1 hora com jogadores reais e identifique callbacks que não foram refatorados. Loops residuais em OnPlayerUpdate (chamado dezenas de vezes por segundo por jogador) consomem CPU exponencialmente — esse callback nunca deve conter loops sobre todos os jogadores.

Desync persiste mesmo com lagcompmode correto

Verifique packetloss da rota com mtr -r -c 100 IP_DO_SERVIDOR do seu computador. Qualquer hop com perda acima de 0,5% indica problema de rede do datacenter ou do trânsito. Esse tipo de desync não tem solução em software — exige troca de provedor ou rota.

Próximos passos

Com o servidor otimizado, considere estes próximos investimentos técnicos:

• Migrar para open.mp se ainda estiver em SA-MP 0.3.7-R5 — recompilação custa horas, ganho de performance e segurança é permanente.
• Implementar anti-cheat server-side com Pawn.RakNet — bloqueia 90% dos hacks comuns sem dependência de cliente.
• Monitorar via graphite + grafana ou painel da Hostini — observar tickrate e CPU ao longo de semanas revela padrões invisíveis em diagnóstico pontual.
• Avaliar DDoS protection dedicada para UDP — ataques contra a porta 7777 são frequentes em servidores SA-MP populares.

Se você está hospedando um servidor SA-MP em crescimento, vale considerar a hospedagem dedicada para jogos da Hostini — VPS com KVM completo, proteção DDoS para UDP e datacenters em São Paulo e Miami com baixa latência para Brasil e Hispanoamérica. Sem oversell, sem compartilhamento de core com outros tenants.