Como resolver lentidão de I/O de disco na VPS: diagnóstico e soluções práticas

*# Como resolver lentidão de I/O de disco na VPS: diagnóstico e soluções práticas

Meta descrição: Aprenda a corrigir lentidão de I/O de disco na VPS com diagnósticos, ajustes no Linux e boas práticas para reduzir iowait e melhorar performance.

Se sua VPS “tem CPU sobrando”, mas tudo demora — banco de dados travando, painéis lentos, deploy que não termina, automações que engasgam — há uma grande chance de você estar lidando com lentidão de I/O de disco na VPS. O ponto-chave aqui é que nem sempre o problema é “falta de CPU” ou “pouca RAM”. Às vezes, o servidor está esperando o disco responder, e isso aparece como iowait alto na VPS.

Neste guia, você vai aprender a:

• Identificar sintomas reais de gargalo de disco (sem adivinhação);
• Entender as causas mais comuns (inclusive as que parecem “misteriosas”);
• Testar performance de disco VPS com ferramentas simples;
• Aplicar ajustes e boas práticas para otimizar I/O de disco no Linux;
• Monitorar para o problema não voltar.

A ideia é ser prático: diagnóstico primeiro, solução depois — e com passos que funcionam para iniciantes.*

Quando falamos em lentidão de I/O de disco na VPS, estamos falando de um tipo de gargalo em que a VPS passa mais tempo esperando leitura/gravação do que realmente processando tarefas. Isso é extremamente comum em cenários como:

• Banco de dados (PostgreSQL/MySQL) sob carga, com muitas gravações;
• Aplicações com muitos logs e arquivos temporários;
• Filas e automações (ex.: n8n) salvando execuções, histórico e dados em disco;
• VPS com armazenamento mais simples (ou com vizinhos barulhentos em ambiente compartilhado).

O que confunde muita gente é que, mesmo com “CPU baixa”, o servidor parece travado. Isso acontece porque processos ficam bloqueados aguardando o disco. No Linux, um dos sinais mais claros disso é o iowait alto na VPS: parte do tempo de CPU é gasto esperando I/O.

A boa notícia: na maioria dos casos dá para diagnosticar com precisão e aplicar correções incrementais (configurações, ajustes no sistema de arquivos, organização de logs, mudanças no banco, etc.). Em situações mais críticas, a solução pode ser simplesmente migrar para um storage melhor (NVMe) ou aumentar recursos — mas isso deve ser o último passo, não o primeiro.

Ao longo deste artigo, vou te mostrar um caminho em camadas: entender sintomas, confirmar com testes, achar a causa raiz e aplicar soluções práticas sem quebrar nada no processo.

Como identificar sinais de lentidão de I/O de disco na VPS

Antes de sair ajustando kernel, trocando scheduler ou “otimizando tudo”, vale reconhecer os sinais típicos de lentidão de I/O de disco na VPS. A melhor forma de pensar nisso é: o que no meu servidor depende diretamente de disco e está demorando demais?

Sintomas comuns no dia a dia

Alguns sinais aparecem sem você nem abrir o terminal:

• Páginas do painel/admin ou endpoints que ficam “carregando” e depois respondem de uma vez;
• Deploy travando em etapas que mexem com dependências e escrita em disco;
• Banco de dados lento em operações simples (principalmente INSERT/UPDATE);
• SSH “ok”, mas comandos como ls, cd e leitura de logs demoram mais do que deveriam;
• Aplicação com picos de latência sem aumento proporcional de CPU.

Em ferramentas e métricas, o padrão costuma ser:

• load average alto com CPU baixa (parece contraditório, mas é típico quando há processos bloqueados em I/O);
• iowait alto na VPS em momentos de lentidão;
• Fila de disco crescendo (muitas requisições aguardando atendimento).

Observando com comandos simples

Se você estiver começando, dá para captar o “cheiro” do problema com alguns comandos:

• top ou htop: observe o campo de I/O wait (em top ele aparece como %wa). Se esse número sobe bastante durante as travadas, é um forte indício.
• uptime: veja o load average. Se estiver alto e a CPU não estiver saturada, pode ser disco.
• dmesg -T | tail -n 50: procure mensagens de erro de disco, timeouts, filesystem “remount read-only” etc.

O segredo aqui é correlacionar: quando a lentidão acontece, quais sinais aparecem juntos? Se o problema é I/O, quase sempre você vai ver o %wa subir, processos entrarem em estado de espera e as operações que dependem de disco virarem o gargalo.

Um exemplo bem real

Imagine um n8n rodando com banco e muitos workflows. Se você guarda muitas execuções, logs e histórico, o n8n e o banco começam a gravar muito. Em VPS com disco mais limitado, isso vira fila. Resultado: as execuções “somem”, o editor fica lento e o banco parece “congelar”, mesmo sem CPU alta.

Identificar esses sinais é o primeiro passo para evitar o erro mais comum: tratar sintoma (CPU/RAM) quando o problema é o disco.

🤖 Uma dica extra se você está rodando n8n: aprender a estruturar automações do jeito certo

Quando a gente começa a usar automações e agentes, é normal colocar tudo “no mesmo servidor” e deixar histórico/logs crescendo… e aí o disco vira gargalo. O que mais ajuda, na prática, é aprender a montar a arquitetura e as rotinas do n8n já pensando em escala (retenção de execuções, modo fila, banco bem configurado, monitoramento etc.).

Uma formação que eu vi que pega bem nesse ponto — com foco bem mão na massa — é a Formação Agentes de IA (n8n) da Hora de Codar. Ela tem 221+ aulas, 21+ projetos, 20h+ e uma trilha bem completa para sair do básico até fluxos profissionais, incluindo instalação em VPS e otimização.

Se quiser dar uma olhada no conteúdo (vale nem que seja para comparar a estrutura), o link é:

https://app.horadecodar.com.br/lp/formacao-agentes-de-ia-n8n?utm_source=blog

Principais causas de iowait alto e gargalos de I/O em VPS Linux

O iowait alto na VPS quase nunca aparece “do nada”. Ele é consequência de algo pedindo mais do disco do que o ambiente consegue entregar. Em VPS Linux, as causas mais frequentes se dividem em três grupos: limitações do storage, padrões de uso da aplicação e problemas de configuração/manutenção.

1) Limitações do storage e do ambiente da VPS

Mesmo quando você tem SSD, nem todo SSD é igual — e em VPS existe o fator “infra compartilhada”. Algumas causas típicas:

• Disco com baixa performance (ou não-NVMe): latência maior e IOPS menores, especialmente sob escrita.
• Limites do provedor: alguns planos têm teto de IOPS ou throughput.
• “Noisy neighbor”: outro cliente no mesmo host físico pode estar consumindo I/O, impactando seu desempenho.

Isso explica por que às vezes o servidor está rápido de manhã e lento à noite: a carga do host muda.

2) Pressão de escrita/leitura gerada pelo seu stack

Mesmo um disco bom sofre se a aplicação estiver gerando I/O desnecessário. Exemplos comuns:

• Logs verbosos demais (principalmente em debug): centenas de MB/GB por dia.
• Banco de dados com consultas que fazem muita leitura por falta de índice.
• Workloads de fila/automação (como n8n) persistindo muita coisa em disco: histórico de execuções, binários, anexos, cache.
• Swap acontecendo: quando falta RAM, o sistema começa a usar swap, e isso pode explodir a latência. Muitos interpretam como “disco ruim”, mas a raiz pode ser memória.

3) Problemas de sistema e manutenção

Aqui entram pontos que parecem pequenos, mas viram gargalo:

• Disco lotado (90–100%): filesystem fica mais lento e o sistema sofre para alocar blocos.
• Filesystem com opções inadequadas para o tipo de carga.
• Banco de dados mal configurado (ex.: buffers muito baixos ou checkpoints agressivos).
• Backups e rotinas de compressão rodando em horários de pico e disputando I/O.

Como pensar em causa raiz (de forma prática)

Uma boa maneira de organizar a análise é perguntar:

1. “O disco está lento sempre ou só em horários específicos?” (suspeite de ambiente compartilhado, backups, vizinhos, jobs)
2. “A lentidão acontece quando há muitas gravações?” (logs, banco, histórico)
3. “A RAM está sobrando ou tem swap?” (se tem swap, trate isso antes)

Quando você entende a causa, fica mais fácil escolher a correção certa: às vezes é limpeza e ajuste; às vezes é arquitetura; e, em alguns casos, é mesmo hora de subir para um plano com NVMe e mais recursos.

Vídeo recomendado: como instalar o n8n na VPS (base sólida para performance)

Se você usa (ou pretende usar) n8n na VPS, uma instalação bem feita ajuda muito a evitar gargalos — inclusive os de disco, porque você organiza volumes, banco e serviços desde o início.

Assista ao tutorial “COMO INSTALAR n8n NA VPS EM 5 MINUTOS!” e aproveite para revisar boas práticas de setup:

CTA: veja o vídeo aqui:

https://youtube.com/watch?v=VCKzXFk_XjM%3Fsi%3DeOBTMrjZNPj3q07Z

Como testar a performance de disco na VPS

Para testar performance de disco VPS, você quer duas coisas: medir (a) throughput (MB/s) e (b) latência/IOPS (operações pequenas). A combinação das duas é o que define se o sistema “parece rápido” em aplicações reais.

1) Comece vendo o cenário atual

Antes de rodar benchmarks, olhe como o sistema está se comportando:

• df -h: verifique espaço livre (disco cheio derruba performance).
• free -h: veja se há swap sendo usada.
• iostat -xz 1 (pacote sysstat): mostra utilização, await (latência), fila e mais.

No iostat, alguns pontos importantes:

• %util perto de 100% com frequência indica disco saturado;
• await alto indica latência alta (o “tempo de espera” das operações);
• r/s e w/s mostram volume de operações.

2) Teste simples de leitura sequencial

Para uma leitura básica (não perfeita, mas útil como triagem), você pode usar:

sudo hdparm -Tt /dev/vda

Isso dá uma noção rápida de leitura, mas não reflete bem cargas reais com escrita pequena e concorrência.

3) Benchmark mais realista com fio

O fio é a ferramenta mais usada para simular cargas de I/O. Em geral, você quer testar no diretório onde sua aplicação grava (ex.: /var/lib/postgresql, /var/lib/docker, etc.), mas com cuidado para não encher o disco.

Exemplo de teste de escrita/leitura randômica (blocos pequenos):

fio --name=randrw --filename=fio.test --size=1G --direct=1 --rw=randrw --bs=4k --iodepth=32 --numjobs=1 --runtime=60 --group_reporting

O que observar no resultado:

• IOPS (quanto maior, melhor para banco e filas);
• latência média e p95/p99 (quanto menor, melhor para “responsividade”);
• bw (bandwidth) para throughput.

Depois apague o arquivo: rm -f fio.test.

4) Teste de escrita sequencial (bom para logs e backups)

Quando o problema é log ou exportação, escrita sequencial importa:

fio --name=seqwrite --filename=fio.seq --size=2G --direct=1 --rw=write --bs=1M --iodepth=16 --runtime=60 --group_reporting

Interpretando de forma útil

O objetivo não é comparar com benchmarks da internet, e sim responder:

• “Meu disco está consistentemente rápido?”
• “A latência explode quando faço escrita randômica?”
• “O desempenho varia muito de um teste para outro?” (pode indicar contenda no host)

Se seus testes mostram latência muito alta e variando bastante, e isso coincide com travamentos na aplicação, você provavelmente achou o culpado. A partir daí, fica bem mais fácil escolher como otimizar I/O de disco no Linux sem chutar.

Soluções práticas para otimizar o I/O de disco no Linux

Depois de confirmar que o gargalo é disco, a pergunta vira: o que dá para melhorar sem reinventar o servidor? Abaixo estão soluções práticas (das mais simples às mais estruturais) para reduzir lentidão de I/O de disco na VPS.

1) Corte I/O desnecessário (o “dinheiro na mesa”)

Grande parte do iowait alto vem de coisas que você nem precisa gravar tanto:

• Ajuste logs: reduza nível de log em produção, habilite rotação (logrotate) e evite logar payloads gigantes.
• Limpe arquivos temporários: pastas de cache e tmp podem crescer e virar gargalo.
• Revise backups: comprimir e enviar backup no horário de pico pode derrubar o I/O. Tente janelas de menor tráfego.

2) Verifique swap e RAM

Se o servidor está usando swap, você pode estar pagando I/O “sem perceber”. Duas ações comuns:

• aumentar RAM (ou reduzir serviços no mesmo host);
• revisar limites de containers (Docker) para não forçar swapping.

Swap ocasional não é pecado, mas swap constante com latência alta costuma destruir a experiência.

3) Otimize o banco de dados (quando ele é o maior escritor/leitor)

Bancos são campeões em I/O randômico. Algumas melhorias típicas:

• criar índices para reduzir full scans;
• ajustar buffers/cache (ex.: shared_buffers no Postgres) para usar mais RAM e menos disco;
• reduzir retenção de dados históricos (especialmente em ferramentas que acumulam execuções).

Se você usa n8n, por exemplo, manter histórico infinito pode virar uma “máquina de gravar” no banco. Limitar retenção já ajuda bastante.

4) Ajustes no filesystem e mount options

Dependendo do seu cenário, opções de montagem podem reduzir escrita:

• noatime evita atualização de “last access time” em leituras.

Esse tipo de ajuste é simples, mas faça com cuidado e valide compatibilidade com sua distribuição e seu workload.

5) Container/stack: mova o que é “pesado” para storage melhor

Se você está em Docker, pense em volumes:

• banco e dados persistentes em volume dedicado;
• logs e caches controlados;
• separar “sistema” do “dado” ajuda a não saturar tudo ao mesmo tempo.

6) Quando a solução é infraestrutura (e está tudo bem)

Se você já limpou, ajustou e mediu, e ainda assim os testes mostram latência alta e pouca consistência, talvez a limitação seja do plano. Nessa hora, trocar para um storage NVMe e um provedor com boa entrega de IOPS é o atalho mais honesto.

Em projetos com automações, banco e múltiplos serviços, é comum que uma VPS de entrada sofra. Um upgrade bem escolhido remove o gargalo sem precisar “micro-otimizar” o Linux para sempre.

O ponto principal: otimizar I/O de disco no Linux é equilibrar “menos I/O gerado” + “I/O mais rápido” + “prioridade para o que importa”.

💻 VPS para reduzir gargalo de disco: por que eu gosto da Hostinger (especialmente para n8n)

Em muitos casos, você faz todo o diagnóstico, ajusta logs, melhora banco e… ainda assim a lentidão de I/O de disco na VPS continua porque o limite está no storage do plano. Aí, trocar para uma VPS com NVMe e recursos bem dimensionados costuma ser o passo que “destrava” o projeto.

Uma opção que eu gosto por ser bem direta para quem está começando (e por já ter caminho fácil para rodar n8n) é a VPS da Hostinger. Os planos vêm com armazenamento NVMe, boa estabilidade (99,9% uptime) e dá para escalar conforme o projeto cresce.

Se você quiser conferir, use este link de indicação:

https://www.hostinger.com.br/horadecodar

E se for contratar, dá para usar o cupom HORADECODAR para desconto.

Para referência rápida de planos (valores estimados em contrato de 24 meses): KVM 1 (1 vCPU, 4GB RAM, 50GB NVMe), KVM 2 (2 vCPU, 8GB RAM, 100GB NVMe), e assim por diante — o KVM 2 costuma ser um “meio-termo” legal para automações e serviços com banco.

Boas práticas e monitoramento contínuo para evitar novos problemas

Resolver a lentidão de I/O de disco na VPS uma vez é ótimo. Melhor ainda é impedir que ela volte — e isso acontece com duas coisas: rotina de boas práticas e monitoramento simples (mas consistente).

Tenha um “mínimo de observabilidade”

Você não precisa montar um NOC, mas precisa de alguns sinais contínuos:

• acompanhar espaço em disco (alerta antes de chegar em 80–85%);
• acompanhar uso de RAM e swap;
• acompanhar iowait e latência de disco em horários de pico.

Ferramentas como Netdata, Grafana + Prometheus, ou até alertas básicos via scripts já evitam surpresa. O ideal é ter gráficos para perceber tendência: “a latência está piorando toda semana?” é o tipo de pergunta que gráfico responde rápido.

Rotina de manutenção (sem paranoia)

Algumas rotinas simples reduzem muito risco:

• rotação e retenção de logs (seu I/O agradece);
• limpeza de backups antigos e caches que não fazem sentido manter;
• atualizações de segurança e reboot planejado (evita acumular problemas e melhora previsibilidade);
• checar jobs agendados (cron) que possam estar batendo no disco em horários críticos.

Defina limites para dados que crescem

A causa silenciosa mais comum é “crescimento infinito”:

• tabelas de histórico crescendo sem retenção;
• logs de aplicação crescendo sem rotação;
• armazenamento de anexos sem política de limpeza.

Quando você estabelece limites (retenção, arquivamento, expurgo), o servidor fica estável e você evita o ciclo “funciona bem → degrada → trava”.

Prepare o ambiente para escalar

Se o seu projeto envolve automações, webhooks e execução frequente (como em n8n), pense desde cedo em:

• separar serviços pesados quando crescer (banco em instância dedicada, por exemplo);
• usar modo fila/worker quando o volume aumentar;
• garantir storage NVMe e RAM suficiente para cache.

Monitoramento não serve só para “apagar incêndio”; ele serve para decidir upgrade com base em dado, não em sensação. Assim, quando aparecer iowait alto na VPS, você já sabe se é pico momentâneo, crescimento natural ou algo anormal.

O que causa lentidão de I/O de disco em uma VPS?

A lentidão de I/O de disco em uma VPS geralmente é causada por sobrecarga no acesso ao disco, processos consumindo muitos recursos, limitações do provedor ou problemas de configuração no sistema operacional. Também pode estar relacionada à escolha de discos lentos, como HDDs ao invés de SSDs.

Como diagnosticar problemas de I/O de disco na VPS?

O diagnóstico pode ser feito utilizando comandos como ‘iostat’, ‘vmstat’ e ‘top’ no Linux para monitorar métricas como iowait, uso do disco e identificar processos que estão impactando o desempenho. Ferramentas como ‘iotop’ ajudam a visualizar quais processos consomem mais recursos de I/O.

Quais são as principais soluções para resolver lentidão de I/O de disco na VPS?

As principais soluções incluem migrar para discos SSD, otimizar aplicações e reduzir acessos desnecessários ao disco, ajustar parâmetros do kernel para gerenciamento de I/O, limitar o uso de recursos por processos, atualizar infraestrutura e aplicar boas práticas de gerenciamento do sistema.

Conclusão

A lentidão de I/O de disco na VPS é um daqueles problemas que parecem “mágicos” no começo, mas ficam bem claros quando você mede: sintomas como travadas com CPU baixa, iowait alto na VPS e latência de disco elevada quase sempre apontam para o mesmo lugar.

O caminho mais seguro é: identificar sinais, testar performance de disco VPS com ferramentas como iostat e fio, e só então aplicar correções. Na prática, as melhores melhorias costumam vir de reduzir I/O desnecessário (logs/retenção/temporários), evitar swap constante, ajustar banco e manter uma rotina de monitoramento. E quando os dados mostram que o storage do plano não acompanha sua carga, migrar para uma VPS com NVMe e mais folga é uma decisão técnica — não “luxo”.

Se você roda automações (especialmente n8n), vale pensar em performance desde o setup: isso economiza muito tempo de “caça a gargalo” lá na frente.