Não estou escrevendo isto como uma avaliação negativa da REGXA, nem tentando dizer a alguém se deve ou não comprar um VPS deles. É simplesmente um dos meus dias como desenvolvedor.
Migrei uma carga normal para um VPS KVM com 2 vCPU, 2 GB de RAM e 60 GB NVMe. O Nginx estava funcionando. O backend também. Mesmo assim, a máquina se comportava como se estivesse extremamente sobrecarregada: requisições se acumulavam, operações TLS ficavam lentas, conexões permaneciam abertas e algumas requisições acabavam retornando HTTP 504 depois de mais de dois minutos.
A contabilização da CPU mudou a investigação
Minha primeira hipótese era óbvia: alguma coisa dentro do VPS estava consumindo o processador. Então executei mpstat.
Average CPU steal: 92.58%
CPU 0 steal: 90.62%
CPU 1 steal: 94.57%
CPU user: 4.02%
CPU system: 1.47%
CPU iowait: 0.41%
CPU idle: 0.53%As amostras individuais mostravam repetidamente algo em torno de 89–98% de steal. A pressão de CPU também estava extrema:
CPU PSI some avg10: 79.47
CPU PSI some avg60: 75.32
CPU PSI some avg300: 76.31
Load average: 5.85 / 5.75 / 5.73Era uma máquina com apenas dois vCPU. O Linux tinha processos runnable esperando CPU. O número importante não era o uso normal do processador pela aplicação, e sim %steal.
Uso alto de CPU e CPU steal são problemas diferentes
Se minha aplicação estivesse realmente consumindo o processador, eu esperaria valores altos de user ou system. Em vez disso, o VPS parecia aproximadamente assim:
user: 4%
system: 1%
steal: 93%CPU steal é o tempo em que uma CPU virtual está pronta para executar, mas o hypervisor não a agenda. Quando digo que o VPS estava perdendo tempo de CPU, é nesse sentido técnico de virtualização. Não posso provar que a REGXA deliberadamente realocou para outro cliente núcleos físicos que fossem exclusivamente meus, nem inferir intenção a partir de métricas do guest. O que posso provar é que o guest tinha trabalho pronto para executar e repetidamente não recebia tempo de scheduling de CPU.
Removi todo o tráfego de produção
Ainda havia uma objeção razoável: talvez minha própria carga estivesse causando o problema. Então removi essa variável. Levei o workload ativo para outro lugar, parei o tráfego de produção para esse VPS, deixei as filas esvaziarem e repeti a medição.
Average CPU steal: 94.17%
CPU 0 steal: 95.56%
CPU 1 steal: 92.83%
CPU user: 1.95%
CPU system: 0.59%
CPU iowait: 0.59%
CPU idle: 2.18%O resultado piorou. Amostras individuais de vmstat continuavam mostrando 91–98% de steal, e até 15 processos runnable esperavam CPU. A combinação mais importante era:
user: 1.95%
system: 0.59%
steal: 94.17%Minhas aplicações praticamente não faziam nada, mas a VM ainda perdia quase todo o tempo de scheduling. A carga normal de produção deixou de ser uma explicação plausível.
Até localhost ficou absurdamente lento
Também testei HTTPS via 127.0.0.1, removendo da equação DNS público, meu ISP, distância geográfica e o caminho de rede externo.
Com tráfego, quatro de dez tentativas HTTPS para localhost falharam durante o TLS handshake. As requisições bem-sucedidas levaram 29,30, 22,77, 12,25, 11,87, 11,12 e 9,40 segundos. Alguns TLS handshakes, sozinhos, levaram cerca de nove segundos.
Depois de remover o tráfego de produção, localhost melhorou, mas continuou instável: 0,061, 0,745, 0,830, 0,873, 1,010, 1,117, 1,121, 2,188 e 3,355 segundos. A mesma operação local podia levar cerca de 61 ms em uma tentativa e mais de 3,3 segundos na seguinte.
O restante da stack mostrava as consequências
Em determinado momento observei cerca de 450 conexões established, 122 conexões orphaned, 110 FIN-WAIT-1 e 33 CLOSE-WAIT. A listen queue do backend local chegou a aproximadamente 14–15, enquanto a de HTTPS chegou a cerca de 40.
O Nginx registrou HTTP 504 após 142,857, 138,902, 135,064, 129,819 e 128,657 segundos. Outras requisições permaneceram abertas por cerca de 67–130 segundos. Também vi secure-connect timeouts em torno de 35–41 segundos, database network timeouts e operações TLS atrasadas.
Separadamente, esses sintomas poderiam parecer problemas distintos de Nginx, banco de dados, rede ou backend. Mas aumentar timeouts não cria o tempo de CPU que o hypervisor não está agendando.
RAM e disco não explicavam o problema
O VPS ainda tinha cerca de 1,0–1,1 GiB de RAM disponível, praticamente nenhum uso de swap, nenhum evento OOM e nenhuma atividade do OOM killer. O filesystem estava apenas cerca de 20% ocupado, com aproximadamente 44 GB livres. O I/O wait ficou abaixo de 1% durante as medições importantes de CPU.
A memória não estava esgotada, o disco não estava cheio e minhas aplicações não estavam consumindo a CPU ausente. A métrica dominante continuava sendo %steal.
Um VPS KVM saudável parecia completamente diferente
Executei o mesmo tipo de diagnóstico em outro VPS KVM que estava atendendo tráfego normal:
Average CPU steal: 0.02%
CPU idle: 87.86%
CPU PSI avg10: 0.29
CPU PSI avg60: 0.63
CPU PSI avg300: 0.49
Load average: 0.47 / 0.33 / 0.14As dez requisições HTTPS localhost foram concluídas em aproximadamente 37–69 ms. Mais tarde medi outro VPS de produção realmente ocupado e encontrei 61,71% de user CPU, 5,08% de system CPU, 24,09% idle e apenas 0,13% de steal.
Essa é a distinção que considero importante hoje. Um VPS pode estar ocupado porque meu software realmente usa o processador. Isso é muito diferente de um guest passar mais de 90% do tempo de CPU medido esperando o hypervisor.
A REGXA acabou confirmando a contenção na infraestrutura
De dentro da VM eu podia medir o guest, mas não enxergar o host físico, a configuração do scheduler, as CPU quotas ou as VMs vizinhas. A REGXA podia.
O suporte acabou me informando que o VPS estava hospedado em shared CPU infrastructure, que os recursos de CPU eram compartilhados por várias máquinas virtuais e que a performance podia variar conforme a carga do nó físico. Também disseram que a infraestrutura de Frankfurt estava passando por uma demanda especialmente alta e atribuíram explicitamente meu CPU steal elevado a resource contention on the underlying infrastructure.
Eles também afirmaram que não podiam alterar CPU quotas ou políticas de scheduling nem dedicar recursos de CPU adicionais àquele VPS compartilhado na infraestrutura atual. A solução técnica proposta foi migrar o VPS para um local com menor utilização.
Foi difícil conciliar essa explicação com a linguagem que eu tinha visto sobre dedicated CPU cores e guaranteed resources. Não consigo ver a configuração exata do host, então não posso dizer se o mecanismo imediato era CPU overcommitment, quotas, scheduler weighting, throttling ou uma combinação. Também não posso provar intenção. Não preciso: o Linux mostrou 92–94% de steal de forma sustentada e a própria REGXA atribuiu esse valor elevado à contenção em sua infraestrutura compartilhada.
Conseguir o reembolso também exigiu insistência
Depois que o problema de infraestrutura ficou claro, eu não queria continuar migrando o VPS e testando outros nós. Queria cancelar o serviço e receber meu dinheiro de volta.
Inicialmente me ofereceram apenas uma parte do valor, e o reembolso proposto seria creditado no saldo da minha conta REGXA em vez de voltar para o cartão utilizado no pagamento. Para mim, crédito interno do provedor não equivale a reembolso quando estou tentando deixar o serviço.
Por isso continuei respondendo e pedindo que 100% do pagamento fosse devolvido ao método de pagamento original. No fim, a REGXA aceitou e devolveu o valor total ao método de pagamento original, descrevendo o reembolso integral como uma exceção.
Reconheço que no final devolveram tudo. Mas ter de continuar insistindo na resolução financeira depois de o suporte já ter reconhecido a contenção de infraestrutura também faz parte da minha experiência.
A lição que ficou
O erro mais fácil seria continuar otimizando minha aplicação. Eu poderia mudar o Nginx, aumentar timeouts, reduzir concurrency, adicionar retries, investigar MongoDB ou reescrever o backend. Algumas dessas mudanças talvez alterassem sintomas específicos. Nenhuma responderia à pergunta importante: por que o CPU steal estava acima de 90%?
Hoje eu não paro depois de confirmar que SSH funciona, Nginx inicia e um health endpoint devolve 200. Em um VPS novo também verifico %user, %system, %iowait, %idle, %steal, CPU PSI, run queue e latência localhost.
E quando algo parece suspeito, removo o workload e meço novamente. Neste caso, isso produziu o resultado mais claro de todo o incidente:
CPU user: 1.95%
CPU system: 0.59%
CPU steal: 94.17%Não estou dizendo que todo VPS da REGXA se comporta assim. Testei um VPS e documentei o que aconteceu com aquela máquina. Mas naquele servidor as evidências eram excepcionalmente claras: minhas aplicações quase não consumiam CPU, enquanto o Linux mostrava que a maior parte do tempo de CPU virtual estava sendo perdida esperando o scheduling do hypervisor. Mais tarde, a REGXA atribuiu exatamente esse comportamento à contenção de recursos em sua infraestrutura compartilhada.
É por isso que estou documentando a experiência. Não como uma nota ou recomendação, mas simplesmente como um dos meus dias como desenvolvedor — e como uma métrica que nunca mais vou ignorar em um VPS.