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

O NVMe é importante numa VPS?

O NVMe é importante numa VPS quando o seu software faz muitas leituras e escritas pequenas e aguarda a conclusão de cada uma. Faz pouca diferença num site que serve páginas em cache ou num programa que passa a maior parte do tempo à espera da rede. O meio de armazenamento é apenas um dos fatores. O hypervisor à frente do disco e os restantes guests que partilham o mesmo host definem o limite de desempenho que obtém efetivamente.

O que o NVMe altera e o que não altera

NVMe (non-volatile memory express) não é um tipo de memória flash. É o protocolo e a ligação usados para aceder à memória flash. Um dispositivo NVMe utiliza pistas PCIe (peripheral component interconnect express) e comunica através de NVMe. Um SSD SATA (serial ATA) utiliza uma ligação SATA e comunica através de AHCI (advanced host controller interface). Os chips de memória que armazenam os seus bytes podem ser idênticos nos dois casos.

Há duas diferenças, e ambas estão relacionadas com o caminho dos comandos, não com o armazenamento propriamente dito.

Filas. O AHCI fornece ao kernel uma fila de comandos com capacidade para 32 comandos. O NVMe permite milhares de filas, na prática uma por núcleo de CPU, e cada uma pode ser muito mais profunda do que 32. Um processo que leia um bloco de cada vez não deteta essa diferença. Uma base de dados com 64 leituras pendentes deteta-a: em SATA, o 33.º pedido espera por um lugar na fila antes de o dispositivo sequer o receber, enquanto o dispositivo NVMe aceita todos e processa-os em conjunto.

Largura da ligação. Uma ligação SATA III funciona a 6 Gbit/s, o que corresponde a cerca de 550 MB/s de dados reais depois do overhead do protocolo. Esse é um limite fixo, independentemente da memória flash ligada. Quatro pistas PCIe transportam vários gigabytes por segundo, pelo que a ligação deixa de ser o limite.

A latência é o aspeto em que as expectativas costumam estar erradas. Com uma profundidade de fila de 1, ou seja, um único pedido em curso, um SSD SATA responde a uma leitura de 4k em cerca de 100 a 150 microssegundos. O NVMe responde em cerca de 80 a 100. Ambos são rápidos, e nenhum programa que execute notará a diferença num único pedido. A diferença surge com a concorrência. A profundidade da fila, isto é, o número de pedidos em curso ao mesmo tempo, é a definição que determina se os dois meios de armazenamento têm um comportamento semelhante ou muito diferente.

O armazenamento de blocos através da rede é uma terceira classe, com características diferentes. Uma escrita atravessa a rede até um cluster de armazenamento e só é confirmada quando o cluster a tiver armazenado, pelo que a latência é medida em milissegundos, e não em microssegundos. O que se obtém em troca dessa latência é durabilidade: o volume sobrevive ao host ao qual está ligado e pode ser objeto de snapshots e redimensionado.

Valores publicados típicos: NVMe, SATA SSD 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 é normalmente anunciado com 184,000 IOPS de leitura aleatória 4k (operações de entrada/saída por segundo), com profundidade de fila 32. O mesmo teste num SATA SSD é anunciado perto de 90,000, limitado pela fila única do AHCI e pela ligação de 6 Gbit/s. O armazenamento de blocos em rede é normalmente limitado pelo fornecedor, não pelo hardware, e 12,500 é um limite superior documentado comum.

A latência expressa o mesmo na unidade que os utilizadores sentem. A latência de leitura p99, ou seja, a latência dos 1 por cento de pedidos mais lentos, é de cerca de 0.4 ms no NVMe local e 1.2 ms no SATA. Quando a rede entra no percurso, passa para 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 num servidor lê um ficheiro grande do princípio ao fim à velocidade máxima. A coluna aleatória e a coluna de latência descrevem o comportamento real de uma base de dados, de uma fila de correio ou de um gestor de pacotes.

Quais cargas de trabalho percebem o disco

Uma regra explica todos estes casos: uma carga de trabalho só percebe o disco quando fica à espera do disco. O Linux mantém em RAM os dados de ficheiros usados recentemente, na cache de páginas, pelo que a segunda leitura de um ficheiro nunca chega ao armazenamento. Se o conjunto de trabalho, ou seja, os dados efetivamente em uso, couber na RAM, as leituras passam a ser leituras de memória depois da primeira passagem. As escritas são diferentes. Qualquer escrita que a aplicação descarregue com fsync() tem de estar num armazenamento persistente antes de a aplicação poder continuar.

Trabalho que confirma transações. PostgreSQL, MySQL e SQLite chamam fsync() ou fdatasync() durante a confirmação, e cada confirmação espera pela resposta do dispositivo. A taxa de confirmações de uma ligação é, por isso, determinada pela latência de escrita, 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 dispositivo que demora 5 ms, e nenhum aumento de débito altera esse facto. O MySQL regista essa situação no log de erros quando o descarregamento não acompanha o ritmo:

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

O PostgreSQL regista-a nas linhas de checkpoint, onde um valor elevado 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 acede a muitos ficheiros pequenos. Cada ficheiro envolve operações de metadados que uma leitura sequencial grande não envolve. npm install, git clone de um repositório grande, a descompressão de imagens de contentores, um armazenamento de correio Maildir e uma cópia de segurança que percorre uma árvore grande passam grande parte do tempo em acessos aleatórios pequenos. Um trabalho de cópia de segurança restic numa VPS lê e calcula o hash de cada ficheiro que ainda não encontrou, pelo que a duração de uma cópia de segurança de um milhão de ficheiros acompanha de perto a latência de leitura aleatória. O mesmo acontece com du -sh, que lê apenas metadados.

As bases de dados que ultrapassam a capacidade da RAM também pertencem a este grupo. Quando o índice deixa de caber na cache de páginas, cada consulta transforma-se numa leitura aleatória e o disco volta a estar no caminho crítico.

Quais cargas de trabalho não percebem a diferença do disco

Um blog ou um site pequeno de uma empresa. As páginas são pequenas, a cache de páginas mantém todas na memória depois do primeiro pedido, e o limite está no processamento da renderização ou na largura de banda dos recursos. Uma stack LAMP no Ubuntu 24.04 que serve um site com pouco tráfego praticamente não faz operações de entrada e saída no disco depois de aquecida.

Transmissão de multimédia. Uma transmissão 4K a 40 Mbit/s lê 5 MB/s. Dez transmissões leem 50 MB/s, uma taxa que até o armazenamento de blocos através da rede consegue servir sem dificuldade. Um servidor de multimédia Jellyfin numa VPS é limitado pela largura de banda de saída da rede disponível e pelo CPU quando faz transcodificação, não pelo meio de armazenamento.

Inferência local de modelos. Executar Ollama numa VPS para alojar um LLM lê o ficheiro 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. Não altera o número de tokens por segundo, que é limitado pela largura de banda da memória e pelo CPU.

Qualquer tarefa que aguarde por um serviço externo. Um worker que passa 800 ms por tarefa a fazer um pedido HTTP não fica mais rápido com um disco melhor.

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

Você não comunica diretamente com o dispositivo. Você comunica com um disco virtual apresentado pelo hypervisor, normalmente através de virtio, e várias decisões nessa camada são mais importantes do que escolher NVMe em vez de SATA.

Você não consegue ver o meio de armazenamento 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 é flash. nvme list, do pacote nvme-cli, não lista nada na maioria dos VPS, mesmo quando o host tem muitas unidades NVMe, porque o seu disco é um dispositivo virtio, não um dispositivo NVMe. Um plano que diz NVMe normalmente descreve o armazenamento existente no host. O seu volume ainda pode estar ligado pela rede.

O modo de cache do host altera os números mais do que o meio de armazenamento. Com o cache de escrita writeback ativado no host, um fsync() no 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 poderia oferecer. Também significa que uma falha do host pode perder escritas que o seu banco de dados considera seguras. Com o modo de cache none, os números são menores e mais realistas.

Limites e créditos de burst. Muitos provedores limitam os IOPS por volume ou por plano, e muitos volumes de rede usam uma permissão de burst. Essa permissão é um conjunto de créditos: o volume funciona rapidamente enquanto houver créditos e depois cai para uma linha de base muito mais baixa. O sintoma é fácil de reconhecer. Uma importação ou restauração é executada rapidamente durante vários minutos, depois fica muito mais lenta e continua 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 a atividade 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 do que a diferença publicada entre dois meios de armazenamento.

Como medir o disco que o seu VPS realmente tem

Instale o fio, o benchmark padrão de IO, e faça a medição. Primeiro, tenha em conta três precauções. O teste cria um ficheiro, por isso utiliza espaço em disco e é contabilizado em qualquer limite de IOPS incluído na faturação. Mantenha as execuções curtas. Não o execute com uma profundidade de fila máxima num volume que esteja a servir tráfego de produção, porque estará a competir com a sua 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 indicada 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 relevante começa com read:

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

--direct=1 ignora a cache de páginas do guest, por isso o resultado descreve o dispositivo e não a sua RAM. Se o omitir, medirá a memória, que devolve um valor que nenhum disco consegue atingir. Use --size=4G ou um valor superior se tiver espaço, porque um ficheiro de 1G pode ficar totalmente dentro da cache do host e inflacionar o resultado.

A profundidade de fila 1 mostra a latência bruta, que é a latência sentida por um processo de thread único:

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 de uma base de dados. Escreve 4k e chama fdatasync() depois de cada escrita, por isso a taxa apresentada 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 aproxima-se do número máximo de pequenas transações por segundo que uma ligação de base de dados consegue confirmar, porque um commit espera pelo mesmo flush.

Para obter 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 como a média. Um desvio elevado num host sem carga significa que o backend de armazenamento é partilhado e está ocupado.

Como ler o resultado

Em julho de 2026, estes são valores razoáveis para um VPS pequeno. Dezenas de milhares de IOPS de leitura aleatória de 4k com profundidade de fila 32, e uma 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 uma ligação SATA. Um valor muito acima do que qualquer dispositivo individual consegue atingir indica que existe cache no caminho, quase sempre no host.

Para ver o efeito da carga de trabalho atual no disco:

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

Na saída de iostat -x, leia r_await e w_await, o número médio de milissegundos durante o qual um pedido aguardou, e aqu-sz, o comprimento médio da fila. Ignore %util num disco virtual. Este campo indica a percentagem de tempo em que pelo menos um pedido estava pendente, mas não informa sobre a saturação de um dispositivo que processa muitos pedidos em simultâneo. Por isso, um %util de 100 juntamente com um r_await de 0.2 ms indica um disco ocupado, mas saudável. Em vmstat, a coluna wa indica a percentagem do tempo de CPU gasto à espera de IO. Se /proc/pressure/io existir no seu kernel, o valor some avg10= indica a percentagem dos últimos 10 segundos durante a qual pelo menos uma tarefa ficou bloqueada à espera de IO. Esta é a resposta mais direta à questão de saber se o armazenamento é o seu gargalo.

Como é um VPS limitado pelo disco

Uma média de carga elevada, CPU ociosa e um wa grande em vmstat significam que os processos estão em fila à espera do 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 bloqueadas registou o evento. jbd2 é a thread do journal do ext4, o que significa que todo o sistema de ficheiros estava à espera, e não apenas um programa com comportamento incorreto. Num VPS, isto normalmente 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 mantém-se aceitável, enquanto os pedidos mais lentos formam uma cauda longa, porque apenas os pedidos que acedem ao disco sofrem o atraso. apt upgrade permanece em Unpacking durante minutos, porque o dpkg faz flush à medida que escreve. git status num repositório grande demora segundos. Estes custos estão relacionados com metadados e operações de flush, por isso 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 page cache, as leituras deixam completamente de chegar ao disco. Duplicar a memória costuma trazer mais benefícios do que mudar para uma classe de armazenamento mais rápida e, normalmente, custa menos.

Reduza o número de flushes, quando os dados permitirem. No PostgreSQL, synchronous_commit = off permite que um commit seja concluído antes de os dados serem gravados no disco. Se o servidor falhar, pode perder a última fração de segundo de transações. A base de dados não fica corrompida, porque o write-ahead log continua a ser gravado pela ordem correta. Esta troca é adequada para uma cópia usada em análises e inadequada para pagamentos. innodb_flush_log_at_trx_commit = 2 no MySQL aplica a mesma troca.

Agrupe ficheiros pequenos. Uma transferência ou cópia de segurança de um milhão de ficheiros pequenos é dominada pelo custo de cada ficheiro. Por isso, criar primeiro um arquivo e mover um único fluxo é mais rápido em armazenamento com elevada latência do que copiar a árvore ficheiro a ficheiro.

Mantenha o discard ativo em volumes thin. Num armazenamento com provisionamento thin, o backend não sabe que um bloco está livre até o sistema de ficheiros o indicar. Um volume que nunca executa trim perde gradualmente desempenho de escrita. O Ubuntu inclui um timer semanal para isto:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av mostra os bytes submetidos a trim por ponto de montagem. Uma mensagem a indicar 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 escalonador de I/O. Num disco virtio, cat /sys/block/vda/queue/scheduler normalmente já mostra none, e o escalonamento real ocorre no host, ao qual não tem acesso. Ignore também noatime: por predefinição, o Ubuntu monta com relatime, o que já evita quase todas as escritas de atime.

Escolha do plano

Pague por NVMe quando houver uma base de dados, um servidor de correio, um runner de CI ou uma compilação com muitos pacotes no servidor. Não pague um preço superior por um site em cache nem por uma aplicação cujo tempo seja consumido por chamadas externas. Se tiver dúvidas, 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 segue os primeiros dez minutos num VPS novo, e guarde o resultado num ficheiro. Uma linha de base permite provar mais tarde que o servidor ficou mais lento, e não que o problema está no seu código. Prefira fornecedores que indiquem por escrito a classe de armazenamento e qualquer limite de IOPS. Se um plano disser NVMe, mas uma leitura com profundidade de fila 1 demorar 4 ms, está a usar armazenamento de rede num host equipado com NVMe. É uma oferta legítima, mas corresponde a algo diferente do que está a comprar.

FAQ

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

Não. Com uma profundidade de fila de 1, os dois têm desempenho próximo, cerca de 80 a 150 microssegundos para uma leitura 4k, e um programa de thread único não consegue distingui-los. O NVMe ganha vantagem quando há muitos pedidos em curso, porque o AHCI oferece uma fila com 32 comandos, enquanto o NVMe oferece milhares de filas mais profundas. Num host partilhado, a carga de outros guests pode alterar a sua latência mais do que o tipo de armazenamento, por isso meça o seu próprio volume com fio em vez de se basear no nome do plano.

Como verifico se a minha VPS usa realmente NVMe?

Não é possível verificar isso diretamente, porque o virtio oculta o dispositivo físico. lsblk mostra vda sem uma cadeia de modelo, nvme list não devolve nada e /sys/block/vda/queue/rotational comunica apenas o que o hypervisor anuncia. Meça o comportamento. Uma leitura aleatória 4k com profundidade de fila de 1 e latência inferior a cerca de 0.3 ms indica flash local. Vários milissegundos indicam que existe um salto de rede no percurso. Leituras sequenciais que param perto de 550 MB/s indicam uma ligação SATA.

O NVMe faz o meu site carregar mais depressa?

Normalmente, não. Depois do primeiro pedido, o Linux serve os ficheiros a partir da page cache na RAM, por isso o disco fica inativo. Numa VPS pequena, a velocidade da página é normalmente limitada pelo tempo de CPU da aplicação e pela largura de banda. O disco volta a fazer parte do caminho crítico se o site escrever em cada pedido, por exemplo, um carrinho baseado numa base de dados que faz commits frequentes, porque cada commit espera que um flush termine.

Qual é um bom resultado do fio para uma VPS?

Em julho de 2026, uma VPS pequena com flash local devolve normalmente dezenas de milhares de IOPS de leitura aleatória 4k com uma profundidade de fila de 32, e uma latência inferior a 0.3 ms com profundidade de fila de 1. O armazenamento de blocos em rede devolve normalmente alguns milhares de IOPS, com uma latência de alguns milissegundos. Execute o teste 3 vezes em horários diferentes. Uma grande diferença entre as execuções informa mais do que a média, porque mostra o impacto dos outros guests no host.

Devo colocar a minha base de dados num armazenamento de blocos em rede?

Pode fazê-lo, e muitos serviços geridos fazem isso, mas o caminho do commit sofre esse impacto. Cada flush atravessa a rede, por isso uma única ligação faz menos transações pequenas por segundo do que faria com flash local. Em contrapartida, obtém durabilidade que sobrevive ao host. Se escolher armazenamento em rede para uma base de dados com muitas escritas, agrupe o trabalho em transações maiores, para que menos flushes transportem mais linhas.