Detecção de overselling em VPS: Steal Time e queda abrupta do Cache de disco na prática

O overselling é um fenômeno comum na indústria de VPS, mas o overselling excessivo pode afetar significativamente o desempenho. Este artigo oferece um conjunto de métodos práticos de detecção baseados em duas dimensões: CPU Steal Time e queda abrupta do Cache de disco, ajudando você a determinar se o VPS está excessivamente oversold e apresentando estratégias de resposta.

Atualizado 2026-08-10 · CloudWorth

Overselling em VPSSteal TimeCache de discoTeste de desempenhoServidor em nuvemCloudWorthOverselling VPSBenchmark VPS

Ao monitorar continuamente o CPU Steal Time e a queda abrupta do Cache de disco, juntamente com testes de estresse, você pode identificar efetivamente VPS com overselling excessivo, agir rapidamente para evitar perdas e otimizar sua estratégia de implantação.

Por que é necessário detectar a superprovisão de VPS?

VPS (Servidor Virtual Privado) é derivado da divisão de recursos de servidores físicos com base em tecnologia de virtualização. Superprovisão (Overselling) refere-se à prática em que a soma dos recursos virtuais vendidos pelo provedor ultrapassa o limite físico dos recursos, sendo uma prática comum na indústria de IDC. Uma superprovisão razoável pode reduzir custos, mas uma superprovisão excessiva pode levar à disputa por CPU, aumento drástico da latência de I/O de disco e até mesmo ao problema de "ruído de vizinhos".

Como usuários, não podemos ver diretamente a configuração de superprovisão do provedor, mas podemos inferir indiretamente por meio dos padrões de variação das métricas do sistema. Entre eles, CPU Steal Time e queda abrupta de cache de disco são dois sinais mais diretos e eficazes.

Métrica Principal 1: CPU Steal Time (tempo roubado)

O que é Steal Time?

Em sistemas Linux, o campo steal ou st representa a porcentagem de tempo de CPU da máquina virtual que foi tomada pelo hipervisor (máquina hospedeira). Quando os recursos de CPU física são insuficientes, o hipervisor força o agendamento, fazendo com que sua VPS não consiga obter o tempo de CPU que lhe é devido, e esse tempo de espera é o Steal Time.

Steal Time muito alto significa que sua VPS está “esperando na fila pela CPU”, com desempenho prejudicado.

Como verificar o Steal Time?

Use o comando top e verifique o valor st na linha %Cpu(s):

top -n 1 | grep '%Cpu'

Exemplo de saída:

%Cpu(s):  5.1 us,  2.0 sy,  0.0 ni, 92.0 id,  0.0 wa,  0.9 hi,  0.0 si,  0.0 st

Aqui, st é o Steal Time. Você também pode usar o comando vmstat, observando a coluna st (requer privilégios de root):

vmstat 1 5

Limiares de avaliação

• Sustentado acima de 5%: indica que a CPU do host está sobrecarregada e sua VPS começa a ser afetada.
• Picos acima de 10%: possível queda perceptível de desempenho, especialmente para tarefas que exigem computação contínua.
• Exceder 20% por um longo período: é um sinal de superprovisionamento severo; considere trocar de provedor.

Simulação de teste de estresse

Observar o Steal Time apenas em estado ocioso pode não ser evidente. Recomenda-se usar a ferramenta stress para simular carga de CPU e observar o comportamento do Steal Time sob pressão:

# 安装stress（Debian/Ubuntu）
apt install stress -y

# 满载所有CPU核心60秒
stress --cpu $(nproc) --timeout 60 &

# 同时运行top观察
sleep 5 && top -d 2 | grep '%Cpu'

Se o valor de st disparar em estado de carga total, significa que os recursos físicos da CPU estão sendo amplamente tomados por outras VPS, indicando superprovisionamento severo.

Métrica principal 2: Precipício do Cache do Disco

O que é o precipício de cache de disco?

O desempenho de I/O do disco de um VPS depende fortemente do cache na memória do host. Quando há cache hit, a velocidade de leitura/escrita é extremamente rápida; quando há cache miss (especialmente em rajadas de leitura/escrita), a velocidade do disco físico se torna o gargalo, e o desempenho cai várias ordens de grandeza, formando um "precipício".

Se houver muitos VPS rodando no host, a proporção de cache disponível para cada VPS diminui, tornando mais fácil desencadear o efeito precipício.

Como detectar a queda abrupta do cache de disco?

Use hdparm ou dd para testar a velocidade de leitura/escrita do disco e observe as flutuações de velocidade.

1. Teste simples:

# 写入测试（512MB文件）
time dd if=/dev/zero of=testfile bs=1M count=512 conv=fdatasync

# 读取测试（清缓存后）
echo 3 > /proc/sys/vm/drop_caches   # 需要root，清Page Cache
time dd if=testfile of=/dev/null bs=1M count=512

Registre a diferença de velocidade entre o primeiro teste e os testes repetidos. Se a velocidade de escrita inicial for muito rápida (devido ao cache de escrita) e cair drasticamente em seguida, isso indica que a capacidade do cache é limitada e a disputa é intensa.

2. Usando fio para um teste mais preciso:

# 安装fio（Debian/Ubuntu）
apt install fio -y

# 4K随机写测试，持续60秒
fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=4k --size=1G --numjobs=4 --iodepth=16 --runtime=60 --time_based --direct=1 --group_reporting

Observe atentamente a distribuição de lat (usec) e iops. Se a curva de latência apresentar tremores intensos, isso indica que o desempenho do disco físico é extremamente instável quando o cache não é atingido.

Método para detectar queda abrupta

Execute múltiplos testes de leitura/escrita de pequenos arquivos em sequência, registrando o IOPS ou a taxa de transferência de cada um. Por exemplo:

for i in {1..10}; do
  dd if=/dev/zero of=testfile bs=1M count=64 oflag=direct 2>&1 | tail -1
  rm testfile
done

Se a velocidade cair subitamente de centenas de MB/s para dezenas de MB/s, e isso ocorrer com frequência, pode-se concluir que há uma queda abrupta do cache do disco.

Outros métodos auxiliares de detecção

1. Disponibilidade de memória

O superprovisionamento também pode ocorrer na memória. Use free -h para observar a memória disponível. Se ela estiver frequentemente abaixo de 10% e o consumo de swap for significativo, isso indica que a memória também está superprovisionada.

2. Teste de concorrência de vizinhos

Tente executar testes de estresse em períodos específicos (como horário de pico noturno), comparando o Steal Time com períodos ociosos. Se as métricas piorarem significativamente no horário de pico, isso reforça ainda mais a hipótese de sobrevenda.

3. Monitoramento de longo prazo

Recomenda-se usar sar ou atop para registrar continuamente as métricas do sistema, por pelo menos uma semana. Observe as flutuações de desempenho em horários fixos semanais.

# Usar sar para registrar o histórico da CPU (requer sysstat instalado)
sar -u 60 > /tmp/cpu_history.log &

Como lidar com o overselling?

• Evite horários de pico: Para negócios não em tempo real, agende as tarefas para horários de baixa demanda.
• Adicione cache: Adicione caches como Redis na camada de aplicação, reduzindo a dependência de I/O de disco subjacente.
• Troque de provedor: Se o Steal Time permanecer alto por muito tempo, migre decisivamente para um provedor de nuvem que não tenha overselling ou que tenha uma proporção menor de overselling.
• Escolha planos de alto desempenho: Alguns provedores oferecem VPS com "CPU exclusiva" ou "overselling limitado", com custo maior, mas desempenho mais estável.

Recomendamos usar ferramentas profissionais de detecção para avaliar antes da compra. Você pode obter o script de detecção automatizado na página de obtenção de instruções de detecção e gerar um relatório detalhado de overselling com um clique.

Conclusão

A detecção de overselling de VPS não é uma operação única, mas requer monitoramento contínuo. Através dos dois indicadores principais, Steal Time e queda de cache de disco, combinados com testes de estresse e registros de longo prazo, você pode avaliar efetivamente se o VPS atual está com overselling excessivo, tomando assim a decisão de atualizar ou migrar.

Lembre-se, nenhum indicador único pode determinar 100% o overselling, mas combinar dados de múltiplas dimensões é suficiente para você enxergar a verdade.

Espero que este guia prático ajude você a evitar armadilhas ao escolher um VPS. Se você está considerando mudar de provedor, é recomendável testar o servidor atual usando os métodos deste artigo e depois comparar com os resultados do provedor-alvo.