Mais vCPUs não garantem processamento exclusivo. Compare CPU steal, tráfego e tempo de resposta para distinguir espera pelo processador físico, limites da aplicação e gargalos em outros recursos.
Se a VPS continua lenta mesmo depois de aumentar o plano, compare CPU steal, tráfego e tempo de resposta durante a lentidão. CPU steal é o tempo em que um processador virtual fica sem executar enquanto o hipervisor, a camada que gerencia máquinas virtuais, atende trabalho externo àquela VPS. Esse sinal ajuda a investigar a disponibilidade de processamento, mas não confirma sozinho disputa no provedor.
- Mais processadores virtuais não garantem núcleos físicos exclusivos.
- Steal recorrente durante a lentidão merece investigação com o provedor.
- Steal zerado não elimina limites de CPU nem disputa por outros recursos.
- Uma tarefa sequencial pode continuar lenta mesmo com mais processadores disponíveis.
- Burst acrescenta capacidade para trabalho distribuível; não corrige a VPS original.
VPS lenta mesmo depois de aumentar o plano: o que o aumento realmente mudou
VPS é um servidor virtual, e vCPU é o processador virtual apresentado ao sistema operacional. Uma vCPU não corresponde necessariamente a um núcleo físico exclusivo: essa relação depende da infraestrutura e das garantias contratadas.
Adicionar vCPUs pode permitir executar mais tarefas ao mesmo tempo, sem acelerar cada tarefa individualmente. Uma operação sequencial, que precisa terminar uma etapa antes de começar outra, pode continuar usando apenas uma vCPU por vez.
Para distinguir falta de capacidade total de uma operação sequencial, observe a distribuição durante a execução da tarefa lenta. Se uma vCPU concentra o trabalho enquanto as demais ficam disponíveis, aumentar a quantidade de processadores pode ampliar o atendimento simultâneo, mas não necessariamente reduzir a duração daquela operação.
Confira o que mudou no contrato: quantidade de vCPUs, memória, limites de disco e garantia de processamento. Pergunte também se houve mudança de máquina física e se o plano usa créditos de CPU, uma reserva que permite processamento adicional temporário. Se esses créditos acabam, o desempenho pode ficar limitado pelas regras do plano.
O nome comercial do plano não esclarece tudo isso. Mesmo uma oferta de CPU dedicada precisa especificar o recurso reservado e suas condições; ela não implica exclusividade de disco, rede ou de toda a máquina hospedeira.
Como interpretar CPU steal sem confundir indício com diagnóstico
Quando uma vCPU precisa executar, ela depende do agendamento feito pelo hipervisor. O steal contabiliza tempo de espera involuntária associado à execução de trabalho fora da máquina virtual, quando essa informação é exposta ao sistema convidado.
Essa espera pode aumentar o tempo de atendimento sem elevar proporcionalmente o processamento contabilizado para os programas. Se novas requisições, os pedidos recebidos pelo servidor, continuarem chegando mais rápido do que são concluídas, forma-se uma fila.
Steal recorrente junto com respostas mais lentas fortalece a hipótese de espera pelo processamento físico. Ele não identifica qual outra carga estava executando nem prova que o provedor colocou clientes demais na máquina. Também não permite deduzir diretamente quanto a aplicação aceleraria sem essa espera.
O comportamento merece mais atenção quando se repete em janelas de trabalho semelhante. Compare as mesmas rotas, os caminhos atendidos pela aplicação, e observe se houve mudança nas tarefas internas. Um pico isolado pode não explicar uma lentidão prolongada.
Uma comparação útil precisa preservar tanto o tipo de requisição quanto as tarefas executadas no mesmo período. Se o steal aumenta durante um backup e a resposta também piora, registre essa sobreposição. Compare depois uma janela sem o backup antes de atribuir a diferença à disponibilidade de processamento físico.
Ausência de steal também exige cautela. A virtualização pode não expor essa contabilização, e alguns limites de processamento aparecem por outros mecanismos. Portanto, valor zerado não equivale a comprovação de capacidade física sempre disponível.
Como observar steal e distribuição de CPU no Linux
Colete as métricas dentro da VPS que hospeda a aplicação. Contêineres são ambientes isolados para executar programas; ferramentas executadas dentro deles podem mostrar informações com escopos diferentes. Prefira observar também o sistema da VPS.
- Execute top -d 1 para atualizar a tela a cada segundo. Procure st no resumo de CPU: ele representa steal.
- Pressione 1 no top para separar a leitura por processador virtual. Observe se o trabalho está concentrado em uma vCPU.
- Execute vmstat 1 10 para obter dez relatórios. O primeiro normalmente resume o período desde a inicialização; os seguintes mostram intervalos de um segundo.
- Registre amostras durante a lentidão e em períodos normais. Consulte man top e man vmstat para conferir o comportamento da versão instalada.
Nos resumos de CPU, us representa execução de programas; sy, execução do sistema; id, ociosidade. O campo wa indica tempo contabilizado como espera de entrada ou saída, como operações de disco. Ele não mede diretamente a duração dessas operações nem comprova disco lento.
A média pode esconder uma vCPU saturada entre outras ociosas. Além disso, o percentual mostrado por processo no top pode usar uma escala diferente do resumo da máquina, conforme a configuração. Confira essa escala antes de comparar os valores.
Não existe percentual universal de steal que feche o diagnóstico. Importam a persistência, a coincidência com o impacto e as condições de coleta.
Como cruzar CPU, requisições e resposta na mesma linha do tempo
Alinhe relógios, fuso e intervalos antes de comparar registros. Uma medição de CPU por segundo e uma média de resposta de vários minutos podem esconder a ordem dos acontecimentos.
| Campo | O que registrar |
|---|---|
| Horário | Início, fim, fuso e intervalo de coleta |
| Tráfego | Requisições recebidas e concluídas no intervalo |
| Rotas | Caminhos afetados, como busca e carrinho |
| Resposta | Tempos de atendimento, erros e pedidos que excederam o prazo |
| CPU | us, sy, st e distribuição entre vCPUs |
| Contexto | Processos consumidores, versões, backups e tarefas agendadas |
Separe requisições recebidas das concluídas, quando houver dados para isso. Se observar apenas conclusões, uma queda no volume pode ser consequência da lentidão, e não redução da demanda. Pedidos interrompidos antes de chegar à aplicação também podem ficar fora dos registros dela.
Observe também se a diferença entre pedidos recebidos e concluídos persiste nos intervalos seguintes. Um intervalo isolado pode capturar requisições ainda em andamento; a continuidade da diferença ajuda a reconhecer acúmulo de trabalho. Cruze esse comportamento com erros e prazos excedidos para interpretar o volume concluído junto com o impacto.
Compare rotas semelhantes: uma busca pode exigir mais processamento que uma página servida por cache, o armazenamento de resultados para reutilização. Registre mudanças nesse mecanismo e nas versões da aplicação para não atribuir ao provedor uma diferença no trabalho executado.
Visitantes no Analytics, ferramenta de análise de audiência, não representam toda a carga do servidor. Uma visita gera várias requisições, e robôs também podem consumir recursos. Para separar essas origens, veja como analisar os registros de acesso.
Quais sinais investigar e o que levar ao provedor
Use a combinação de sinais para escolher a próxima verificação. Capacidade esgotada na aplicação e espera pelo processamento físico podem coexistir.
| Hipótese | Sinais favoráveis | Próxima verificação |
|---|---|---|
| Espera pelo processamento físico | Steal recorrente acompanha a lentidão com trabalho semelhante | Pedir análise de agendamento e contenção na máquina hospedeira |
| Capacidade de CPU esgotada | Execução de programas elevada, filas e pouco steal observado | Conferir processos, distribuição entre vCPUs e limites |
| Tarefa sequencial | Uma vCPU ocupada e outras disponíveis | Verificar se a operação consegue dividir trabalho |
| Espera por outro recurso | Resposta piora sem aumento correspondente de processamento | Medir memória, disco, rede e serviços dependentes |
Verifique também restrições impostas à aplicação ou ao contêiner. No Linux, cgroups são mecanismos que controlam recursos de grupos de processos; uma cota de CPU pode suspender temporariamente sua execução quando o orçamento se esgota. Aumentar as vCPUs da VPS não altera necessariamente essa configuração.
Separe a capacidade apresentada à VPS do orçamento permitido aos processos da aplicação. Confira se a restrição está no plano contratado ou na configuração do contêiner. Essa distinção orienta a correção: disponibilizar mais vCPUs não resolve uma cota que continua impedindo aqueles processos de usar a capacidade já disponível no servidor.
Se as evidências apontarem para consultas, prossiga com a investigação do banco MySQL. O objetivo aqui é separar hipóteses, sem transformar steal em explicação para toda lentidão.
- Informe identificação da VPS, plano e momento da alteração.
- Envie horários com fuso, duração dos episódios e amostras sequenciais.
- Inclua tráfego, resposta, erros e processos nas mesmas janelas.
- Peça verificação dos limites contratados e da contenção na máquina física.
Remova dados pessoais e credenciais antes de compartilhar registros. Depois de qualquer ajuste ou migração, repita a comparação sob carga semelhante; uma melhora em horário mais tranquilo não comprova a causa.
Conclusão: escolha a mudança que atende ao gargalo identificado
Aumentar o plano ajuda quando acrescenta o recurso que falta e a aplicação consegue aproveitá-lo. As evidências devem orientar a escolha entre corrigir limites, rever a aplicação, contratar garantias de CPU ou avaliar outro provedor.
Burst é capacidade extra em nuvem pública durante picos, retirada quando a demanda cai. Faz sentido quando a aplicação está preparada para distribuir trabalho entre servidores. Sessões e arquivos presos à VPS, por exemplo, exigem preparação antes dessa distribuição.
O SwarmBurst é um agente instalado no cluster Docker Swarm do cliente, um conjunto de servidores que executa contêineres de forma coordenada. Ele não corrige disputa na VPS original nem elimina um gargalo no banco que permanece nela.
Com o gargalo identificado, compare plano maior com reforço apenas no pico. Para avaliar a adequação do SwarmBurst ao ambiente, converse pelo WhatsApp com as evidências coletadas.
Perguntas frequentes
Por que a VPS continua lenta depois de contratar mais processadores virtuais?
Mais processadores virtuais permitem executar mais tarefas ao mesmo tempo, mas não garantem núcleos físicos exclusivos nem aceleram toda operação. Uma tarefa sequencial pode continuar usando apenas um processador virtual. Limites da aplicação, memória, disco, rede e regras do plano também precisam ser investigados.
Como observar CPU steal no top e no vmstat durante a lentidão?
CPU steal é o tempo em que um processador virtual fica sem executar enquanto o hipervisor, a camada que gerencia máquinas virtuais, atende trabalho externo à VPS. Execute top -d 1 e procure o campo st no resumo de CPU. Pressione 1 para separar a leitura por processador virtual. Execute também vmstat 1 10: o primeiro relatório normalmente resume o período desde a inicialização; os seguintes mostram intervalos de um segundo. Compare amostras durante a lentidão e em períodos normais.
CPU steal zerado descarta disputa de recursos no provedor?
Não. A virtualização pode não expor essa contabilização, e alguns limites de processamento aparecem por outros mecanismos. Um valor zerado também não elimina disputa por disco, rede ou outros recursos. Compare o sinal com tráfego, tempo de resposta e limites contratados.
Quais evidências enviar ao provedor antes de pedir mudança de máquina física?
Envie a identificação da VPS, o plano e o momento da alteração, além dos horários com fuso, duração dos episódios e amostras sequenciais. Inclua tráfego, tempo de resposta, erros e processos consumidores nas mesmas janelas. Peça a verificação dos limites contratados e da disputa por processamento na máquina física. Remova dados pessoais e credenciais dos registros antes de compartilhá-los.
Quando considerar CPU dedicada, trocar de provedor ou usar burst no pico?
A escolha depende do gargalo identificado. Evidências de espera pelo processamento físico podem orientar a avaliação de garantias de CPU ou de outro provedor. Confira exatamente quais recursos uma oferta de CPU dedicada reserva. Burst, capacidade extra em nuvem pública durante picos, faz sentido quando a aplicação consegue distribuir trabalho entre servidores. Ele não corrige disputa na VPS original nem elimina um gargalo no banco que permanece nela.