🔹 Introdução

Validação de recursos contratados. Em ambientes de VPS, cloud e até servidores dedicados, assumir que os recursos contratados estão realmente disponíveis pode ser um erro caro. Overcommit de CPU, limitação oculta de I/O, memória compartilhada e throttling silencioso são problemas comuns — especialmente em clouds mais baratas.

A validação de recursos contratados é uma etapa essencial logo após o provisionamento do servidor e também deve fazer parte de auditorias periódicas de infraestrutura.

🔹 O que deve ser validado

1️⃣ CPU

• Quantidade real de vCPUs
• Tipo de CPU (dedicada vs compartilhada)
• Frequência e throttling
• Steal time em ambientes virtualizados

2️⃣ Memória RAM

• Quantidade total disponível
• Ballooning ativo
• Swap forçada pelo hypervisor
• Limites cgroups (clouds modernas)

3️⃣ Disco

• Capacidade real
• Tipo (HDD, SSD, NVMe)
• Performance de IOPS e throughput
• Latência média e picos

4️⃣ Rede

• Velocidade de link
• Limites de banda
• Latência interna e externa
• Packet loss sob carga

🔹 Por que validar recursos contratados

• Evita pagar por recursos inexistentes
• Identifica overcommit agressivo do provedor
• Explica gargalos “invisíveis”
• Melhora planejamento de capacidade
• Dá base técnica para abrir chamados ou trocar de fornecedor

🔹 Quando fazer essa validação

• Logo após contratar o servidor
• Após migração de plano
• Quando surgirem lentidões inexplicáveis
• Antes de colocar produção crítica
• Periodicamente (ex: a cada 3 ou 6 meses)

🔹 Erros comuns

• Confiar apenas no painel do provedor
• Validar só CPU e RAM e ignorar disco
• Não testar sob carga
• Comparar números teóricos com benchmarks irreais
• Ignorar steal time e throttling

✅ Checklist prático: validação de recursos contratados (Linux)

🧠 CPU

🔍 Quantidade de CPUs visíveis

nproc
lscpu | grep '^CPU(s)'

Compare com o que foi contratado.

🔍 Modelo, clock e virtualização

lscpu

Pontos importantes:

• Model name
• CPU MHz / Max MHz
• Hypervisor vendor
• Virtualization type

🔥 Steal time (CPU roubada pelo hypervisor)

top

Observe a linha:

%Cpu(s): ... st

👉 Regra prática

• st > 2% constante → CPU compartilhada agressiva
• st > 5% → problema sério de overcommit

🔄 Teste rápido de carga de CPU

apt install -y stress || yum install -y stress
stress --cpu $(nproc) --timeout 60

Durante o teste:

top

Se a CPU não chega perto de 100% ou o tempo de execução aumenta demais → throttling.

🧠 Memória RAM

🔍 Total de memória disponível

free -h

Compare total com o plano contratado.

🔍 Detalhes da memória

cat /proc/meminfo | head

Verifique:

• MemTotal
• SwapTotal

⚠️ Verificar ballooning / cgroup

dmesg | grep -i balloon

Em clouds modernas:

cat /sys/fs/cgroup/memory.max 2>/dev/null

Se retornar valor menor que a RAM contratada → limite imposto pelo hypervisor.

🔄 Teste simples de uso de memória

apt install -y stress || yum install -y stress
stress --vm 1 --vm-bytes 80% --timeout 60

Se o processo for morto rapidamente → limitação oculta.

💾 Disco

🔍 Capacidade real

lsblk
df -h

Confirme:

• Tamanho total
• Ponto de montagem correto

🔍 Tipo de disco

lsblk -o NAME,ROTA,TYPE,SIZE,MODEL

• ROTA=0 → SSD / NVMe
• ROTA=1 → HDD

🚀 Teste rápido de throughput

dd if=/dev/zero of=testfile bs=1G count=1 oflag=direct
rm -f testfile

Indicativo:

• HDD: ~100–200 MB/s
• SSD: ~300–500 MB/s
• NVMe: >800 MB/s (pode variar)

⚡ IOPS e latência (fio)

apt install -y fio || yum install -y fio

fio --name=randread \
    --ioengine=libaio \
    --iodepth=32 \
    --rw=randread \
    --bs=4k \
    --direct=1 \
    --size=1G \
    --numjobs=1 \
    --runtime=30 \
    --group_reporting

Observe:

• IOPS
• lat (usec/msec)

Latência alta = storage compartilhado saturado.

🌐 Rede

🔍 Interface e link

ip a
ethtool eth0

Verifique:

• Speed
• Duplex

🚀 Teste de banda (iperf)

No servidor:

iperf3 -s

No cliente:

iperf3 -c IP_DO_SERVIDOR

Compare com a banda contratada.

🌍 Latência e perda de pacotes

ping -c 50 8.8.8.8

Packet loss > 1% → alerta.

🔎 Virtualização e ambiente

🔍 Tipo de virtualização

systemd-detect-virt

Ou:

virt-what

🔍 Kernel e arquitetura

uname -a

🧾 Checklist final (resumo rápido)

✔ CPU cores visíveis
✔ Steal time aceitável
✔ RAM total correta
✔ Sem ballooning / limites ocultos
✔ Disco com capacidade e performance compatíveis
✔ IOPS e latência aceitáveis
✔ Rede sem perda e com banda real
✔ Virtualização conhecida e documentada

🚨 Sinais clássicos de problema

• CPU não escala sob carga
• Steal time alto em horário comercial
• Disco NVMe com latência de HDD
• Processos mortos ao usar RAM
• Banda abaixo do prometido

FAQ