Não estou escrevendo isto como uma avaliação negativa da AVA Hosting.
É apenas um daqueles dias normais de trabalho como desenvolvedor: um servidor se comporta mal, as explicações óbvias não encaixam e, no fim, o Linux mostra o que realmente está acontecendo.
Eu tinha um pequeno VPS KVM da AVA Hosting com:
1 vCPU
2 GB RAM
25 GB NVMeUma carga normal de produção estava rodando nele. O Nginx estava ativo. O backend estava ativo. Havia memória disponível. O disco não estava cheio.
Mesmo assim, o servidor não conseguia acompanhar a carga.
Então fiz uma observação passiva de 60 segundos sob tráfego normal de produção. Sem stress test, sem flood HTTP sintético e sem benchmark de disco.
O resultado:
vCPU count: 1
Average CPU user: 52.52%
Average CPU system: 8.07%
Average CPU softirq: 6.69%
Average CPU steal: 32.73%
Average CPU iowait: 0.00%
Average CPU idle: 0.00%
Maximum runnable queue: 11O número decisivo foi 32,73% de CPU steal. A partir daí, o diagnóstico mudou completamente.
Por que isso me surpreendeu
A AVA Hosting atualmente anuncia seu produto VPS com a frase “Guaranteed resources — no sharing”. As páginas de VPS também descrevem a alocação de vCPU como fixa ou dedicada e dizem que o desempenho não deveria ser afetado por outros clientes. No material sobre Linux VPS, a AVA vai além: uma carga CPU-intensive de outro tenant no mesmo host não poderia introduzir steal time na sua instância. Outra página afirma que o CPU steal é eliminado no nível do hypervisor.
São afirmações muito específicas. Não era apenas uma página listando 1 vCPU sem explicar o modelo de alocação de CPU. A AVA anunciava explicitamente proteção contra exatamente o tipo de contenção de CPU que o Linux parecia estar relatando dentro da minha VM.
O que significa CPU steal
steal é uma métrica normal de CPU do Linux em ambientes virtualizados. Ela representa o tempo em que o guest tinha trabalho executável, mas a CPU virtual não estava realmente rodando.
Isso é diferente de minha aplicação simplesmente consumir toda a CPU disponível. Se eu tivesse visto aproximadamente 100% em user/system, 0% de steal e 0% de idle, teria concluído que a carga simplesmente precisava de mais poder de processamento.
Em vez disso, aproximadamente um terço da contabilização de CPU aparecia como steal.
De dentro do guest eu não consigo ver o hypervisor da AVA. Não sei a carga do nó físico, o número de VMs vizinhas, a política de CPU pinning nem a taxa de overcommit. O que consigo ver é o que o Linux relatou à minha VM: a vCPU repetidamente não estava rodando enquanto havia trabalho esperando para ser executado.
Não foi um pico de um segundo
Uma única amostra ruim de CPU não seria suficiente para me convencer. Por isso medi a máquina continuamente durante 60 segundos. Não executei stress test, flood HTTP sintético nem benchmark de disco.
As amostras por segundo se repetiam assim:
%usr %sys %soft %steal %idle
53.54 10.10 5.05 31.31 0.00
56.44 6.93 5.94 30.69 0.00
51.52 7.07 6.06 35.35 0.00
55.45 6.93 5.94 31.68 0.00
51.49 8.91 5.94 33.66 0.00
52.53 7.07 7.07 33.33 0.00
52.48 6.93 7.92 32.67 0.00Perto do fim da observação, o mesmo padrão continuava:
50.98 10.78 6.86 31.37 0.00
48.48 8.08 9.09 34.34 0.00
55.00 5.00 7.00 33.00 0.00A média completa foi:
user: 52.52%
system: 8.07%
softirq: 6.69%
steal: 32.73%
iowait: 0.00%
idle: 0.00%Portanto, não era uma breve anomalia de scheduling. Durante a maior parte do minuto, o steal ficou em torno de 30% ou mais, enquanto o CPU idle permaneceu em zero.
Para dar uma noção, 32,73% de um minuto correspondem a cerca de 19,64 segundos. Isso não significa que o VPS ficou congelado durante 19,64 segundos consecutivos; pequenos intervalos nos quais a vCPU não foi agendada se acumularam até aproximadamente esse valor.
O backend não conseguia recuperar o atraso
O problema de CPU também aparecia no nível da aplicação. Antes da observação, a fila de escuta do backend era:
Recv-Q: 168
Send-Q: 511Depois de 60 segundos:
Recv-Q: 166
Send-Q: 511Os números exatos não são o ponto principal. O importante é que a fila praticamente não diminuiu. A aplicação teve um minuto inteiro para recuperar o atraso e continuou para trás.
Também havia muitas conexões em CLOSE-WAIT. Eu não culparia o host apenas por esse estado, porque ele também pode resultar do gerenciamento de conexões pela própria aplicação. Mas o quadro geral era consistente:
1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not drainingO servidor estava vivo, mas não estava saudável.
RAM e disco não eram os gargalos óbvios
Também verifiquei as causas comuns. A memória:
RAM total: ~1.9 GiB
RAM available: ~959 MiB
Swap total: 2 GiB
Swap used: ~33 MiBAinda havia uma quantidade relevante de memória disponível e nenhum evento OOM evidente que explicasse o comportamento.
O sistema de arquivos:
24 GB total
14 GB used
9.4 GB available
60% usedO CPU I/O wait médio era 0.00%. Enquanto isso, a pressão de CPU permanecia perto de 99%, o load average ficava em torno de 3,5–4 em uma VM com uma vCPU e a runnable queue chegou a 11.
Todas essas medições apontavam na mesma direção: a máquina estava carente de tempo de CPU, e não claramente bloqueada por RAM ou armazenamento.
A contradição com o discurso da AVA
Esta é a parte que considero mais interessante.
A AVA diz “Guaranteed resources — no sharing”. Afirma que o desempenho não deveria ser afetado por outros clientes. O material de Linux VPS diz que outro tenant não pode introduzir steal time, e outra página afirma que o CPU steal é eliminado no hypervisor.
Meu VPS da AVA mostrou:
Average CPU steal: 32.73%De dentro da VM, eu não consigo provar exatamente por que isso aconteceu. Não posso provar overselling intencional, identificar uma carga vizinha específica nem reconstruir a configuração de CPU do host da AVA.
Também não estou dizendo que todo VPS da AVA Hosting se comporta assim. Testei um VPS.
Mas posso dizer que o comportamento que medi é muito difícil de conciliar com essas afirmações específicas de isolamento de CPU. Para este artigo, isso é suficiente.
Por que não fiz upgrade
A resposta mais óbvia teria sido comprar mais vCPUs.
Se o VPS estivesse mostrando praticamente zero steal e minha aplicação simplesmente estivesse consumindo um core inteiro, um upgrade faria sentido. Em vez disso, aproximadamente um terço do tempo de CPU observado era steal.
Eu não queria pagar por CPUs virtuais adicionais antes de entender por que uma parcela tão grande do tempo de execução da primeira vCPU já estava sendo relatada como indisponível. Por isso cancelei o VPS e pedi reembolso.
A AVA devolveu tudo rapidamente
Esta parte da experiência foi boa.
A AVA Hosting devolveu o valor integral. O reembolso foi processado rapidamente e eles não passaram dias discutindo comigo sobre as medições de CPU. Expliquei o problema, pedi meu dinheiro de volta e eles devolveram.
Eu valorizo isso.
Assim, minha experiência leva a duas conclusões separadas: o VPS que recebi tinha um problema sério de disponibilidade de CPU e a AVA tratou meu reembolso corretamente. As duas coisas são verdade.
O que aprendi com isso
Eu não avalio mais um VPS apenas por uma especificação como 1 vCPU / 2 GB RAM / NVMe / KVM. Esses números dizem o que foi provisionado, mas não dizem quão previsível será a disponibilidade de CPU sob uma carga real.
Hoje, uma das primeiras coisas que verifico em uma VM nova é:
mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60A principal lição da minha experiência com a AVA Hosting não foi que uma vCPU seja necessariamente insuficiente. Foi perceber que um processo em execução, RAM disponível e um disco aparentemente saudável podem esconder um problema completamente diferente.
No meu caso, o Linux deixou isso particularmente claro:
CPU steal: 32.73%
CPU idle: 0.00%
CPU pressure: ~99%A AVA Hosting anuncia recursos de CPU sem compartilhamento e diz que cargas vizinhas não deveriam causar steal. Meu VPS relatou algo diferente.
Eu o cancelei. A AVA devolveu todo o meu dinheiro rapidamente e sem discussão.
E foi assim que terminou esse dia de debugging.