O que fazer quando o VPS está com throttling (2026): como identificar limitação de CPU, disco e rede

• Quanto mais você pressiona sua carga de trabalho, mais as métricas de recursos sobem junto, até encher → mais parece saturação normal
• Sua carga de trabalho quer continuar subindo, mas o desempenho fica preso em um valor fixo → mais parece throttling

Este também é o núcleo de todo o artigo:

Primeiro prove que você está sendo limitado, e só depois decida se deve atualizar, migrar ou reclamar com o provedor.

Por exemplo:

• A CPU fica presa por muito tempo em uma linha de base fixa
• O IOPS de disco sempre para em um teto parecido
• A vazão de rede fica presa por muito tempo em um nível fixo

A "redondeza" em si já é um sinal muito forte.

Isso se parece muito com o comportamento depois que os créditos acabam:

• No começo há burst
• Depois você é devolvido à linha de base

Por exemplo:

• O uso de CPU não parece alto
• Mas os tempos de resposta começam a oscilar
• As filas aumentam
• A sensação de travamento do sistema é evidente

Nesse momento não basta olhar só para %cpu; é preciso olhar steal, iowait, créditos e o teto de vazão.

A oscilação normal não será tão redonda toda vez. Bater repetidamente no mesmo teto geralmente indica que a restrição é "regrada".

Em cenários de VPS virtualizado, steal time é um sinal muito importante.

Ele significa que:

• Sua CPU virtual queria executar
• Mas o host cedeu a fatia de tempo para outra VM

Isso geralmente indica contenção na camada do host, e não que seu programa esteja esgotando a CPU.

top
vmstat 1
mpstat -P ALL 1

Foque em:

• st / %st

• %st próximo de 0: normalmente normal
• %st persistentemente alto e evidente: significa que você está esperando o host liberar CPU

Se sua carga de trabalho não é pesada mas %st continua alto, isso não é algo que "otimizar o código" consiga resolver completamente.

Máquinas como a série T da AWS e a série B do Azure não são feitas para "ir sempre a toda velocidade", mas sim para:

• Acumular créditos normalmente
• Explodir quando necessário
• Voltar à linha de base quando os créditos acabam

O erro de diagnóstico mais típico aqui é:

"Por que o teste de estresse foi tão forte nos primeiros 10 minutos e depois de repente não deu mais?"

Pode não ser que a máquina esteja quebrada, mas que você esgotou o burst.

• O desempenho é normal ou até muito bom no começo
• Após pressão sustentada cai para um nível fixo
• Os créditos se aproximam de 0 no monitoramento do provedor
• A carga de trabalho não terminou, mas o teto de CPU parece ter sido tampado

• us / sy muito altos
• A vazão sobe quando a carga sobe
• Só que no final o poder de processamento real é o limite

Nesse caso parece mais "a máquina não dá conta" do que "a plataforma está te segurando".

Comando comum:

vmstat 1
iostat -x 1

Foque em:

• %wa
• %util
• await

iowait alto não significa necessariamente throttling.

Ele só indica que:

• A CPU está esperando I/O

Quanto ao motivo da espera, pode ser:

• O disco é realmente lento
• A fila é longa demais
• A latência do armazenamento é alta
• O IOPS está limitado por cota

• Você continua aplicando pressão, mas o IOPS não cresce mais
• A latência começa a subir de forma evidente
• %util muito alto, mas a vazão não sobe
• Vários resultados de fio batem no mesmo teto

fio --name=randwrite-test     --ioengine=libaio     --direct=1     --rw=randwrite     --bs=4k     --size=1G     --iodepth=64     --numjobs=4     --runtime=120     --time_based     --group_reporting

O que você precisa olhar não é "quanto rodou em uma única vez", mas:

• Se o IOPS continua crescendo quando iodepth e numjobs aumentam
• Se a latência p95 / p99 piora de repente
• Se o que trava é a leitura/escrita aleatória ou a vazão sequencial

Se você aplica pressão continuamente e o resultado sempre fica preso em um limite parecido, parece muito uma cota de I/O ou limitação de velocidade da camada de armazenamento.

## 服务端
iperf3 -s

## 客户端
iperf3 -c <server_ip> -R

Se você suspeitar que um único fluxo não é preciso, também pode testar com múltiplos fluxos.

• Um único fluxo fica preso em um teto fixo
• Múltiplos fluxos também não superam esse teto
• Testes em horários diferentes batem no mesmo nível
• Anunciado como 1Gbps, mas na prática parece limitado a um valor mais baixo de forma sustentada

• Rota ruim
• Perda de pacotes
• Congestionamento no horário de pico
• O destino em si é lento
• Problemas do ISP local

Por isso a camada de rede sempre deve ser analisada em duas etapas:

1. Qualidade da rota
2. Se o teto de vazão bate na parede de forma regrada

Se só oscila no horário de pico, parece mais congestionamento; se fica preso no mesmo nível a qualquer hora, parece mais uma restrição.

Algumas não são throttling no nível da instância, mas restrições de política do serviço, como:

• Limitação de velocidade após ultrapassar o tráfego mensal
• Portas específicas / protocolos específicos limitados
• Bloqueio padrão da porta 25 de saída em cenários de e-mail

Isso não é "preempção do host", mas uma restrição na camada de políticas do provedor.

Se seu aplicativo realmente esgota a CPU, isso se chama saturação de recursos, não throttling.

Rota ruim, horário de pico, perda de pacotes e destino lento podem fazer você sentir "como se estivesse limitado".

Pode ser simplesmente que o armazenamento do host esteja muito ocupado, ou que seu padrão de acesso em si não seja amigável.

A pontuação é só um sintoma, não uma conclusão. Você precisa combinar:

• Métricas
• Linha do tempo
• Modelo de cotas
• Resultados reproduzidos várias vezes

para julgar em conjunto.

Olhe:

• Uso de CPU
• load
• Memória
• iowait
• Vazão de rede

Se a carga de trabalho em si já é pesada, não se apresse em culpar a plataforma.

Foque em:

• Se a CPU cai para uma linha de base fixa
• Se o IOPS bate na parede
• Se a vazão sempre fica presa em um nível fixo

Foque em:

• steal time
• créditos
• O painel de monitoramento do provedor

• CPU: veja o comportamento após teste de estresse sustentado
• Disco: use fio
• Rede: use iperf3

Não rode só uma vez, mas sim:

• Em horários diferentes
• Com níveis de pressão diferentes
• Para ver se sempre bate no mesmo teto

Se confirmar que é throttling, então considere:

• Aumentar a especificação da instância
• Trocar para um modelo não burstable
• Migrar de provedor/datacenter
• Contatar o provedor com evidências para conversar

• Verifique se os créditos acabaram
• Troque para um modelo não burstable
• Evite rodar tarefas de CPU alta por muito tempo em instâncias compartilhadas do tipo burst

• Veja o tipo de disco atual e o modelo de IOPS
• Verifique se é necessário armazenamento de especificação maior
• Evite colocar bancos de dados com muita escrita aleatória em discos compartilhados de baixa configuração

• Veja se a descrição do plano tem políticas de tráfego/banda/portas
• Diferencie link ruim de limitação regrada
• Para cargas de alta vazão, tente não usar planos "baratos mas com muitas políticas de rede"

Guarde evidências antes de abrir um ticket.

Não diga apenas:

• "Sinto que ficou mais lento"

Mas leve:

• Períodos de tempo
• Capturas de tela do monitoramento
• Saídas de fio / iperf3 / vmstat / iostat
• Resultados de várias repetições

Assim fica mais difícil para o provedor te despachar com uma resposta padrão.

Sim. Por exemplo, quando o steal time é alto, os créditos acabam ou a espera de I/O é grave, a experiência será ruim, mas o uso de CPU que você vê pode não ser exageradamente alto.

Veja se existe um teto regrado. A saturação real parece mais bater na parede de forma linear; o throttling parece mais ficar preso em um limite redondo.

Não. A pontuação é só uma pista, não uma conclusão. É preciso julgar junto com steal, créditos, iowait e os resultados de repetição de fio/iperf3.

Primeiro guarde as evidências e os resultados de monitoramento, e depois decida se atualiza, troca de modelo, migra ou leva os dados para conversar com o provedor.