Como reduzir o lag em servidores de RedM
Clock alto decide o desempenho, e Xeon de muitos núcleos vira gargalo. Como separar lag de ping, de script e de demora para entrar na sua cidade de RedM.
No RedM, lag custa mais caro do que em outros jogos. A comunidade é menor e mais concentrada, então o jogador que sai por causa de travada demora bem mais para ser reposto.
A boa notícia é que o diagnóstico é objetivo. "Lag" descreve quatro problemas diferentes, e cada um tem uma causa própria.
Os quatro tipos de lag
Delay entre a ação e a resposta. O personagem volta alguns metros, o cavalo anda aos pulos, o tiro não registra. Costuma ser ping.
A cidade inteira engasga. Todo mundo trava junto, geralmente no pico. Isso é processamento ou memória.
Travadas curtas e repetidas ao circular pelo mapa. Costuma ser carregamento de arquivos.
Demora para entrar. O jogador fica na tela de download. Isso não é lag, é entrega de arquivos.
O clock do processador é o gargalo número um
É o item que mais decide o desempenho, e o que mais gente ignora ao comparar planos.
O RedM roda no mesmo FXServer do FiveM, com a lógica principal concentrada, não espalhada por dezenas de núcleos. O que importa não é quantos núcleos a máquina tem, e sim quão rápido cada núcleo é.
E aqui está o erro mais caro do mercado: hospedagem barata costuma rodar em processadores Xeon de clock baixo. Eles têm muitos núcleos, o que é ótimo para virtualização e para dividir a máquina entre vários clientes, mas péssimo para servidor de jogo.
O resultado é uma máquina que parece potente na descrição, com um monte de vCPU listada, e que na prática engasga com poucas dezenas de jogadores. Não falta núcleo: falta velocidade em cada um.
Por isso na WyzeHost trabalhamos apenas com AMD Ryzen 9, de 4 GHz para cima, em toda a linha.
Como verificar na hospedagem que você já usa: olhe o modelo e o clock do processador, não só a quantidade de vCPU. Se for Xeon de geração antiga abaixo de 3 GHz, o gargalo provavelmente é esse, e nenhum upgrade de memória resolve.
Memória
Cresce com a quantidade de resources carregados. Uma VORP Core com muitos addons instalados consome bem mais que uma base enxuta.
O sintoma clássico é a cidade ficar boa depois de reiniciar e piorar ao longo do dia. Se o processador não está no limite e a memória está, é aí que você mexe. O dimensionamento está em como escolher a VPS para o seu servidor de RedM.
Os scripts
Nenhuma base sozinha faz a cidade travar. O que trava é o que você instalou em cima: loop rodando sem necessidade, evento disparado repetidas vezes, resource testado e esquecido ligado.
E isso se mede, não se adivinha. Como o RedM usa o mesmo cliente e o mesmo servidor do FiveM, as duas ferramentas de diagnóstico funcionam igual:
- resmon, que mostra quanto cada resource consome
- neteventlog, que mostra qual evento está sendo disparado repetidamente
O passo a passo dos dois, com os valores de referência para interpretar os números, está em como saber se a sua base precisa de otimização. O guia é escrito com exemplos de FiveM, mas o procedimento é idêntico.
Demora para entrar não é lag
Se quem já está dentro joga bem e a reclamação é só de demora na tela de download, o problema não é a máquina nem os scripts. É a entrega dos arquivos da sua cidade, que acontece antes do jogador conectar.
Quem resolve é o cache externo, que é otimizado para FiveM e RedM e tira esse download do seu servidor.
Subir de plano para resolver demora de entrada é dinheiro jogado fora.
A distância até o jogador
Se a reclamação é delay entre ação e resposta, e não travada geral, a causa é ping, e isso não se resolve com hardware. O limite é físico.
Servidor fora do Brasil devolve latência muito maior para o público brasileiro. Os números estão em por que hospedar no Brasil faz diferença.
Um detalhe que engana: se apenas um jogador reclama, provavelmente é a internet dele. Se todos reclamam, é do seu lado. Numa comunidade pequena isso é fácil de confirmar, porque você fala com todo mundo.
Como descobrir qual é o seu caso
| O que acontece | Causa provável |
|---|---|
| Delay em tudo, para todos, o dia inteiro | Ping, servidor longe do público |
| Só um jogador reclama | A conexão dele |
| Trava geral no pico, processador no limite | Clock do processador |
| Trava geral no pico, memória no limite | Memória |
| Piora ao longo do dia, melhora ao reiniciar | Memória ou script vazando |
| Trava só depois que instalou um addon | Aquele resource |
| Um resource crasha, o resto segue | Erro de código |
| Demora para entrar, mas joga bem depois | Cache externo |
| Cai do nada, com a máquina saudável | Pode ser ataque, veja o guia de DDoS |
Meça com a cidade cheia. Muito resource só mostra o custo real quando tem gente interagindo.
O que não resolve
Subir de plano sem saber a causa. Se o gargalo é clock, mais memória não muda nada.
Trocar de hospedagem no impulso. Se o problema estava na sua base, ele vai junto. Antes de decidir, veja os sinais de que é hora de trocar.
Reiniciar de hora em hora. Mascara vazamento de memória e incomoda quem está jogando.
O resumo
- Descubra qual dos quatro lags é o seu, pela tabela acima
- Olhe o processador da hospedagem. Xeon de clock baixo é gargalo
- Rode o resmon e o neteventlog num horário cheio
- Limpe o que não usa antes de pensar em plano maior
- Se for demora de entrada, ative o cache externo
Nos planos de RedM da WyzeHost usamos AMD Ryzen 9 de 4 GHz para cima, com servidores em São Paulo, proteção DDoS inclusa e upgrade sem perder arquivos a qualquer momento.
