NVMe frente a SSD SATA en un VPS: ¿importa?

¿Importa NVMe en un VPS?

NVMe importa en un VPS cuando el software realiza muchas lecturas y escrituras pequeñas y espera a que termine cada una. Cambia muy poco en un sitio que sirve páginas almacenadas en caché o en un programa que pasa la mayor parte del tiempo esperando a la red. El medio de almacenamiento es un factor. El hipervisor que se encuentra delante del disco y los demás huéspedes que comparten el mismo host determinan el límite que realmente obtiene.

Qué cambia NVMe y qué no cambia

NVMe (non-volatile memory express) no es un tipo de memoria flash. Es el protocolo y la conexión que se usan para acceder a la memoria flash. Un dispositivo NVMe usa líneas PCIe (peripheral component interconnect express) y se comunica mediante NVMe. Una SSD SATA (serial ATA) usa un enlace SATA y se comunica mediante AHCI (advanced host controller interface). Los chips de memoria que almacenan los bytes pueden ser idénticos en ambos casos.

Hay dos diferencias, y ambas se relacionan con la ruta de comandos, no con el almacenamiento en sí.

Colas. AHCI proporciona al kernel una cola de comandos con capacidad para 32 comandos. NVMe permite miles de colas, en la práctica una por núcleo de CPU, y cada una tiene mucha más profundidad que 32. Un proceso que lee un bloque cada vez no puede apreciar esa diferencia. Una base de datos con 64 lecturas pendientes sí puede apreciarla: en SATA, la solicitud número 33 espera un espacio en la cola antes de que el dispositivo siquiera la reciba, mientras que el dispositivo NVMe acepta todas y las procesa simultáneamente.

Ancho del enlace. Un enlace SATA III funciona a 6 Gbit/s, lo que equivale aproximadamente a 550 MB/s de datos reales después de la sobrecarga del protocolo. Este es un límite fijo, independientemente de la memoria flash que haya detrás. Cuatro líneas PCIe transportan varios gigabytes por segundo, por lo que el enlace deja de ser el límite.

La latencia es donde normalmente las expectativas son incorrectas. Con una profundidad de cola de 1, es decir, una sola solicitud en curso, una SSD SATA responde a una lectura de 4k en aproximadamente 100 a 150 microsegundos. NVMe responde en aproximadamente 80 a 100. Ambas son rápidas, y ningún proceso que ejecutes notará la diferencia con una sola solicitud. La diferencia aparece con la concurrencia. La profundidad de cola, es decir, el número de solicitudes en curso al mismo tiempo, es el ajuste que determina si ambos medios funcionan de forma parecida o muy diferente.

El almacenamiento de bloques en red es una tercera clase, con una física diferente. Una escritura atraviesa una red hasta un clúster de almacenamiento y solo recibe confirmación cuando el clúster la ha almacenado, por lo que su latencia se mide en milisegundos en lugar de microsegundos. Lo que se obtiene a cambio de esa latencia es durabilidad: el volumen sobrevive al host al que está conectado y se puede crear una instantánea y cambiar su tamaño.

Cifras publicadas habituales: NVMe, SSD SATA y almacenamiento de red

[
  {
    "disk": "Local NVMe SSD",
    "iops_4k_read": "184,000",
    "p99_latency_ms": 0.4,
    "seq_read_mbps": "3,400"
  },
  {
    "disk": "Local SATA SSD",
    "iops_4k_read": "90,000",
    "p99_latency_ms": 1.2,
    "seq_read_mbps": "550"
  },
  {
    "disk": "Network block storage",
    "iops_4k_read": "12,500",
    "p99_latency_ms": 6.5,
    "seq_read_mbps": "250"
  }
]

Un dispositivo NVMe local suele anunciar 184,000 IOPS de lectura aleatoria de 4k (operaciones de entrada/salida por segundo) con una profundidad de cola de 32. La misma prueba en un SSD SATA suele situarse cerca de 90,000, limitada por la única cola de AHCI y por el enlace de 6 Gbit/s. El almacenamiento de bloques de red suele estar limitado por el proveedor y no por el hardware, y 12,500 es un límite superior documentado habitual.

La latencia expresa lo mismo en la unidad que perciben los usuarios. La latencia de lectura p99, es decir, la del 1 por ciento más lento de las solicitudes, es de aproximadamente 0.4 ms en NVMe local y 1.2 ms en SATA. Si la ruta incluye una red, aumenta a 6.5 ms, más de diez veces la cifra de NVMe.

Las lecturas secuenciales muestran la mayor diferencia, pero son las menos útiles: 3,400 MB/s frente a 550 MB/s. Casi ningún servidor lee un archivo grande completo a máxima velocidad. Las columnas de operaciones aleatorias y de latencia describen lo que realmente hacen una base de datos, una cola de correo o un gestor de paquetes.

Qué cargas de trabajo notan el disco

Una regla explica todos estos casos: una carga de trabajo solo nota el disco cuando espera al disco. Linux conserva en la RAM los datos de archivos usados recientemente, en la caché de páginas, por lo que la segunda lectura de un archivo nunca llega al almacenamiento. Si el conjunto de trabajo, es decir, los datos que se usan realmente, cabe en la RAM, las lecturas se convierten en lecturas de memoria después de la primera pasada. Las escrituras son diferentes. Cualquier escritura que la aplicación vacíe con fsync() debe estar en almacenamiento estable antes de que la aplicación pueda continuar.

Trabajo que confirma transacciones. PostgreSQL, MySQL y SQLite llaman a fsync() o fdatasync() al confirmar una transacción, y cada confirmación espera la respuesta del dispositivo. Por tanto, la tasa de confirmaciones de una conexión está determinada por la latencia de escritura, no por el ancho de banda. Un dispositivo que vacía la caché en 0.2 ms permite muchas más confirmaciones por segundo que uno que tarda 5 ms, y ningún nivel de rendimiento cambia ese hecho. MySQL lo indica en el registro de errores cuando el vaciado no puede mantener el ritmo:

[Note] InnoDB: page_cleaner: 1000ms intended loop took 4589ms. The settings might not be optimal.

PostgreSQL lo informa en sus líneas de checkpoint, donde un valor grande de sync= significa que el vaciado fue lento:

LOG:  checkpoint complete: wrote 8192 buffers (25.0%); write=27.694 s, sync=11.207 s, total=39.001 s

Trabajo que accede a muchos archivos pequeños. Cada archivo requiere operaciones de metadatos que una lectura secuencial grande no necesita. npm install, git clone de un repositorio grande, la extracción de imágenes de contenedor, un almacén de correo Maildir y una copia de seguridad que recorre un árbol grande pasan la mayor parte del tiempo en accesos aleatorios pequeños. Un trabajo de copia de seguridad de restic en un VPS lee y calcula el hash de cada archivo que no ha visto antes, por lo que el tiempo transcurrido de una copia de seguridad de un millón de archivos depende estrechamente de la latencia de lectura aleatoria. Lo mismo ocurre con du -sh, que solo lee metadatos.

Las bases de datos que superan la capacidad de la RAM también pertenecen a esta categoría. Cuando el índice ya no cabe en la caché de páginas, cada búsqueda se convierte en una lectura aleatoria y el disco vuelve a estar en la ruta crítica.

¿Qué cargas de trabajo no notan el disco?

Un blog o un sitio pequeño de una empresa. Las páginas son pequeñas, la caché de páginas las conserva todas después de la primera solicitud y el límite lo establecen la CPU al generarlas o el ancho de banda de los recursos. Un stack LAMP en Ubuntu 24.04 que sirve un sitio con poco tráfico casi no realiza operaciones de E/S de disco cuando ya está en caché.

Streaming multimedia. Un flujo 4K a 40 Mbit/s lee 5 MB/s. Diez flujos leen 50 MB/s, una velocidad que incluso el almacenamiento de bloques en red puede proporcionar sin problemas. Un servidor multimedia Jellyfin en un VPS está limitado por la cuota de salida de red y por la CPU cuando transcodifica, no por el medio de almacenamiento.

Inferencia local de modelos. Ejecutar Ollama en un VPS para alojar un LLM propio lee el archivo del modelo una vez y después trabaja en la RAM. NVMe reduce el tiempo de carga de un modelo de 20 GB de minutos a segundos. No cambia la cantidad de tokens por segundo, que está limitada por el ancho de banda de la memoria y la CPU.

Cualquier proceso que espere a un servicio externo. Un worker que dedica 800 ms por trabajo a una solicitud HTTP no será más rápido con un disco mejor.

Por qué el hipervisor importa tanto como el medio

Nunca se comunica directamente con el dispositivo. Se comunica con un disco virtual que presenta el hipervisor, normalmente mediante virtio, y varias decisiones de esa capa importan más que usar NVMe o SATA.

No puede ver el medio desde el sistema invitado. lsblk -d -o NAME,ROTA,SIZE,MODEL muestra vda con un modelo vacío, porque virtio no transmite la identidad de la unidad. cat /sys/block/vda/queue/rotational informa de lo que anuncia el hipervisor, por lo que un valor 0 no demuestra que el medio sea flash. nvme list, del paquete nvme-cli, no muestra nada en la mayoría de los VPS, aunque el host tenga muchas unidades NVMe, porque su disco es un dispositivo virtio y no un dispositivo NVMe. Un plan que indica NVMe normalmente describe el contenido del host. Su volumen todavía puede estar conectado mediante la red.

El modo de caché del host modifica más los valores que el medio. Con el almacenamiento en caché writeback habilitado en el host, una operación fsync() del sistema invitado puede finalizar en cuanto el host tiene los datos en su propia RAM. Esto produce un resultado de referencia que ningún dispositivo físico podría ofrecer. También significa que un fallo del host puede perder escrituras que la base de datos considera seguras. Con el modo de caché none, los valores son menores y reflejan mejor el rendimiento real.

Límites y créditos de ráfaga. Muchos proveedores limitan las IOPS por volumen o por plan, y muchos volúmenes de red utilizan una asignación de ráfaga. Una asignación de ráfaga es un conjunto de créditos: el volumen funciona rápido mientras quedan créditos y después baja a un nivel base mucho menor. El síntoma es fácil de reconocer. Una importación o una restauración se ejecuta rápidamente durante varios minutos, después se ralentiza de forma notable y permanece lenta, sin que haya cambiado nada en su configuración. Ha consumido los créditos.

Vecinos. En un host compartido, la latencia del disco cambia según lo que hagan los demás sistemas invitados. Por eso debe realizar mediciones más de una vez. Ejecute la misma prueba por la mañana y de nuevo por la tarde, y compare la variación. En un host con mucha carga, la diferencia entre dos ejecuciones en el mismo volumen suele ser mayor que la diferencia publicada entre dos medios.

Cómo medir el disco que realmente tiene su VPS

Instale fio, el benchmark estándar de E/S, y realice la medición. Antes, tenga en cuenta tres advertencias. La prueba crea un archivo, por lo que utiliza espacio de disco y cuenta para cualquier límite de IOPS incluido en su facturación. Mantenga las ejecuciones cortas. No la ejecute con una profundidad de cola máxima en un volumen que atiende tráfico activo, porque competirá con su propia aplicación.

sudo apt update && sudo apt install -y fio ioping sysstat
cd /var/tmp

Lectura aleatoria con una profundidad de cola de 32, que es la profundidad que indican los proveedores:

fio --name=randread --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
  --runtime=30 --time_based --group_reporting

La línea importante comienza con read:

  read: IOPS=184k, BW=719MiB/s (754MB/s)(21.1GiB/30001msec)

--direct=1 omite la caché de páginas del sistema invitado, por lo que el resultado describe el dispositivo y no la RAM. Si lo omite, medirá la memoria, que devuelve un valor que ningún disco puede alcanzar. Use --size=4G o un valor superior si tiene espacio, porque un archivo de 1G puede permanecer completamente en la caché del host y hacer que el resultado parezca mejor.

La profundidad de cola 1 muestra la latencia sin carga, que es la que experimenta un proceso de un solo subproceso:

fio --name=lat --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based

La prueba de confirmación predice el comportamiento de la base de datos. Escribe 4k y llama a fdatasync() después de cada escritura, por lo que la tasa informada incluye el vaciado:

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

La cifra de IOPS de esa ejecución se aproxima al número máximo de transacciones pequeñas por segundo que puede confirmar una conexión de base de datos, porque una confirmación espera el mismo vaciado.

Para obtener una muestra rápida sin fio:

ioping -c 20 .

--- . (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.13 ms, 76 KiB read, 4.60 k iops, 17.9 MiB/s
min/avg/max/mdev = 174.2 us / 217.6 us / 386.1 us / 51.3 us

El valor mdev, la desviación media, es tan importante como el promedio. Una desviación elevada en un equipo inactivo indica que el backend de almacenamiento es compartido y está ocupado.

Cómo leer el resultado

A fecha de julio de 2026, estas son lecturas razonables para una VPS pequeña. Decenas de miles de IOPS de lectura aleatoria de 4k con una profundidad de cola de 32, y una latencia con profundidad de cola 1 inferior a aproximadamente 0.3 ms, son compatibles con flash local. Una latencia de varios milisegundos con profundidad de cola 1 indica una ruta de red, independientemente del nombre del plan. Las lecturas secuenciales que se detienen cerca de 550 MB/s son características de un enlace SATA. Un valor muy superior a lo que puede ofrecer un dispositivo individual indica que hay almacenamiento en caché en la ruta, casi siempre en el host.

Para ver cómo la carga de trabajo activa afecta al disco:

iostat -x 1 3
vmstat 1 5
cat /proc/pressure/io

En la salida de iostat -x, consulta r_await y w_await, los milisegundos medios que una solicitud esperó, y aqu-sz, la longitud media de la cola. Ignora %util en un disco virtual. Este valor informa del porcentaje de tiempo durante el que hubo al menos una solicitud pendiente, pero no indica la saturación de un dispositivo que atiende muchas solicitudes simultáneamente. Por eso, %util de 100 junto con un r_await de 0.2 ms indica que el disco está ocupado de forma saludable. En vmstat, la columna wa muestra el porcentaje de tiempo de CPU empleado esperando operaciones de E/S. Si /proc/pressure/io existe en tu kernel, su valor some avg10= indica la proporción de los últimos 10 segundos durante la que al menos una tarea estuvo bloqueada esperando operaciones de E/S. Esta es la respuesta más directa a si el almacenamiento es tu cuello de botella.

Cómo se ve un VPS limitado por el disco

Una carga media alta con la CPU inactiva y un valor elevado de wa en vmstat indica que los procesos están en espera detrás del disco. La señal más clara del kernel es este mensaje en dmesg -T:

INFO: task jbd2/vda1-8:194 blocked for more than 120 seconds.

Esa línea aparece porque un hilo del kernel esperó más de dos minutos a que el almacenamiento respondiera. Por eso el watchdog de tareas bloqueadas la registró. jbd2 es el hilo del journal de ext4. Esto significa que todo el sistema de archivos estaba esperando, no que hubiera un programa con un comportamiento incorrecto. En un VPS, normalmente indica un problema en el backend de almacenamiento o que se agotó la cuota de IOPS.

Los síntomas de la aplicación siguen el mismo patrón. El tiempo de respuesta mediano se mantiene en niveles aceptables, mientras que las solicitudes más lentas forman una cola larga. Esto ocurre porque solo pagan el coste las solicitudes que acceden al disco. apt upgrade permanece en Unpacking durante minutos porque dpkg hace flush mientras escribe. git status tarda varios segundos en un repositorio grande. Estos son costes de metadatos y de flush, por lo que un mayor ancho de banda no ayudaría.

Qué hacer cuando el disco es el límite

Compra RAM antes que IOPS. Si el conjunto de trabajo cabe en la caché de páginas, las lecturas dejan de llegar al disco. Duplicar la memoria suele ofrecer más beneficios que cambiar a una clase de almacenamiento más rápida y normalmente cuesta menos.

Reduce el número de vaciados cuando los datos lo permitan. En PostgreSQL, synchronous_commit = off permite que un commit finalice antes de que la escritura llegue al disco. Si el servidor falla, puedes perder la última fracción de segundo de transacciones. La base de datos no se corrompe porque el write-ahead log se sigue escribiendo en orden. Esta opción es adecuada para una copia de análisis y no para pagos. innodb_flush_log_at_trx_commit = 2 en MySQL ofrece el mismo compromiso.

Agrupa los archivos pequeños. Una transferencia o copia de seguridad de un millón de archivos pequeños está limitada principalmente por el coste de cada archivo. Por eso, en almacenamiento con alta latencia, crear primero un archivo comprimido y mover un único flujo es más rápido que copiar el árbol archivo por archivo.

Mantén activo discard en los volúmenes thin. En el almacenamiento con aprovisionamiento thin, el backend no sabe que un bloque está libre hasta que el sistema de archivos se lo indica. Un volumen que nunca ejecuta trim pierde rendimiento de escritura de forma gradual. Ubuntu incluye un temporizador semanal para esto:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av muestra los bytes liberados por punto de montaje. Si aparece un mensaje que indica que la operación discard no es compatible, el disco virtual no transmite discard al host. No tienes nada que corregir.

Omite el ajuste del planificador de E/S. En un disco virtio, cat /sys/block/vda/queue/scheduler normalmente muestra none, y la planificación real se realiza en el host, al que no tienes acceso. Omite también noatime: Ubuntu monta con relatime de forma predeterminada, lo que ya evita casi todas las escrituras de atime.

Elegir un plan

Paga por NVMe cuando en el servidor haya una base de datos, un servidor de correo, un ejecutor de CI o una compilación con muchos paquetes. No pagues un precio superior por un sitio web en caché ni por una aplicación cuyo tiempo se consuma en llamadas externas. Si no estás seguro, probablemente el disco no sea tu limitación, porque la mayoría de las cargas de trabajo pequeñas en VPS se quedan primero sin RAM o ancho de banda.

Mide desde el primer día, mientras revisas los primeros diez minutos en un VPS nuevo, y guarda la salida en un archivo. Una línea base te permite demostrar después que el host se volvió más lento y que no fue tu código. Prefiere proveedores que indiquen por escrito la clase de almacenamiento y cualquier límite de IOPS. Si un plan indica NVMe y una lectura con profundidad de cola 1 tarda 4 ms, tienes almacenamiento de red en un host equipado con NVMe. Es algo legítimo para vender, pero es diferente de lo que estás comprando.

FAQ

¿NVMe siempre es más rápido que un SSD SATA en un VPS?

No. Con una profundidad de cola de 1, ambos tienen un rendimiento similar: aproximadamente de 80 a 150 microsegundos para una lectura de 4k. Un programa de un solo subproceso no puede distinguirlos. NVMe ofrece ventaja cuando hay muchas solicitudes en curso, porque AHCI proporciona una cola con una profundidad de 32 comandos, mientras que NVMe proporciona miles de colas más profundas. En un host compartido, la carga de otros guests puede cambiar la latencia más que el medio de almacenamiento. Por eso, mida su propio volumen con fio en lugar de basarse en el nombre del plan.

¿Cómo compruebo si mi VPS realmente usa NVMe?

No puede comprobarlo directamente, porque virtio oculta el dispositivo físico. lsblk muestra vda sin una cadena de modelo, nvme list no devuelve nada y /sys/block/vda/queue/rotational solo informa de lo que anuncia el hipervisor. Mida el comportamiento en su lugar. Una lectura aleatoria de 4k con una profundidad de cola de 1 y una latencia inferior a aproximadamente 0.3 ms indica flash local. Una latencia de varios milisegundos indica que hay un salto de red en la ruta. Las lecturas secuenciales que se detienen cerca de 550 MB/s indican un enlace SATA.

¿NVMe hace que mi sitio web cargue más rápido?

Normalmente, no. Después de la primera solicitud, Linux sirve los archivos desde la caché de páginas en la RAM, por lo que el disco queda inactivo. En un VPS pequeño, la velocidad de carga normalmente está limitada por el tiempo de CPU de la aplicación y por el ancho de banda. El disco vuelve a formar parte de la ruta crítica si el sitio escribe en cada solicitud. Por ejemplo, un carrito respaldado por una base de datos que confirma transacciones con frecuencia espera a que se complete un flush en cada confirmación.

¿Cuál es un buen resultado de fio para un VPS?

En julio de 2026, un VPS pequeño con flash local normalmente alcanza decenas de miles de IOPS de lectura aleatoria de 4k con una profundidad de cola de 32, y una latencia inferior a 0.3 ms con una profundidad de cola de 1. El almacenamiento de bloques en red normalmente alcanza unos pocos miles de IOPS, con una latencia de varios milisegundos. Ejecute la prueba tres veces en diferentes horarios. Una gran variación entre las ejecuciones proporciona más información que el promedio, porque muestra cuánto le afecta la carga de los otros guests del host.

¿Debo colocar mi base de datos en almacenamiento de bloques en red?

Puede hacerlo, y muchos servicios administrados lo hacen, pero la ruta de confirmación tiene ese coste. Cada flush atraviesa la red, por lo que una sola conexión confirma menos transacciones pequeñas por segundo que en flash local. A cambio, obtiene una durabilidad que sobrevive al host. Si elige almacenamiento en red para una base de datos con muchas escrituras, agrupe el trabajo en transacciones más grandes para que menos flushes incluyan más filas.