Cada vCPU corresponde a un thread físico reservado para vos. Memoria y disco no se comparten. Es el comportamiento de un servidor dedicado, por una fracción del valor.
Activación automática. Sin tasa de instalación. Garantía de 7 días.
La práctica común del mercado es vender dos o más vCPU por cada thread real del procesador. Funciona en promedio y es lo que sostiene el precio de un VPS común. El problema aparece en el pico: cuando varias máquinas del mismo host piden CPU al mismo tiempo, la tuya entra en fila.
En el Servidor Dedicado Virtual esa proporción es de uno a uno. El nodo no está sobrevendido: la suma de las vCPU vendidas nunca pasa del número de threads físicos del procesador. Tu tick no depende de lo que el vecino decidió correr a las nueve de la noche.
Es la diferencia entre tener CPU disponible y tener CPU garantizada.
Si alguno de estos escenarios es el tuyo, la asignación 1:1 cambia el resultado.
Arriba de 200 jugadores el thread principal del servidor pasa a trabajar cerca del límite en casi todo horario pico. En esa franja, la diferencia entre un núcleo garantizado y un núcleo disputado aparece directo en el tick rate y en los reportes de lag de los jugadores.
Quien corre varias instancias de SA-MP, MTA o FiveM en la misma máquina necesita núcleos previsibles, porque cada instancia ocupa el suyo. Con CPU compartida, el cuello de botella se mueve de instancia en instancia sin patrón y el diagnóstico se vuelve prueba y error.
Si tu gráfico de uso vive arriba del 70% y ya descartaste problema de código, el próximo paso no es más vCPU compartida. Es vCPU que no compite.
PostgreSQL, MySQL, Redis y colas de procesamiento sufren más con la variación que con el promedio. Threads reservados y NVMe exclusivo mantienen el tiempo de respuesta estable en los percentiles altos, que es donde el usuario final lo percibe.
El salto entre un VPS de tope de gama y un servidor dedicado es de más de dos veces y media. El Servidor Dedicado Virtual existe para el operador que ya pasó del primero y todavía no necesita el segundo.
Todo proveedor que vende VPS decide una proporción entre vCPU vendidas y threads físicos disponibles. Cuando esa proporción pasa de uno a uno, existe la posibilidad de que dos máquinas quieran el mismo thread en el mismo instante. Una corre, la otra espera.
Ese tiempo de espera tiene nombre y aparece en tu sistema. Es el steal time, mostrado como %st en top y como la columna st en vmstat 1. Mide cuánto tiempo tu vCPU quiso procesar y no pudo, porque el hipervisor le entregó el thread a otra máquina virtual.
El detalle que engaña es que el promedio queda bien. En uso normal la disputa es rara y el steal time queda cerca de cero, así que el gráfico del panel parece sano todo el mes. El sufrimiento pasa en el pico, que es exactamente cuando tu servidor está lleno y tu comunidad está online. Por eso tanta gente describe el problema como un lag ocasional en vez de lentitud constante.
Corré vmstat 1 en tu servidor actual en horario pico y observá la columna st. Si sube de forma consistente, no tenés un problema de tamaño de plan. Tenés un problema de competencia por CPU, y aumentar RAM no lo resuelve.
Con asignación 1:1 no existe otra máquina compitiendo por tus threads, así que el steal time se mantiene en cero incluso con la máquina bajo carga.
El nodo no recibe más vCPU de las que tiene en threads físicos, así que las tuyas nunca entran en fila detrás de otro cliente. Corré vmstat en tu servidor actual en horario pico y compará la columna st con la de acá.
Snapshot diario en storage separado, con retención de 7 días. Restauración por el panel o por ticket. No lo cobramos aparte.
El servidor ya está en el rack. Contratás, recibís los accesos en minutos y subís tu stack el mismo día. Una máquina dedicada nueva tarda hasta 48 horas en entrar en producción.
Cuando la memoria quede ajustada, la migración a un servidor dedicado completo no tiene tasa. Nosotros movemos los datos y vos pagás solo la diferencia.
Activación automática, sin tasa de instalación, con 7 días de garantía.