Burst de CPU em VPS: Configuração, Limites e Performance

A administração de sistemas (SysAdmin), a engenharia de DevOps e a arquitetura de Cloud Computing evoluíram drasticamente na última década. No passado, alugar um servidor significava lidar com uma máquina física (Bare Metal) onde 100% dos recursos eram seus. Hoje, a norma é a virtualização. Quando você contrata um Servidor Privado Virtual (VPS) com “4 vCPUs”, você não está comprando quatro núcleos de silício dedicados a você. Você está comprando uma fração de tempo de processamento em um ecossistema complexo governado por algoritmos rígidos.

No centro dessa dinâmica está um conceito vital e frequentemente mal compreendido: o Burst de CPU (ou rajada de CPU).

Neste guia monumental, vamos dissecar absolutamente tudo sobre o burst de CPU. Vamos entender a economia por trás disso, como o kernel do Linux agenda processos, como limitar recursos usando as ferramentas nativas mais modernas e como monitorar gargalos de performance que podem estar destruindo a velocidade da sua aplicação web.

1. A Evolução da Hospedagem e o Nascimento do VPS

Para entender o burst de CPU, precisamos entender por que os Servidores Virtuais Privados (VPS) foram criados.

Nos primórdios da internet comercial, tínhamos duas opções principais:

1. Hospedagem Compartilhada (Shared Hosting): Centenas de sites rodando no mesmo sistema operacional, usando o mesmo servidor web (como Apache) e o mesmo banco de dados. Um site com código ruim podia derrubar o servidor inteiro, afetando todos os outros clientes.
2. Servidor Dedicado (Bare Metal): Uma máquina física inteira só para você. Excelente performance e isolamento, mas com um custo proibitivo para pequenas e médias empresas.

A tecnologia de virtualização resolveu esse abismo. Hipervisores (como VMware, Xen e, posteriormente, KVM) permitiram pegar um servidor físico massivo com, digamos, 64 núcleos de CPU e 256 GB de RAM, e fatiá-lo em dezenas de máquinas virtuais independentes. Cada VPS tem seu próprio sistema operacional, sua própria rede isolada e seus próprios processos.

No entanto, surgiu um problema matemático: se o servidor físico tem 64 núcleos, o provedor só pode vender 64 vCPUs com garantia total. Mas a maioria dos servidores passa 90% do tempo ociosa. É aqui que entra o conceito de overprovisioning e, consequentemente, o burst de CPU.

2. O Que É, Afinal, o Burst de CPU?

Em um ambiente de computação em nuvem (Cloud Computing) ou VPS padrão, os provedores utilizam a multiplexação estatística. Eles vendem mais vCPUs lógicas do que existem núcleos físicos no hardware, sabendo que nem todos os clientes usarão 100% da CPU ao mesmo tempo.

Para manter a justiça e a estabilidade, os recursos de CPU são divididos em duas categorias para cada cliente:

• CPU Garantida (Baseline / Reserva Mínima / CPU Shares): É a quantidade mínima de tempo de processador que o hipervisor garante que você sempre terá acesso, não importa o quão sobrecarregado esteja o servidor físico. Por exemplo, em um plano básico, você pode ter 1 vCPU, mas uma garantia de apenas 20% do tempo desse núcleo.
• CPU Burst (Rajada / Capacidade Extra / CPU Quota): É a capacidade de usar até 100% da vCPU (ou múltiplas vCPUs) temporariamente, desde que o servidor físico hospedeiro tenha recursos ociosos no momento.

A Analogia da Rodovia

Imagine uma rodovia com 4 faixas (os núcleos do servidor físico).

A CPU Garantida significa que você tem o direito inalienável de colocar 1 carro nessa rodovia a qualquer momento.

O CPU Burst significa que, se a rodovia estiver vazia de madrugada, você tem permissão para colocar 4 carros simultaneamente para fazer suas entregas mais rápido. Porém, se for hora do rush e todos os outros clientes quiserem usar a rodovia, o “guarda de trânsito” (o Hipervisor) vai forçar você a voltar a usar apenas 1 carro, e os outros 3 terão que esperar no acostamento. Essa “espera no acostamento” é o que chamamos de Steal Time.

3. A Matemática do CPU Scheduling: Como o Kernel Lida com Isso

Para dominar o burst, precisamos entender o CFS (Completely Fair Scheduler), que é o agendador de processos padrão do kernel Linux.

Quando o seu VPS (que é uma máquina virtual rodando em cima de um servidor físico) pede para processar um cálculo do PHP ou uma query do MySQL, esse pedido desce para o hipervisor (geralmente KVM em distribuições modernas).

O hipervisor usa o CFS para dividir o tempo da CPU em “fatias” (time slices). Ele opera baseado em dois parâmetros fundamentais quando trabalha com cgroups (Control Groups, que discutiremos em detalhes mais à frente):

1. Quota (cfs_quota_us): O tempo total de execução permitido em um determinado período.
2. Período (cfs_period_us): O intervalo de tempo no qual a quota é reabastecida.

Se o seu provedor de VPS define que sua máquina tem uma baseline de 50% de 1 núcleo, ele pode configurar no hipervisor:

• Período: 100.000 microssegundos (100 ms)
• Quota: 50.000 microssegundos (50 ms)

Isso significa que a cada 100 milissegundos, o seu VPS tem permissão para rodar na CPU física por 50 milissegundos. Se o seu VPS tentar rodar por 60 milissegundos, o hipervisor pausa a sua máquina virtual (fazendo-a dormir) durante os 10 milissegundos restantes, até que o próximo período de 100ms comece.

Quando o burst está habilitado, o hipervisor ignora essa pausa de 10ms se a CPU física estiver ociosa, permitindo que seu VPS continue calculando.

4. O Sistema de Créditos de CPU (O Padrão AWS e Cloud)

Provedores modernos de nuvem pública, liderados historicamente pela Amazon Web Services (AWS) com suas instâncias T2, T3 e T4g, formalizaram o burst transformando-o em uma mecânica financeira e técnica baseada em Créditos de CPU.

Como funciona a economia de créditos?

1. Geração Contínua: A sua instância ganha créditos a uma taxa constante por hora. Por exemplo, uma instância t3.micro ganha 12 créditos por hora.
2. A Baseline: Um crédito equivale a 1 vCPU rodando a 100% de utilização por 1 minuto. Ganhar 12 créditos por hora significa que a sua baseline garantida é de 20% de 1 vCPU (12 minutos em 60 minutos).
3. O Acúmulo: Se o seu site não estiver recebendo visitas e a sua CPU estiver em 5%, você está gastando menos créditos do que ganha. Os créditos não utilizados vão para um saldo acumulado (até um limite máximo, geralmente 24 horas de créditos).
4. O Burst: Quando seu site recebe um pico de acessos (alguém compartilhou seu link no Twitter), a instância precisa de 100% da CPU. Ela pode fazer isso “queimando” o saldo acumulado de créditos.
5. O Esgotamento (Throttling): Se o pico durar muito tempo e o seu saldo de créditos chegar a zero, o hipervisor impõe um corte violento. A sua instância é forçada a rodar apenas na baseline (20%). O resultado? Lentidão extrema, timeouts no Nginx (Error 504 Gateway Timeout) e queda no banco de dados.

Outros provedores, como DigitalOcean (nas instâncias Basic Shared) ou Linode, não mostram um “saldo de créditos” explícito em um painel, mas utilizam algoritmos de Fair Share no hipervisor que agem de forma semelhante. Se você abusar do burst por horas seguidas, seu VPS será estrangulado silenciosamente.

5. O Inimigo Silencioso: CPU Steal Time

Como você descobre, de dentro do seu VPS, se o seu provedor está limitando o seu burst? A resposta está em uma métrica de sistema chamada Steal Time.

Se você abrir o terminal do seu servidor Linux e digitar o comando top, verá um cabeçalho semelhante a este:

Plaintext

%Cpu(s): 15.2 us,  3.1 sy,  0.0 ni, 75.3 id,  0.2 wa,  0.0 hi,  0.1 si,  6.1 st

Vamos decifrar essas métricas vitais:

• us (User): Tempo gasto rodando código do usuário (seu PHP, Node.js, etc).
• sy (System): Tempo gasto rodando código do kernel do Linux.
• id (Idle): Tempo em que a CPU está completamente livre e ociosa.
• wa (I/O Wait): Tempo em que a CPU está parada esperando o disco rígido responder.
• st (Steal Time): A métrica mais importante para o Burst.

O que é o Steal Time (st)?

É a porcentagem de tempo em que a sua máquina virtual tinha tarefas prontas para serem executadas, processamento para fazer, mas o hipervisor do servidor físico disse: “Não. Você esgotou seus créditos de burst” ou “O servidor físico está sobrecarregado com outros clientes, espere sua vez”. O tempo foi, literalmente, roubado de você.

Diagnosticando problemas com Steal Time:

• Steal Time entre 0% e 2%: Completamente normal em ambientes de nuvem compartilhada. Micro-atrasos no hipervisor.
• Steal Time entre 5% e 10%: Sinal de alerta. Seu site pode começar a apresentar lentidões esporádicas.
• Steal Time acima de 15% sustentado: Seu servidor está sofrendo throttling (estrangulamento). Você estourou seu limite de burst ou o provedor vendeu mais do que a máquina física aguenta (overselling criminoso). A aplicação estará notavelmente lenta.

6. Controlando o Burst no Linux: A Abordagem Moderna com Systemd e Cgroups

Muitas vezes, não queremos depender do provedor para limitar nossa CPU. Como administradores de sistemas, queremos impor nossos próprios limites internamente.

Por que faríamos isso? Imagine que você tem um servidor web crítico (Nginx + MariaDB). Você configura um script de backup no cron para rodar às 3 da manhã, que compacta gigabytes de dados usando tar e gzip. O gzip é faminto por CPU. Ele vai usar 100% da sua vCPU, engatilhar o Burst máximo, esgotar os seus créditos no provedor e, em seguida, derrubar a performance do Nginx.

Para evitar isso, usamos Control Groups (cgroups), a mesma tecnologia que torna o Docker possível.

A Evolução: cgroups v1 vs cgroups v2

No passado (CentOS 7, Ubuntu 18.04), interagir com cgroups envolvia montar sistemas de arquivos virtuais e escrever PIDs manualmente em arquivos /sys/fs/cgroup/cpu/tasks.

Hoje, com distribuições modernas (Ubuntu 22.04/24.04, AlmaLinux 9, Debian 12), o systemd unificou o gerenciamento de cgroups. O systemd organiza os processos em uma hierarquia de slices, scopes e services.

Passo a Passo: Limitando a CPU de um Serviço via Systemd

Vamos impedir que nosso banco de dados MariaDB consuma mais do que 80% de um núcleo (evitando que ele faça burst para múltiplos núcleos e esgote os recursos do VPS).

1. Crie um arquivo de substituição (drop-in) para o serviço:A maneira correta de alterar configurações do systemd não é editar o arquivo original em /lib/systemd/system/, mas usar o comando edit.Bashsudo systemctl edit mariadb.service
2. Configure a Quota de CPU:Isso abrirá um editor de texto vazio. Você adicionará os limites de recurso do cgroup na seção [Service].Ini, TOML[Service] # Limita o uso máximo a 80% de um único núcleo. # Se você tiver 4 núcleos (400% no total) e quiser limitar a 2 núcleos, usaria 200%. CPUQuota=80%
3. Salve o arquivo, recarregue o daemon e reinicie o serviço:Bashsudo systemctl daemon-reload sudo systemctl restart mariadb.service

A partir deste momento, o kernel do Linux monitorará rigorosamente o MariaDB. Se ele tentar usar mais de 80% da CPU, o próprio kernel do seu VPS irá pausá-lo (throttling interno), poupando o restante da sua CPU para o Nginx ou outras tarefas vitais, e impedindo que o seu provedor corte os seus recursos de burst globais.

7. A Abordagem Tradicional: Usando o cpulimit

Para scripts rápidos ou processos que não rodam como serviços do systemd (como um comando solto no terminal ou um shell script básico), a ferramenta cpulimit é excelente.

O cpulimit não usa cgroups. Em vez disso, ele monitora o processo alvo e envia repetidamente sinais do kernel POSIX: SIGSTOP (pause) e SIGCONT (continue) para forçar o processo a manter uma média de uso de CPU específica.

Instalação:

• Debian/Ubuntu: sudo apt install cpulimit
• RHEL/AlmaLinux/Rocky: sudo dnf install epel-release && sudo dnf install cpulimit

Casos de Uso Práticos:

Caso 1: Limitando um processo já em execução pelo PID

Você abriu o htop e viu que um script Python (PID 10450) enlouqueceu e está usando 100% da CPU. Você quer acalmá-lo para 30% enquanto investiga.

Bash

cpulimit -p 10450 -l 30

Caso 2: Iniciando um comando já com limite

Você vai iniciar o backup manual e sabe que vai consumir muita CPU. Inicie-o engaiolado:

Bash

cpulimit -l 50 -- tar -czvf /backup/site.tar.gz /var/www/html/

Neste cenário, o comando tar nunca passará de 50% de uso da CPU, deixando os recursos livres para as requisições web dos usuários.

8. Monitoramento Avançado: Não Trabalhe às Cegas

Configurar limites é inútil se você não souber o impacto deles. Administradores profissionais usam pilhas de observabilidade. Vou detalhar como monitorar o CPU Burst.

Ferramentas de Linha de Comando (Diagnóstico Rápido)

• htop: Melhor que o top padrão. Pressione F2, vá em “Display options” e marque “Detailed CPU time”. Isso mostrará o Steal Time de forma gráfica e colorida.
• vmstat 1: O comando vmstat seguido de 1 (atualização a cada 1 segundo) é fantástico para ver o panorama geral. Olhe para a última coluna (st).
• mpstat -P ALL 1: Parte do pacote sysstat. Mostra o uso de CPU separado por cada núcleo lógico. Fundamental para ver se o limite do provedor afeta todos os núcleos ou se há um gargalo de thread única (single-thread bottleneck).

A Pilha Profissional: Prometheus + Node Exporter + Grafana

Para produção, você precisa de histórico. Se o seu servidor caiu às 4 da manhã, o top não vai te ajudar às 8 da manhã. Você precisa de métricas armazenadas.

1. Node Exporter: Um serviço (daemon) que roda no seu VPS coletando métricas do kernel do Linux (incluindo tempo exato de CPU em cada estado: user, system, idle, steal).
2. Prometheus: Um banco de dados de séries temporais que se conecta ao Node Exporter e salva o histórico das métricas.
3. Grafana: A interface gráfica que conecta no Prometheus e gera gráficos lindos.

No Grafana, a query (PromQL) para monitorar o esgotamento do burst (Steal Time) seria algo como:

Snippet de código

rate(node_cpu_seconds_total{mode="steal"}[5m]) * 100

Se você configurar um alerta para disparar no Slack ou Microsoft Teams toda vez que essa query retornar um valor maior que 10 por mais de 5 minutos, você será avisado instantaneamente de que o seu VPS está ficando sem fôlego e perdendo desempenho de burst, muito antes do cliente reclamar que “o site está lento”.

9. Arquitetura: Quando o Burst é o Herói e Quando é o Vilão

A decisão de hospedar uma aplicação em um VPS com CPU compartilhada (com Burst) ou migrar para um ambiente de CPU Dedicada (Dedicated Instances / Bare Metal) define o sucesso ou o fracasso de um projeto infraestrutural.

Cenários Onde o CPU Burst é o Herói (Uso Recomendado)

1. Blogs, Sites Institucionais e WordPress: O tráfego web é, por natureza, “espasmódico”. Um usuário entra, o PHP processa a página (pico de CPU), o servidor entrega o HTML, e o usuário passa 3 minutos lendo a página (CPU ociosa). A instância acumula créditos enquanto o usuário lê, e gasta os créditos para gerar a próxima página. Perfeito para o modelo de burst. Custo-benefício insuperável.
2. Microserviços de Backend (APIs RESTful com tráfego irregular): APIs que recebem chamadas de aplicativos móveis com picos claros durante o dia, mas ficam tranquilas de madrugada.
3. Servidores de Homologação (Staging/Dev): Ambientes de teste não precisam de poder computacional constante. Desenvolvedores compilam código de vez em quando. Ambientes compartilhados economizam milhares de reais por mês em grandes empresas.

Cenários Onde o CPU Burst é o Vilão (NÃO RECOMENDADO)

1. Bancos de Dados Relacionais Críticos (MySQL, PostgreSQL em grande escala): Um banco de dados otimizado mantém muitas tabelas em RAM, mas cálculos de agregação complexos (JOINs gigantes, relatórios) exigem CPU sustentada por minutos ou horas. Se a query estourar o limite de burst e o hipervisor aplicar o estrangulamento (throttling), a query ficará em espera, travando tabelas e causando um engavetamento de conexões que derrubará toda a infraestrutura em efeito dominó. Bancos de dados de produção crítica exigem CPU Dedicada.
2. Transcodificação de Vídeo e Áudio (FFmpeg): Converter um vídeo de 4K para 1080p vai fritar a CPU por horas. Se rodar isso em uma máquina com burst, ela fará a conversão rápido nos primeiros 15 minutos, esgotará os créditos, e as próximas horas rodarão a 20% da velocidade, arrastando o processamento.
3. Servidores de Jogos Multiplayer (Minecraft, CS2, Palworld): Jogos exigem uma Tick Rate (taxa de atualização) constante e contínua atrelada ao relógio da CPU em single-thread. Uma flutuação imposta pelo hipervisor causará picos de lag insuportáveis para os jogadores (o famoso rubberbanding). Exige servidores Bare Metal ou High Frequency Compute Dedicado.
4. Criptomineração: Além de violar os Termos de Serviço de 99% dos provedores de nuvem e gerar banimento sumário da sua conta, tentar rodar algoritmos de mineração consumirá todos os créditos de burst instantaneamente.

10. Tabelas Comparativas de Provedores de Mercado

Para auxiliar na tomada de decisão, aqui está um panorama de como os maiores players do mercado tratam o CPU Burst.

Conclusão e Melhores Práticas de Engenharia

Chegamos ao final desta extensa jornada pelo coração do processamento em ambientes virtualizados. Compreender o Burst de CPU é o que separa o operador de servidores amador do Engenheiro de Infraestrutura sênior.

Você não está mais no escuro quando seu servidor misteriosamente fica lento apesar de ter “4 núcleos”. Agora você sabe que a nuvem é uma ilusão muito bem orquestrada de compartilhamento de recursos.

O resumo das melhores práticas:

1. Monitoramento implacável: Nunca rode aplicações de produção sem configurar o Node Exporter ou o Netdata para vigiar o Steal Time.
2. Separação de Papéis: Separe o banco de dados da aplicação web. Coloque o banco de dados em uma instância de CPU Dedicada e deixe os servidores web frontend (Nginx/PHP) em instâncias mais baratas com Burst.
3. Tome o controle: Use o systemd (cgroups) para confinar processos gulosos como scripts de backup e atualizações noturnas, garantindo que eles não gastem a sua quota preciosa de burst do provedor.
4. Scale Out, não Scale Up: Em vez de pagar uma fortuna por uma única máquina gigante para aguentar picos de burst, implemente arquiteturas distribuídas com Load Balancers e Auto Scaling Groups. Múltiplas máquinas pequenas com burst conseguem gerenciar o tráfego de forma muito mais inteligente e barata.

FAQ