VPS ou dedicado para FiveM: onde está o limite

O limite prático de uma VPS#

A pergunta que todo dono de cidade faz cedo ou tarde é quantos jogadores uma VPS aguenta. A resposta honesta é que essa não é a pergunta certa, porque o limite de uma VPS para FiveM raramente aparece na memória. Ele aparece na thread principal do FXServer.

O FiveM concentra a execução dos resources em um fluxo principal. Cada tick do servidor precisa percorrer a lógica de todos os scripts ativos antes de fechar. Quando essa volta demora mais do que o intervalo previsto, o servidor começa a atrasar e a cidade inteira sente. É esse o teto de uma VPS, e ele chega antes do teto de memória na maioria dos projetos de roleplay.

A boa notícia é que esse teto costuma estar bem alto. A linha VPS Ryzen usa processadores de desktop com clock alto justamente porque esse é o tipo de carga que mais se beneficia de frequência. Uma configuração de 16 GB com 6 vCPU por R$ 214,00 por mês, ou de 32 GB com 10 vCPU por R$ 414,00, cobre cidades que a maioria dos projetos nunca chega a ter.

Existe uma consequência prática importante nisso. Aumentar a memória não resolve um problema de tick. Se a cidade engasga porque a volta dos resources está demorando, dobrar a RAM só faz o servidor engasgar com mais folga de memória livre. O upgrade que ajuda nesse caso é o que entrega mais desempenho por núcleo, ou então a redução do trabalho que cada tick precisa fazer. Confundir esses dois eixos é o erro mais caro na evolução de uma cidade de roleplay.

Sinais de que passou do ponto#

Três sintomas, quando aparecem juntos e persistem depois da otimização, indicam que o problema virou estrutural.

• Tick caindo no horário de pico: a cidade roda bem à tarde e engasga às nove da noite. Se o comportamento acompanha o número de jogadores online e não um resource específico, a máquina está no limite de processamento e não com bug de script.
• Banco competindo com o FXServer: quando o MariaDB começa a aparecer no topo do consumo de CPU ao lado do servidor de jogo, os dois estão brigando pelos mesmos núcleos. Cada consulta lenta vira atraso no tick, e cada atraso no tick vira reclamação no Discord.
• Mais de um servidor na mesma máquina: cidade principal, servidor de testes e talvez um projeto secundário disputando a mesma VPS. Isso funciona enquanto os três estão vazios. No momento em que dois enchem ao mesmo tempo, nenhum entrega desempenho aceitável.

Há um quarto sintoma que costuma passar batido: o tempo de entrada na cidade. Quando um jogador leva vários minutos para carregar e a fila de conexão trava com duas ou três pessoas entrando juntas, o gargalo geralmente está no disco e na entrega dos assets, não no processamento. Esse sintoma isolado não justifica um dedicado, mas somado aos outros três compõe um quadro difícil de resolver só com otimização de código.

O que o dedicado entrega#

Um servidor dedicado não é simplesmente uma VPS maior. Ele muda três coisas de natureza, e vale entender cada uma antes de assinar.

• Núcleos físicos dedicados: em uma VPS, vCPU é uma fatia de tempo de processamento. No dedicado, os núcleos são seus o tempo inteiro. Para uma carga que depende de terminar cada tick no prazo, essa previsibilidade vale mais do que o número bruto de núcleos.
• NVMe inteiro: o disco não é compartilhado, então o tempo de resposta do banco de dados e do streaming de assets deixa de depender do que outros clientes estão fazendo. Em cidade com biblioteca grande de MLOs, isso aparece na entrada dos jogadores.
• Nenhum vizinho barulhento: a máquina física é sua, ponto. A variação de desempenho passa a depender exclusivamente do que a sua equipe roda nela, o que também significa que você perde o direito de culpar a hospedagem quando algo sai errado.

Além disso vem a memória. O Budget SM entrega 64 GB e o Extreme LG chega a 192 GB DDR5, volumes que permitem manter várias instâncias, banco, painel e ambiente de testes na mesma máquina sem apertar nada. Os modelos estão na página de servidores dedicados.

A conta do salto#

A tabela abaixo coloca lado a lado as opções reais e os valores mensais, para você medir a distância entre onde está e onde pensa em chegar.

O salto da VPS de 32 GB para o dedicado mais econômico é de aproximadamente três vezes e meia o valor mensal. A pergunta prática é o que você ganha com esse dinheiro. Se a resposta é apenas mais desempenho para a mesma cidade, provavelmente ainda não é hora. Se a resposta é duas ou três cidades rodando de verdade, um ambiente de testes permanente, o banco isolado e a certeza de que o hardware não é dividido com ninguém, a conta começa a fechar.

Uma forma honesta de fazer essa avaliação é somar o que você já paga hoje. Muitos projetos descobrem que mantêm uma VPS grande para a cidade, outra menor para testes, uma terceira para o site e o painel e ainda um plano de bot. Quando essa soma se aproxima de mil reais, a distância para o dedicado deixa de ser um abismo e vira uma decisão sobre consolidar tudo em uma máquina só, com a vantagem de ter um único ambiente para administrar em vez de quatro.

O raciocínio econômico mais amplo, aplicável a qualquer carga e não só a FiveM, está em servidor dedicado contra VPS.

O que tentar antes de migrar#

Quase toda cidade que acha que precisa de dedicado consegue ganhar meses de sobrevida com quatro ações que custam tempo em vez de dinheiro.

• Rodar o profiler e listar os resources mais caros por tick
• Remover scripts duplicados e funcionalidades que ninguém usa
• Revisar consultas ao banco feitas dentro de laços de repetição
• Reduzir a biblioteca de assets que nunca aparece na cidade
• Separar o servidor de testes para outra máquina pequena
• Subir um degrau de VPS e medir de novo com a cidade cheia

O passo de separar o servidor de testes é o mais subestimado. Uma VPS pequena de R$ 64,00 por mês, com 4 GB e 2 vCPU, tira toda a atividade de desenvolvimento de cima da máquina de produção por uma fração do custo de um dedicado. O guia de dimensionamento de FiveM em VPS Ryzen detalha como medir cada gargalo.

Plano de migração#

Decidido o salto, a migração de uma cidade de roleplay é delicada porque o banco de dados carrega anos de personagem, propriedade e economia. Uma ordem segura evita perder progresso dos jogadores.

• Fazer dump completo do banco e guardar duas cópias
• Montar a nova máquina com a mesma versão de artefatos e de banco
• Restaurar o banco e subir a cidade em porta fechada ao público
• Testar com a equipe: criar personagem, comprar, guardar e sair
• Agendar a janela de migração e avisar a comunidade com antecedência
• Congelar a cidade antiga, refazer o dump final e restaurar
• Apontar o endereço para a nova máquina e acompanhar o primeiro pico
• Manter a máquina antiga desligada mas intacta por alguns dias

O dump final feito com a cidade congelada é o que garante que nenhum jogador perca o que fez nas últimas horas. Já a máquina antiga preservada por alguns dias é o seu plano de retorno caso algo apareça só no segundo dia de operação. Escolha também uma janela de baixo movimento, normalmente uma madrugada de meio de semana, e comunique a comunidade com pelo menos alguns dias de antecedência. Migração anunciada é vista como cuidado, migração surpresa é vista como queda.

Depois da virada, resista à tentação de reinstalar tudo do zero na máquina nova achando que é a oportunidade perfeita para modernizar a base. Migre primeiro, estabilize, e só então volte a mexer nos resources. Trocar de hardware e de código ao mesmo tempo torna impossível saber a qual das duas mudanças atribuir qualquer problema que apareça. Os critérios gerais que justificam hardware exclusivo, úteis para apresentar a decisão à sua equipe, estão em quando usar um servidor dedicado. E se a conclusão for que a cidade ainda cabe em um plano pronto, os cinco degraus estão na página de hospedagem FiveM.