Como resolver picos de I/O e uso de swap em VPS durante backups noturnos sem aumentar disco

Por · Publicado em · 8 min de leitura

Ampulheta em primeiro plano sobre mesa, com pessoa desfocada ao fundo
Ampulheta simboliza escalonamento de backups para reduzir picos de I/O Foto: Thirdman / Pexels

Está enfrentando picos de I/O e uso de swap em VPS durante backups noturnos e não quer (ou não pode) aumentar o disco? Veja um diagnóstico objetivo e ações práticas para reduzir contenção de I/O, limitar concorrência e ajustar o sistema — incluindo ionice/nice, bwlimit, snapshots e parâmetros de kernel — mantendo seus backups confiáveis.

Sintomas: como saber que é I/O e swap competindo

Durante a janela de backup, o sistema fica lento, o load average sobe e processos comuns travam esperando disco. A memória livre cai e a swap cresce. Geralmente há compressão, cópia de grandes arquivos ou snapshots concorrendo com o banco e serviços de produção.

Se esse é o cenário, o objetivo é reduzir picos e espalhar a escrita/leitura no tempo, sem aumentar o volume de armazenamento.

Diagnóstico rápido (10 minutos) para localizar o gargalo

Rode estas medições durante o backup. Procure filas de I/O altas, processos com I/O intenso e pressão de memória levando a swap.

Se houver limite de burst em discos de provedores, ele pode estar esgotando e gerando latência elevada.

# Utilização detalhada do disco (filas, espera, %util)
iostat -xy 5 3

# Pressão de memória e swap (cs, si/so)
vmstat 5 5; free -h; swapon --show

# Processos que mais fazem I/O (root requerido)
iotop -oPa

# Por processo: escrita/leitura por segundo
pidstat -d 5 3

# Histórico, se sysstat estiver habilitado
sar -b 1 10

Causas comuns em VPS durante backups

Na maioria dos incidentes, há uma combinação de fatores. Entender a origem guia a mitigação certa.

  • Backup lendo e comprimindo tudo de uma vez (tar/gzip, restic/borg com paralelismo alto).
  • rsync sem limite de banda e múltiplas threads varrendo o FS, gerando cache churn.
  • Snapshots em COW (ex.: LVM) mantidos por horas enquanto a base continua escrevendo — cresce I/O de cópia de blocos.
  • Compressão pesada (gzip -9/xz) causando mais leitura/gravação e competição de CPU/I/O.
  • Concorrência com outras rotinas noturnas (updatedb, logrotate com compress, ETLs, VACUUMs).
  • Disco da VPS atingindo limite de desempenho/burst do provedor, elevando latências.
  • Swappiness alta empurrando páginas para swap durante picos de cache e compressão.

Correções imediatas para hoje à noite (sem aumentar disco)

A meta é suavizar picos. Limite I/O e CPU do job de backup, reduza concorrência e melhore a eficiência da leitura/escrita.

Aplique gradualmente e monitore o efeito; priorize o que impacta mais com menor risco.

  • Forçar baixa prioridade de I/O/CPU no backup com ionice (classe idle) e nice (+15 ou +19).
  • Limitar throughput do rsync/restic/borg (ex.: --bwlimit) para evitar varreduras agressivas.
  • Reduzir concorrência: uma tarefa por vez; evite varrer e comprimir simultaneamente em múltiplos diretórios.
  • Excluir caches, temporários e arquivos rotacionados recentes do conjunto de backup.
  • Usar compressão mais leve e rápida (zstd nível moderado) para menos I/O por byte.
  • Agendar janelas diferentes para logrotate, VACUUM/ETL e backups, evitando sobreposição.
# Exemplos (ajuste caminhos e limites ao seu ambiente)
# rsync: limitar banda, priorizar CPU/I/O baixos
ionice -c3 nice -n 15 rsync -aHAX --delete \
  --bwlimit=20m --info=progress2 --exclude-from=/etc/backup.excludes \
  /dados/ user@backup:/repositorio/host1/

# restic: reduzir concorrência e I/O
IONICE="ionice -c3" NICE="nice -n 15" \
$IONICE $NICE restic backup /dados \
  --limit-bandwidth 20Mi \
  --compression max --pack-size 16Mi \
  --one-file-system

Estratégia robusta: snapshot rápido + upload incremental controlado

Separar a captura do estado (snapshot) do envio ao destino reduz o tempo de I/O intenso no host. Use snapshot curto e upload incremental com limites.

Com LVM snapshot, mantenha o snapshot pelo menor tempo possível para reduzir copy-on-write. Em seguida, faça o upload incremental (restic/borg) com limitação de I/O e banda.

Veja um passo a passo completo de LVM + Restic com timers em LVM snapshots + Restic em S3 (Debian).

Se usar containers, controle recursos por cgroups para que o backup nunca roube I/O crítico. Guia prático em cgroup v2 + systemd para Docker.

Ação Efeito esperado Risco/Observação
Snapshot curto (minutos) Minimiza COW e I/O no host Exige planejamento de consistência (ex.: flush do DB)
Upload incremental com limite Redistribui I/O no tempo Backup leva mais tempo (janela maior)
Compressão moderada (zstd) Menos CPU por byte e I/O estável Arquivos levemente maiores que gzip -9
Exclusões bem definidas Menos dados varridos e escritos Cuidado para não excluir o que precisa
Uma tarefa por vez Evita competição interna Orquestre dependências/timers

Ajustes de kernel e filesystem para reduzir swap e writeback

Use com cautela e teste antes de aplicar em produção. O objetivo é evitar empurrar memória para swap durante picos transitórios e reduzir flush agressivo.

Defina swappiness baixo/moderado, ajuste dirty ratios e avalie noatime no filesystem para diminuir escritas de metadados.

  • vm.swappiness entre 10 e 30 costuma evitar swap precoce em servidores.
  • vm.dirty_background_ratio e vm.dirty_ratio controlam quando o kernel começa a gravar páginas sujas.
  • noatime/relatime reduzem writes de atualização de acesso.
  • Readahead ajustado evita leituras desnecessárias em sequências curtas.
# Teste temporariamente (até reboot)
sudo sysctl vm.swappiness=20
sudo sysctl vm.dirty_background_ratio=5
sudo sysctl vm.dirty_ratio=20

# Persistir (edite com cuidado)
echo -e "vm.swappiness=20\nvm.dirty_background_ratio=5\nvm.dirty_ratio=20" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Agendamento, orquestração e visibilidade contínua

Evite sobreposição de jobs noturnos. Use timers com aleatoriedade e dependências. Meça continuamente para confirmar que a mitigação funcionou.

Transforme crons em timers, use RandomizedDelaySec para espalhar carga e WantedBy/After para ordenar tarefas. Guia prático: migrar cron para systemd timers.

Monitore disco/CPU/memória com Prometheus+Grafana; veja configurar Prometheus e Grafana.

  • Separe janelas: logrotate/compressão, VACUUM/ETL e backup.
  • Limite de concorrência por host: no máximo um job pesado.
  • Alertas para latência de disco, swap em uso e fila de I/O.
  • Revise decisões após 1–2 ciclos de backup com dados reais.

Quando o problema é o disco da VPS (limites do provedor)

Alguns volumes têm desempenho que varia por burst/IOPS provisionados. Se o burst esgota, a latência sobe até para cargas leves. Nesse caso, suavizar I/O ajuda, mas entenda o teto do provedor.

Veja visão geral de limites de discos em nuvem: Amazon EBS e Google Persistent Disk performance.

  • Se o burst estável do disco for baixo, aumente a janela (–bwlimit) para espalhar escrita.
  • Evite múltiplos jobs de I/O simultâneos; serialize backups e compressões.
  • Considere separar disco de dados e disco de backup temporário, quando possível.

Perguntas frequentes

Alta de swap significa falta de RAM?

Nem sempre. Em picos de cache e compressão, o kernel pode trocar páginas menos usadas para swap mesmo com RAM disponível, dependendo da swappiness e da pressão de writeback. Ajustar swappiness, reduzir concorrência e limitar I/O costuma estabilizar sem aumentar memória.

ionice e nice resolvem sozinhos?

Ajudam a dar prioridade aos serviços críticos quando há disputa, mas não reduzem dados processados. Combine com limites de banda (bwlimit), redução de concorrência, exclusões e compressão mais leve para suavizar o perfil de I/O do backup.

É seguro manter LVM snapshot por horas?

Quanto mais tempo o snapshot fica ativo, mais blocos COW são gravados, elevando I/O e risco de encher a área de snapshot. Prefira snapshots curtos, imediatamente seguidos do upload incremental. Monitore o uso do snapshot e dimensione a área COW com folga.

Devo desativar a swap para evitar lentidão?

Desativar swap pode causar OOM kills sob pico de memória. Melhor reduzir swappiness, limitar concorrência e suavizar I/O. Swap pequena e rara é aceitável. Se a swap é usada constantemente, investigue consumo de memória e ajuste serviços.

Qual compressão usar no backup noturno?

zstd em nível moderado costuma oferecer boa taxa com menos CPU e I/O por byte em comparação a gzip alto. Ajuste o nível e a concorrência para manter latência de disco baixa durante a janela de backup.

rsync local precisa de --bwlimit?

Mesmo local, o rsync pode varrer metadados intensamente e aquecer cache de página, afetando outros processos. Usar --bwlimit e prioridade baixa (ionice/nice) ajuda a espalhar o trabalho e reduzir a competição por disco.

Quer estabilizar seus backups noturnos sem estourar I/O?

Converse sobre seu cenário. Podemos revisar seu job de backup, aplicar limites de I/O, ajustar swappiness e orquestrar timers, mantendo o custo atual de disco.

Fale sobre seu caso

Veja também