Servidor FiveM 128 slots : como configurar para suportar muitos jogadores

Rodar um servidor FiveM 128 slots exige muito mais do que aumentar o número no sv_maxclients: é preciso entender como o OneSync distribui entidades entre os jogadores, quanto processamento cada conexão simultânea consome e quais parâmetros do server.cfg realmente evitam travamentos quando a população online cresce. Este guia cobre os três pilares dessa configuração.

OneSync e o impacto real em um servidor FiveM 128 slots

O OneSync é o componente que permite ultrapassar o limite histórico de 32 jogadores no FiveM. Sem ele, cada cliente só enxerga entidades (peds, veículos, objetos) dentro de um raio limitado e sincronizado de forma peer-to-peer, o que simplesmente não escala para um servidor FiveM 128 slots. Com OneSync habilitado, a sincronização passa a ser centralizada no processo do servidor, que decide quais entidades cada jogador precisa receber.

Existem três modos, mas na prática só um interessa para grandes populações:

• onesync (legacy): suporta até cerca de 64 slots, já obsoleto para configurações maiores.
• onesync on / Infinity: suporta até 1024 slots teoricamente, é o modo obrigatório para qualquer configuração acima de 64 jogadores.
• onesync_population: controla se o jogo gera NPCs e tráfego automaticamente; em servidores grandes costuma ser desativado para liberar processamento aos scripts de gameplay.

Antes de mexer no server.cfg, vale ler a documentação oficial sobre o funcionamento do OneSync: documentação oficial do OneSync. Para quem está estruturando a infraestrutura antes de escalar a população, a página de hospedagem FiveM detalha os recursos de CPU e painel disponíveis para esse tipo de configuração.

Por que o modo errado quebra 128 slots

Se o OneSync estiver em modo legacy ou desativado e o sv_maxclients for configurado para 128, o servidor aceita as conexões mas a sincronização de entidades colapsa: jogadores veem veículos teleportando, peds duplicados e desconexões por timeout. O sintoma mais comum relatado por administradores é o "entity lockdown", quando o motor para de criar novas entidades porque o limite de sincronização por jogador foi atingido.

Ajustando o server.cfg para um FiveM 128 slots estável

O arquivo server.cfg é onde a maior parte dos ajustes acontece. Abaixo está uma base funcional para uma configuração de alta população, com comentários sobre cada diretiva relevante.

# Ativa o OneSync em modo Infinity, obrigatório acima de 64 slots
set onesync on

# Define o número máximo de conexões simultâneas
sv_maxclients 128

# Desativa a geração automática de população (NPCs/tráfego) para
# liberar processamento aos scripts de gameplay
set onesync_population false

# Força a versão do jogo esperada pelos clientes
sv_enforceGameBuild 2944

# Aumenta a janela de timeout para evitar quedas falsas sob carga alta
sv_endpointprivacy true
set sv_requestParanoia 1

# Limite de entidades de rede por jogador (ajustar com cautela)
set sv_filterRequestControl 120

# Habilita logs de desempenho para diagnóstico contínuo
set resmon_show true

Parâmetros de rede e timeout

Com 128 slots, o volume de pacotes trocados entre o servidor e os clientes cresce proporcionalmente. Dois parâmetros merecem atenção redobrada:

# Tempo limite antes de considerar um cliente desconectado (ms)
set sv_timeoutDrop 180000

# Intervalo de keep-alive para conexões sob carga
set sv_authMaxVariance 1

Valores muito baixos de timeout derrubam jogadores com conexão instável durante picos de uso de banda; valores muito altos mascaram problemas reais de sincronização. O ideal é testar incrementalmente, subindo a população em lotes de 16 ou 32 jogadores reais antes de liberar os 128 slots ao público.

Resources e streaming de entidades

Cada resource carregado no server.cfg consome memória e tempo de inicialização. Em servidores de alta população, organize os resources por prioridade:

Categoria	Exemplo	Observação
Core/framework	es_extended, qb-core	Carregar primeiro, sem dependências pendentes
Sincronização de veículos/objetos	vehiclesync customizado	Sensível ao OneSync, testar isoladamente
Interface e HUD	scripts client-side	Baixo impacto no servidor, alto impacto no cliente
Eventos/economia	scripts de gameplay	Revisar loops e threads sem wait()

Scripts com loops sem Wait() ou com polling excessivo são a causa mais comum de degradação em populações altas, mais ainda que o próprio limite de slots.

Uso de recursos e otimização de performance com 128 jogadores

Quanto mais jogadores conectados, mais threads de sincronização, mais eventos de rede e mais chamadas de scripts por segundo o processo do servidor precisa processar. Um FiveM 128 slots bem configurado depende de três fatores de infraestrutura:

• CPU de frequência alta e núcleos dedicados: o motor do FiveM é fortemente dependente de single-thread performance para a lógica principal do jogo; processadores Ryzen com clock elevado reduzem o tempo de resposta por tick.
• Armazenamento NVMe: o carregamento de resources, streaming de assets e gravação de logs se beneficiam diretamente de baixa latência de disco, especialmente durante o boot do servidor com muitos scripts.
• Proteção contra ataques volumétricos: servidores populares de FiveM são alvos recorrentes de DDoS; ter uma camada de mitigação ativa na infraestrutura evita quedas coletivas durante picos de jogadores.

Use o comando resmon dentro do console ou via resource dedicado para identificar quais scripts consomem mais tempo de CPU por frame. Qualquer resource acima de 0.10-0.15ms constante merece revisão de código antes de escalar para 128 slots.

# No console do servidor, dentro do jogo
resmon

# Alternativa via painel: ativar o resource de monitoramento
ensure resmon

Monitorando via txAdmin

O txAdmin, incluído na build recente do FiveM, expõe métricas de CPU, memória e threads por resource em tempo real. Combine essa visão com os logs do painel de gestão para correlacionar picos de uso com eventos específicos (restart de resource, join em massa, scripts de economia rodando em intervalo curto).

Para quem gerencia a infraestrutura através de um VPS Pterodactyl, o acesso ao console live e aos logs de performance facilita identificar gargalos sem precisar de acesso SSH direto à máquina.

Administração, segurança e manutenção de um servidor FiveM 128 slots

População alta significa também superfície de ataque maior e mais pontos de falha administrativa. Algumas práticas reduzem o risco de incidentes:

• Defina um RCON forte e nunca reutilize a senha padrão gerada na instalação.
• Ative whitelist temporária durante testes de carga antes de abrir os 128 slots ao público.
• Mantenha o sv_enforceGameBuild atualizado conforme os patches do cfx.re para evitar incompatibilidade de clientes.
• Configure sauvegardes automáticas do banco de dados e dos arquivos de resources antes de qualquer atualização de script em produção.
• Revise logs de conexão regularmente para identificar tentativas de exploit via resources desatualizados.

Checklist antes de liberar os 128 slots

1. onesync on confirmado no console (status: Infinity)
2. sv_maxclients 128 aplicado e servidor reiniciado
3. resmon sem resources acima do limite aceitável
4. teste de carga com 50% da população real
5. backup do banco de dados e do server.cfg realizado
6. RCON e whitelist revisados

Esse processo evita que o lançamento de uma configuração de alta população vire motivo de instabilidade logo na primeira sessão com jogadores reais. Para outros jogos com necessidades parecidas de sincronização e população, vale consultar todos os nossos servidores de jogos disponíveis.

Conclusão

Configurar OneSync corretamente, ajustar o server.cfg com parâmetros testados e monitorar o consumo de cada resource são os três passos que decidem se um FiveM 128 slots funciona de forma estável ou colapsa sob carga real. Teste de forma incremental antes de abrir a população máxima.

FAQ

Qual a diferença entre onesync e onesync on no server.cfg?

O modo legacy (onesync) suporta até cerca de 64 slots e usa sincronização mais simples. O modo onesync on, também chamado Infinity, é necessário para qualquer configuração acima disso, incluindo 128 slots, pois distribui a carga de entidades de forma mais eficiente entre os jogadores conectados.

Por que o servidor trava mesmo com onesync on ativado em 128 slots?

Na maioria dos casos o problema não é o OneSync em si, mas resources com loops sem Wait() ou polling excessivo. Use o comando resmon para identificar os scripts que mais consomem tempo de CPU por frame e otimize ou substitua esses resources antes de aumentar a população.

É necessário desativar onesync_population para suportar 128 jogadores?

Não é obrigatório, mas é recomendado. Desativar a geração automática de NPCs e tráfego libera processamento para os scripts de gameplay, reduzindo a chance de picos de uso de CPU quando a população real atinge os 128 slots.