NVMe ou SSD SATA em VPS: faz diferença?

O NVMe é importante em um VPS?

O NVMe é importante em um VPS quando seu software faz muitas operações pequenas de leitura e gravação e aguarda a conclusão de cada uma. Ele muda muito pouco para um site que fornece páginas em cache ou para um programa que passa a maior parte do tempo aguardando a rede. O tipo de armazenamento é apenas um dos fatores. O hypervisor à frente do disco e os outros guests que compartilham o mesmo host definem o limite de desempenho que você realmente obtém.

O que o NVMe muda e o que não muda

NVMe (non-volatile memory express) não é um tipo de memória flash. É o protocolo e a conexão usados para acessar a memória flash. Um dispositivo NVMe usa lanes PCIe (peripheral component interconnect express) e se comunica por NVMe. Um SSD SATA (serial ATA) usa um link SATA e se comunica por AHCI (advanced host controller interface). Os chips de memória que armazenam seus bytes podem ser idênticos nos dois casos.

Duas coisas são diferentes, e ambas estão relacionadas ao caminho dos comandos, não ao armazenamento em si.

Filas. O AHCI fornece ao kernel uma fila de comandos que comporta 32 comandos. O NVMe permite milhares de filas, na prática uma por núcleo da CPU, e cada uma é muito mais profunda que 32. Um processo que lê um bloco por vez não percebe essa diferença. Um banco de dados com 64 leituras pendentes percebe: no SATA, a 33ª solicitação espera uma vaga na fila antes mesmo de o dispositivo recebê-la, enquanto o dispositivo NVMe aceita todas e trabalha nelas em conjunto.

Largura do link. Um link SATA III opera a 6 Gbit/s, o que corresponde a aproximadamente 550 MB/s de dados reais após a sobrecarga do protocolo. Esse é um limite fixo, independentemente da memória flash conectada a ele. Quatro lanes PCIe transportam vários gigabytes por segundo, portanto o link deixa de ser o limite.

A latência é onde as expectativas geralmente estão erradas. Em queue depth 1, ou seja, uma única solicitação em andamento, um SSD SATA responde a uma leitura de 4k em aproximadamente 100 a 150 microssegundos. O NVMe responde em aproximadamente 80 a 100. Ambos são rápidos, e nada que você execute perceberá a diferença em uma única solicitação. A diferença aparece com a concorrência. Queue depth, o número de solicitações em andamento ao mesmo tempo, é a configuração que determina se os dois meios de armazenamento parecerão iguais ou muito diferentes.

O armazenamento de blocos em rede é uma terceira classe, com características físicas diferentes. Uma gravação atravessa a rede até um cluster de armazenamento e só é confirmada quando o cluster a armazena, portanto sua latência é medida em milissegundos, e não em microssegundos. O que você obtém em troca dessa latência é durabilidade: o volume continua existindo mesmo que o host ao qual está anexado deixe de existir, e pode ser copiado usando snapshots e redimensionado.

Valores normalmente publicados: NVMe, SSD SATA e armazenamento de rede

[
  {
    "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"
  }
]

Um dispositivo NVMe local costuma ser anunciado com 184,000 IOPS de leitura aleatória em blocos de 4k (operações de entrada/saída por segundo), com profundidade de fila 32. O mesmo teste em um SSD SATA costuma ficar perto de 90,000, limitado pela fila única do AHCI e pelo link de 6 Gbit/s. O armazenamento de blocos em rede normalmente é limitado pelo provedor, não pelo hardware, e 12,500 é um limite documentado comum.

A latência mostra o mesmo resultado na unidade percebida pelos usuários. A latência p99 de leitura, que corresponde ao 1 por cento mais lento das solicitações, é de aproximadamente 0.4 ms em NVMe local e 1.2 ms em SATA. Quando a rede entra no caminho, o valor passa a 6.5 ms, mais de dez vezes o valor do NVMe.

As leituras sequenciais apresentam a maior diferença e são as menos úteis: 3,400 MB/s contra 550 MB/s. Quase nada em um servidor lê um arquivo grande inteiro, do início ao fim, na velocidade máxima. As colunas de operações aleatórias e de latência descrevem o comportamento real de um banco de dados, de uma fila de e-mail ou de um gerenciador de pacotes.

Quais cargas de trabalho percebem o disco

Uma regra explica todas elas: uma carga de trabalho só percebe o disco quando espera pelo disco. O Linux mantém os dados de arquivos usados recentemente na RAM, no cache de páginas, portanto a segunda leitura de um arquivo nunca chega ao armazenamento. Se o conjunto de trabalho, ou seja, os dados realmente em uso, couber na RAM, as leituras se tornarão leituras de memória depois da primeira passagem. As gravações são diferentes. Qualquer gravação que o aplicativo descarregue com fsync() deve estar no armazenamento persistente antes que o aplicativo possa continuar.

Trabalho que confirma transações. PostgreSQL, MySQL e SQLite chamam fsync() ou fdatasync() ao confirmar uma transação, e cada confirmação aguarda a resposta do dispositivo. Portanto, a taxa de confirmações de uma conexão é definida pela latência de gravação, não pela largura de banda. Um dispositivo que descarrega dados em 0.2 ms permite muito mais confirmações por segundo do que um que leva 5 ms, e nenhuma quantidade de throughput altera isso. O MySQL informa isso no log de erros quando o descarregamento não consegue acompanhar:

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

O PostgreSQL informa isso nas linhas de checkpoint, nas quais um valor alto de sync= significa que o próprio descarregamento foi lento:

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

Trabalho que acessa muitos arquivos pequenos. Cada arquivo envolve operações de metadados que uma única leitura sequencial grande não envolve. npm install, git clone de um repositório grande, a descompactação de imagens de contêineres, um armazenamento de e-mail Maildir e um backup que percorre uma árvore grande passam a maior parte do tempo em acessos aleatórios pequenos. Uma tarefa de backup do restic em uma VPS lê e calcula o hash de cada arquivo que ainda não foi visto, portanto o tempo total de um backup de um milhão de arquivos acompanha de perto a latência de leitura aleatória. O mesmo vale para du -sh, que lê apenas metadados.

Os bancos de dados que ultrapassam a capacidade da RAM também pertencem a esta categoria. Quando o índice deixa de caber no cache de páginas, cada consulta se torna uma leitura aleatória, e o disco volta a fazer parte do caminho crítico.

Quais cargas de trabalho não percebem o disco

Um blog ou site de uma pequena empresa. As páginas são pequenas, o cache de páginas mantém todas elas após a primeira solicitação, e o limite é a CPU para renderização ou a largura de banda para os recursos. Uma stack LAMP no Ubuntu 24.04 que atende um site com pouco tráfego quase não faz IO de disco depois de aquecida.

Streaming de mídia. Um stream 4K a 40 Mbit/s lê 5 MB/s. Dez streams leem 50 MB/s, uma taxa que até mesmo o armazenamento em blocos pela rede atende sem dificuldade. Um servidor de mídia Jellyfin em um VPS é limitado pela largura de banda de saída da sua rede e pela CPU durante a transcodificação, não pelo meio de armazenamento.

Inferência de modelos local. Executar o Ollama em um VPS para hospedar um LLM por conta própria lê o arquivo do modelo uma vez e depois trabalha na RAM. O NVMe reduz o tempo de carregamento de um modelo de 20 GB de minutos para segundos. Ele não altera a quantidade de tokens por segundo, que é limitada pela largura de banda da memória e pela CPU.

Qualquer processo que aguarda um serviço externo. Um worker que passa 800 ms por tarefa em uma solicitação HTTP não ficará mais rápido com um disco melhor.

Por que o hypervisor é tão importante quanto o meio

Você não se comunica diretamente com o dispositivo. Você se comunica com um disco virtual apresentado pelo hypervisor, geralmente por meio de virtio, e várias decisões nessa camada importam mais do que escolher entre NVMe e SATA.

Você não consegue ver o meio a partir do guest. lsblk -d -o NAME,ROTA,SIZE,MODEL mostra vda com o modelo vazio, porque virtio não transmite a identidade da unidade. cat /sys/block/vda/queue/rotational informa o que o hypervisor anuncia, portanto um valor 0 não prova que o armazenamento usa flash. nvme list, do pacote nvme-cli, não lista nada na maioria dos VPS, mesmo quando o host está cheio de unidades NVMe, porque seu disco é um dispositivo virtio, não um dispositivo NVMe. Um plano que informa NVMe geralmente descreve o armazenamento usado pelo host. Seu volume ainda pode estar conectado pela rede.

O modo de cache do host altera os números mais do que o meio. Com o cache de gravação habilitado no host, um fsync() do guest pode retornar assim que o host tiver os dados na própria RAM. Isso produz um resultado de benchmark que nenhum dispositivo físico conseguiria fornecer. Também significa que uma falha do host pode causar a perda de gravações que o banco de dados considera seguras. Com o modo de cache none, os números são menores e representam melhor o desempenho real.

Limites e créditos de burst. Muitos provedores limitam o IOPS por volume ou por plano, e muitos volumes de rede usam uma permissão de burst. Uma permissão de burst é um conjunto de créditos: o volume opera em alta velocidade enquanto houver créditos e depois cai para uma linha de base muito menor. O sintoma é fácil de reconhecer. Uma importação ou restauração é executada rapidamente por vários minutos, depois fica muito mais lenta e permanece lenta, sem nenhuma alteração na sua configuração. Você consumiu os créditos.

Vizinhos. Em um host compartilhado, a latência do seu disco varia conforme as atividades dos outros guests. Esse é o motivo para medir mais de uma vez. Execute o mesmo teste pela manhã e novamente à noite e compare a variação. Em um host ocupado, a diferença entre duas execuções no mesmo volume costuma ser maior que a diferença publicada entre dois meios.

Como medir o disco que seu VPS realmente tem

Instale o fio, o benchmark padrão de IO, e faça a medição. Primeiro, observe três cuidados. O teste cria um arquivo, portanto usa espaço em disco e conta para qualquer limite de IOPS pelo qual você seja cobrado. Mantenha as execuções curtas. Não execute o teste com profundidade de fila máxima em um volume que esteja atendendo tráfego ativo, porque você estará competindo com a própria aplicação.

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

Leitura aleatória com profundidade de fila 32, que é a profundidade informada pelos fornecedores:

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

A linha importante começa com read:

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

--direct=1 ignora o cache de páginas do guest, portanto o resultado descreve o dispositivo, e não sua RAM. Se você omitir essa opção, medirá a memória, que retorna um valor que nenhum disco pode alcançar. Use --size=4G ou um valor maior se houver espaço, porque um arquivo de 1G pode permanecer inteiramente no cache do host e produzir um resultado artificialmente alto.

A profundidade de fila 1 mostra a latência bruta, que é o que um processo de thread única experimenta:

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

O teste de commit prevê o comportamento do banco de dados. Ele grava 4k e chama fdatasync() depois de cada gravação, portanto a taxa informada inclui o flush:

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

O valor de IOPS dessa execução é próximo ao número máximo de pequenas transações por segundo que uma conexão de banco de dados pode confirmar, porque um commit espera pelo mesmo flush.

Para uma amostra rápida sem 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

O valor mdev, o desvio médio, é tão importante quanto a média. Um desvio alto em um host ocioso indica que o backend de armazenamento é compartilhado e está ocupado.

Como interpretar o resultado

Em julho de 2026, estas são interpretações razoáveis para uma pequena VPS. Dezenas de milhares de IOPS de leitura aleatória de 4k com profundidade de fila 32, e latência com profundidade de fila 1 inferior a cerca de 0.3 ms, são compatíveis com flash local. Uma latência de vários milissegundos com profundidade de fila 1 indica um caminho de rede, independentemente do nome do plano. Leituras sequenciais que param perto de 550 MB/s são a assinatura de um link SATA. Um número muito acima do que qualquer dispositivo único consegue alcançar indica que há cache no caminho, quase sempre no host.

Para ver como sua carga de trabalho atual está afetando o disco:

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

Na saída de iostat -x, leia r_await e w_await, que são, respectivamente, o número médio de milissegundos que uma solicitação aguardou, e aqu-sz, o tamanho médio da fila. Ignore %util em um disco virtual. Esse valor informa a porcentagem de tempo em que pelo menos uma solicitação estava pendente, mas não indica a saturação de um dispositivo que atende muitas solicitações simultaneamente. Portanto, %util de 100 junto com r_await de 0.2 ms representa um disco ocupado, mas saudável. Em vmstat, a coluna wa indica a porcentagem do tempo de CPU gasto aguardando IO. Se /proc/pressure/io existir no seu kernel, seu valor some avg10= será a porcentagem dos últimos 10 segundos durante a qual pelo menos uma tarefa ficou bloqueada aguardando IO. Essa é a resposta mais direta para saber se o armazenamento é o gargalo.

Como é um VPS limitado pelo disco

Uma média de carga alta com CPU ociosa e um wa grande em vmstat significa que os processos estão aguardando o disco. O sinal mais claro no kernel é esta mensagem em dmesg -T:

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

Essa linha aparece porque uma thread do kernel esperou mais de dois minutos pela resposta do armazenamento, e o watchdog de tarefas travadas a registrou. jbd2 é a thread do journal do ext4, o que significa que todo o sistema de arquivos estava aguardando, não apenas um programa com comportamento inadequado. Em um VPS, isso geralmente aponta para o backend de armazenamento ou para um limite de IOPS esgotado.

Os sintomas da aplicação seguem o mesmo padrão. O tempo de resposta mediano continua aceitável, enquanto as solicitações mais lentas formam uma cauda longa, porque apenas as solicitações que acessam o disco sofrem esse custo. apt upgrade permanece em Unpacking por minutos, porque o dpkg faz flush enquanto grava. git status em um repositório grande leva segundos. Esses são custos de metadados e de flush, portanto, mais largura de banda não ajudaria.

O que fazer quando o disco é o limite

Compre RAM antes de comprar IOPS. Se o conjunto de trabalho couber no cache de páginas, as leituras deixam de acessar o disco. Dobrar a memória costuma ser melhor do que migrar para uma classe de armazenamento mais rápida e geralmente custa menos.

Reduza o número de flushes quando os dados permitirem. No PostgreSQL, synchronous_commit = off permite que um commit retorne antes de a gravação chegar ao disco. Se o servidor falhar, você pode perder a última fração de segundo das transações. O banco de dados não é corrompido, porque o write-ahead log continua sendo gravado em ordem. Essa troca é adequada para uma cópia de análise, mas não para pagamentos. innodb_flush_log_at_trx_commit = 2 no MySQL oferece a mesma troca.

Agrupe arquivos pequenos. Uma transferência ou um backup de um milhão de arquivos pequenos é dominado pelo custo por arquivo. Por isso, arquivar primeiro e mover um único fluxo é mais rápido em armazenamento com alta latência do que copiar a árvore arquivo por arquivo.

Mantenha o discard funcionando em volumes thin. No armazenamento thin provisioned, o backend não sabe que um bloco está livre até que o sistema de arquivos informe isso. Um volume que nunca executa trim perde desempenho de gravação gradualmente. O Ubuntu fornece um timer semanal para isso:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av exibe os bytes descartados por ponto de montagem. Uma mensagem informando que a operação de discard não é suportada significa que o disco virtual não encaminha o discard para o host. Nesse caso, não há nada para corrigir.

Ignore o ajuste do agendador de IO. Em um disco virtio, cat /sys/block/vda/queue/scheduler geralmente já exibe none, e o agendamento real ocorre no host, ao qual você não tem acesso. Ignore noatime também: por padrão, o Ubuntu monta com relatime, o que já evita quase todas as gravações de atime.

Escolhendo um plano

Pague por NVMe quando um banco de dados, um servidor de e-mail, um executor de CI ou uma compilação que usa muitos pacotes estiver no servidor. Não pague mais por um site em cache nem por um aplicativo cujo tempo seja consumido por chamadas externas. Se não tiver certeza, o disco provavelmente não é o seu limite, porque a maioria das cargas de trabalho pequenas em VPS fica sem RAM ou largura de banda primeiro.

Faça medições no primeiro dia, enquanto percorre os primeiros dez minutos em um VPS novo, e mantenha a saída em um arquivo. Uma linha de base permite comprovar depois que o servidor ficou mais lento, em vez de o problema estar no seu código. Prefira provedores que informem por escrito a classe de armazenamento e qualquer limite de IOPS. Se um plano diz NVMe e uma leitura com profundidade de fila 1 leva 4 ms, você tem armazenamento de rede em um host equipado com NVMe. Isso é algo legítimo para vender e uma coisa diferente para comprar.

FAQ

O NVMe é sempre mais rápido que um SSD SATA em um VPS?

Não. Na profundidade de fila 1, os dois têm desempenho semelhante, aproximadamente de 80 a 150 microssegundos para uma leitura 4k, e um programa de thread única não consegue diferenciá-los. O NVMe se destaca quando há muitas solicitações em andamento, porque o AHCI oferece uma fila com profundidade de 32 comandos, enquanto o NVMe oferece milhares de filas mais profundas. Em um host compartilhado, a carga de outros guests pode alterar sua latência mais do que o tipo de mídia, portanto meça seu próprio volume com fio em vez de considerar apenas o nome do plano.

Como verifico se meu VPS realmente usa NVMe?

Você não pode verificá-lo diretamente, porque o virtio oculta o dispositivo físico. lsblk mostra vda sem uma string de modelo, nvme list não retorna nada, e /sys/block/vda/queue/rotational informa apenas o que o hypervisor anuncia. Em vez disso, meça o comportamento. Uma leitura aleatória 4k na profundidade de fila 1, com latência inferior a aproximadamente 0.3 ms, indica flash local. Vários milissegundos indicam que há um salto de rede no caminho. Leituras sequenciais que param perto de 550 MB/s indicam um link SATA.

O NVMe faz meu site carregar mais rápido?

Geralmente, não. Depois da primeira solicitação, o Linux mantém os arquivos no page cache da RAM, e o disco deixa de ser usado. Em um VPS pequeno, a velocidade da página normalmente é limitada pelo tempo de CPU da aplicação e pela largura de banda. O disco volta ao caminho crítico se o site gravar em todas as solicitações, por exemplo, um carrinho baseado em banco de dados que faz commits frequentes, porque cada commit espera a conclusão de um flush.

Qual é um bom resultado do fio para um VPS?

Em julho de 2026, um VPS pequeno em flash local normalmente retorna dezenas de milhares de IOPS de leitura aleatória 4k na profundidade de fila 32, com latência inferior a 0.3 ms na profundidade de fila 1. O armazenamento de blocos em rede normalmente retorna alguns milhares de IOPS, com latência de alguns milissegundos. Execute o teste três vezes em horários diferentes. Uma grande variação entre as execuções informa mais do que a média, porque mostra quanto os outros guests no host afetam você.

Devo colocar meu banco de dados em armazenamento de blocos em rede?

Você pode fazer isso, e muitos serviços gerenciados fazem isso, mas o caminho de commit sofre com essa escolha. Cada flush atravessa a rede, portanto uma única conexão faz commit de menos transações pequenas por segundo do que faria em flash local. Em troca, você obtém durabilidade que sobrevive ao host. Se escolher armazenamento em rede para um banco de dados com muitas gravações, agrupe o trabalho em transações maiores, para que menos flushes gravem mais linhas.