Cada vCPU corresponde a uma thread física reservada para você. Memória e disco não são partilhados. É o comportamento de um servidor dedicado, por uma fração do valor.
Ativação automática. Sem taxa de instalação. Garantia de 7 dias.
A prática comum do mercado é vender duas ou mais vCPU para cada thread real do processador. Funciona na média e é o que sustenta o preço de um VPS comum. O problema aparece no pico: quando várias máquinas do mesmo host pedem CPU ao mesmo tempo, a sua entra em fila.
No Servidor Dedicado Virtual essa proporção é de um para um. O nó não é sobrevendido: a soma das vCPU vendidas nunca passa do número de threads físicas do processador. O seu tick não depende do que o vizinho resolveu rodar às nove da noite.
É a diferença entre ter CPU disponível e ter CPU garantida.
Se algum destes cenários é o seu, a alocação 1:1 muda o resultado.
Acima de 200 jogadores o thread principal do servidor passa a trabalhar perto do limite em quase todo horário de pico. Nessa faixa, a diferença entre um núcleo garantido e um núcleo disputado aparece direto no tick rate e nos relatos de travamento dos jogadores.
Quem roda várias instâncias de SA-MP, MTA ou FiveM na mesma máquina precisa de núcleos previsíveis, porque cada instância ocupa o seu. Com CPU compartilhada, o gargalo se move de instância para instância sem padrão e o diagnóstico vira tentativa e erro.
Se o seu gráfico de uso vive acima de 70% e você já descartou problema de código, o próximo passo não é mais vCPU compartilhada. É vCPU que não compete.
PostgreSQL, MySQL, Redis e filas de processamento sofrem mais com variação do que com média. Threads reservadas e NVMe exclusivo mantêm o tempo de resposta estável nos percentis altos, que é onde o usuário final percebe.
O salto entre um VPS de topo e um servidor dedicado é de mais de duas vezes e meia. O Servidor Dedicado Virtual existe para o operador que já passou do primeiro e ainda não precisa do segundo.
Todo provedor que vende VPS decide uma proporção entre vCPU vendidas e threads físicas disponíveis. Quando essa proporção passa de um para um, existe a possibilidade de duas máquinas quererem a mesma thread no mesmo instante. Uma roda, a outra espera.
Esse tempo de espera tem nome e aparece no seu sistema. É o steal time, exibido como %st no top e como a coluna st no vmstat 1. Ele mede quanto tempo a sua vCPU quis processar e não pôde, porque o hipervisor entregou a thread para outra máquina virtual.
O detalhe que engana é que a média fica boa. Em uso normal a disputa é rara e o steal time fica perto de zero, então o gráfico do painel parece saudável o mês inteiro. O sofrimento acontece no pico, que é exatamente quando o seu servidor está cheio e a sua comunidade está online. É por isso que tanta gente descreve o problema como travadinha ocasional em vez de lentidão constante.
Rode vmstat 1 no seu servidor atual em horário de pico e observe a coluna st. Se ela sobe de forma consistente, você não tem um problema de tamanho de plano. Tem um problema de concorrência por CPU, e aumentar RAM não resolve.
Com alocação 1:1 não existe outra máquina competindo pelas suas threads, então o steal time se mantém em zero mesmo com a máquina sob carga.
O nó não recebe mais vCPU do que tem thread física, então as suas nunca entram em fila atrás de outro cliente. Rode o vmstat no seu servidor atual em horário de pico e compare a coluna st com a daqui.
Snapshot diário em storage separado, com retenção de 7 dias. Restauração pelo painel ou por chamado. Não cobramos à parte por isso.
O servidor já está no rack. Você contrata, recebe os acessos em minutos e sobe a sua stack no mesmo dia. Uma máquina dedicada nova leva até 48 horas para entrar em produção.
Quando a memória ficar apertada, a migração para um servidor dedicado completo não tem taxa. Nós movemos os dados e você paga apenas a diferença.
Ativação automática, sem taxa de instalação, com 7 dias de garantia.