Detecte overcommitment em EC2 de nuvem pública com Steal Time
Duas réguas revelam a verdade sobre o overcommitment
Steal Time alto indica CPU superprovisionada; com a queda abrupta de cache e a taxa de prêmio, você pode obter evidências e reivindicar seus direitos.
Duas réguas para overselling
Para determinar se uma EC2 de nuvem pública está sobrecarregada (overselling), não se pode olhar apenas para a taxa de idle da CPU, pois o idle dentro da máquina virtual não significa que o host físico não está ocupado. A primeira régua é o Steal Time (steal%), que informa diretamente: o tempo de CPU que deveria ser destinado a você foi silenciosamente desviado pelo host para um vizinho problemático. Quando o steal% ultrapassa consistentemente 10%, basicamente pode-se suspeitar que o host está em estado de overselling.
Mas olhar apenas para o steal não é suficiente — algumas instâncias (como as da série t da AWS) têm um mecanismo de créditos de CPU; durante picos, um steal alto pode ser apenas esgotamento de créditos. Então entra a segunda régua: o despenhadeiro de Cache de Disco. Hosts com overselling geralmente também suportam muitas solicitações de IO; quando você usa fio para testar leitura aleatória, a taxa de hit do cache de páginas ou a latência podem cair vertiginosamente, o que coincide fortemente no tempo com o steal da CPU. As duas réguas se confirmam mutuamente para formar evidência completa.
Quer começar a detectar rapidamente? Anteriormente, preparamos um script de detecção de overselling para servidores em nuvem, que pode gerar diretamente as métricas de steal e cache, ajudando você a evitar armadilhas antes da compra.
Teste e coleta de evidências em instâncias
Fizemos um teste comparativo entre o Alibaba Cloud ECS g9i e o AWS EC2 m7i, ambos recém-lançados. O script de carga foi fixado em: stress-ng --cpu 4 --timeout 300, enquanto o mpstat amostrava o steal% a cada 5 segundos; em seguida, executamos o fio para leitura aleatória de 4K, registrando IOPS e latência p99.
# CPU steal 采样
mpstat -P ALL 5 > steal.log &
# 磁盘 cache 断崖测试
fio --name=cachetest --rw=randread --bs=4k --size=1G --runtime=120 --iodepth=32Nos testes, durante o horário de pico diurno, o steal do g9i atingiu uma média de 12,4%, com pico de 18,1%. Ao mesmo tempo, a latência p99 do fio saltou de 0,8 ms para 12 ms, evidenciando um claro "cache cliff". No mesmo período, o steal do m7i permaneceu estável abaixo de 2%, com latência suave. Observação: em instâncias burst de baixa especificação, como a série t, é normal o steal ultrapassar ocasionalmente 10%, mas se instâncias otimizadas para computação, como a série m e a g9i, excederem consistentemente esse limite, é uma prova de overcommitment.
Pontos-chave para coleta de evidências: registre o timestamp de cada amostragem, o ID da instância e a versão da imagem, e capture os dados brutos do CloudWatch / CloudMonitor. Esses logs e capturas de tela são as principais provas para o ticket de suporte posterior.
Taxa de prêmio e defesa de direitos
O mais difícil de perceber no superprovisionamento é: você paga um prêmio, mas recebe apenas poder computacional incompleto. Sob a perspectiva do FinOps, o custo-benefício real = preço unitário ÷ tempo efetivo de CPU. O tempo útil pode ser estimado com a fórmula: núcleos-hora úteis = nº de vCPUs × (1 - steal% médio) × duração.
Exemplo: g9i com preço unitário de 1,2 yuan/hora (4 vCPUs), se o steal médio for 15%, os núcleos-hora úteis reais são apenas 3,4 vCPU·h, o que equivale a um aumento de 17,6% no custo por vCPU efetiva. Comparando com o m7i de mesma especificação sem superprovisionamento, a taxa de prêmio acaba sendo invertida pelo "imposto do superprovisionamento" — isso geralmente significa que você pagou mais caro e recebeu um serviço pior.
Após coletar evidências, a defesa de direitos não se baseia apenas em reclamar de "lentidão". Prepare um PDF contendo: gráfico de série temporal da steal%, saída do fio mostrando a queda abrupta de cache, tabela comparativa com outras instâncias de mesma especificação e o cálculo detalhado da taxa de prêmio. Ao abrir o ticket, exija explicitamente "redução de configuração ou reembolso da diferença com base no poder computacional efetivo medido". A Alibaba Cloud e a AWS geralmente não reconhecem superprovisionamento, mas diante de dados concretos, essas empresas podem oferecer créditos ou compensação na forma de upgrade, citando "contenda de recursos no host". Antes de comprar instâncias em nuvem, meça com duas réguas para não deixar que um valor premium compre um serviço superprovisionado.
FAQ
Como usar o Steal Time para identificar overcommitment em EC2?
Execute uma carga de trabalho para manter a CPU ocupada; se o valor de steal ultrapassar 5% continuamente, há overcommitment.
Quais problemas de desempenho o overcommitment pode causar?
A disputa pela CPU causa oscilações de desempenho e aumento de latência, mais evidentes nos horários de pico.
Como obter evidências de overcommitment em nuvem pública?
Registre a curva de steal e a queda abrupta de cache, salve capturas de tela de monitoramento e registros de chamados, e exporte um PDF para arquivamento.
Como a taxa de prêmio reflete o custo-benefício do overcommitment?
Compare a perda de desempenho com o percentual de desconto; se o steal for alto e o desconto for pequeno, o custo-benefício é baixo e você pode solicitar compensação.
Como abrir um chamado de reclamação para problemas de overcommitment?
Anexe as evidências de anormalidade de steal e cache, junto com o PDF, e solicite redução de configuração ou reembolso; se necessário, faça uma reclamação formal.