Detecção de largura de banda de memória em servidores em nuvem: por que a velocidade cai mesmo com capacidade adequada

Capacidade suficiente não significa largura de banda suficiente; somente uma análise tridimensional permite enxergar com clareza.

Atualizado 2026-10-07 · CloudWorth

largura de banda de memóriaSTREAMNUMAdetecção de oversellingFinOpsCloudWorthSteal TimeOverselling VPSBenchmark VPS

Capacidade adequada não é o mesmo que largura de banda adequada; use STREAM, Steal Time e vinculação de NUMA para análise cruzada e, em seguida, compare com a taxa de prêmio para decidir entre upgrade ou reembolso.

Meça a capacidade primeiro, depois a largura de banda

Ao comprar um servidor em nuvem, quase todo mundo olha primeiro para a capacidade de memória: 8GB, 16GB, 32GB. A capacidade está na página do pedido, é visível, confere, então é presumida como “memória sem problema”. Mas capacidade é só a área do armazém, largura de banda é a velocidade da empilhadeira — uma instância de 8GB pode perfeitamente ter, com a capacidade toda verde, uma vazão de memória de apenas metade do nominal da mesma geração.

Este é o cenário clássico de capacidade dentro do esperado, mas com queda de velocidade: cargas como inferência de IA, busca vetorial, grandes valores no Redis, cópia dentro do heap da JVM são muito mais sensíveis a GB/s do que a GB; quando a capacidade é suficiente, você bate primeiro no teto da largura de banda.

Primeiro, separe em duas etapas:

1. Lado da capacidade: free -h para ver total/available, depois confira com a especificação do pedido, confirme que não houve recuperação por um driver balloon oculto. Em KVM, pode verificar dmesg | grep -i balloon.
2. Lado da largura de banda: o fato de a capacidade conferir não significa que a largura de banda confere; é preciso um teste dedicado de vazão de memória, que será detalhado na próxima seção.

A ordem deve ser: primeiro capacidade, depois largura de banda. Se a capacidade não atende, é falsificação de especificação; vá direto para o reembolso. Se a capacidade atende mas a largura de banda cai, aí sim é o problema mais oculto de supervenda / limitação de velocidade, que exige esta cadeia de evidências abaixo.

Um critério empírico: se você comprou uma instância de “mesma capacidade, mas com preço claramente um nível abaixo”, presuma desde o início que a largura de banda é o item suspeito, em vez de presumir que fez um bom negócio. Esse tipo de barato costuma vir de superalocação de CPU, layout NUMA entre nós ou rebaixamento da frequência da memória, e no fim se volta contra você na forma de taxa de prêmio de custo-benefício — comprou capacidade, mas não comprou vazão.

Depois de registrar os dados brutos (especificação da instância, região, imagem, tipo de cobrança, horário do pedido), passe aos testes reais. O próprio registro é a evidência para chamados e decisões de redução de configuração posteriores; em um chamado, escrever apenas “a memória está muito lenta” quase nunca terá tratamento eficaz.

Testes práticos com STREAM e sysbench

A verificação de largura de banda de memória tem dois conjuntos complementares de ferramentas: o STREAM mede a taxa de transferência vetorial sustentável (Copy/Scale/Add/Triad), e o sysbench memory mede cenários mais próximos de "leitura e escrita de pequenos blocos". A discussão sysbench vs STREAM memory bandwidth test for cloud servers não faz sentido; ambos precisam ser executados, porque suas distorções são em direções diferentes: o STREAM é amigável demais com o cache L3 de instâncias pequenas, e o sysbench é sensível demais ao custo de instruções; só cruzando os dados você não será enganado por um número isolado.

Uso do STREAM (pode compilar no diretório home sem root):

sudo apt install -y gcc gfortran make
# 下载 stream.c 后：
gcc -O3 -fopenmp -DSTREAM_ARRAY_SIZE=200000000 stream.c -o stream
OMP_NUM_THREADS=$(nproc) ./stream

Defina o tamanho do array como 1/4 a 1/2 da memória; se for muito pequeno, tudo ficará no cache e você obterá uma "largura de banda inflada"; caso contrário, você estará medindo o L3, não a DRAM.

Do lado do sysbench:

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write run

Há três pontos principais de avaliação:

• Um núcleo vs todos os núcleos: execute separadamente com taskset -c 0 e com todos os núcleos, registrando GB/s. Se com todos os núcleos o valor quase não subir, isso indica que a largura de banda já está limitada, e não que faltam núcleos.
• Compare com o nominal: a diferença geracional entre DDR4 e DDR5 é da ordem de 1,5 a 2 vezes; instâncias de nuvem da mesma geração e mesma frequência não deveriam apresentar diferenças de duas a três vezes; se isso ocorrer, é anormal.
• Converta para largura de banda por vCPU: largura de banda total / número de vCPUs é a métrica mais útil para julgar supervenda de largura de banda de memória. Instâncias compartilhadas costumam ter apenas metade da largura de banda por vCPU das instâncias dedicadas, e isso é uma das verdadeiras fontes da taxa de prêmio de servidores em nuvem.

Execute três vezes e pegue a mediana, evitando os picos dos vizinhos em horas cheias. Se quiser converter automaticamente esses números em largura de banda por vCPU e taxa de prêmio, você pode criar um modelo em /app, inserir STREAM, sysbench e o preço da instância juntos, e gerar um perfil de custo-benefício comparável. A próxima seção usa Steal Time e NUMA para atribuir a "queda de velocidade" a causas específicas.

Análise forense de Steal Time e NUMA

A seção anterior só consegue provar que «perdeu velocidade»; a atribuição ainda depende de dois outros indicadores: Steal Time e topologia NUMA. Essa também é a camada mais fácil de ignorar na verificação de largura de banda de memória em servidores em nuvem — capacidade suficiente, um teste isolado dentro do esperado, mas o gargalo escondido no agendamento e na afinidade de memória. As páginas de configuração nominal nunca escrevem esses dois itens, e a diferença nos benchmarks reais costuma vir exatamente daí.

Primeiro, veja o st:

vmstat 1 10        # 盯 st 列（Steal Time）
mpstat -P ALL 1    # 逐核 %steal

st persistentemente >3% e sincronizado com a queda de largura de banda indica que o tempo de vCPU está sendo tomado pelos vizinhos. Em KVM compartilhado, a correlação entre CPU steal e largura de banda de memória é altíssima; o que cai é todo o caminho, não apenas a capacidade de processamento.

Agora, o NUMA:

lscpu | grep -i numa
numactl --hardware
numactl --cpunodebind=0 --membind=0 \
  sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read run

Se, depois de fixar o processo ao nó local, a largura de banda subir de forma clara, trata-se de penalidade entre nós (comumente 20%–40%), não de overselling; se, após a fixação, ela continuar colada no teto de banda por usuário, aí sim é limitação real de velocidade.

Leve três capturas de tela — st, topologia NUMA e largura de banda antes/depois da fixação — ao abrir um chamado; isso é muito mais eficaz do que dizer «ficou mais lento» sem evidências. Se quiser transformar isso em um modelo de coleta de evidências reutilizável, você pode, em /app, colocar esses três números junto com o preço unitário que você paga, calcular a taxa de sobrepreço e só então decidir entre fazer upgrade de configuração, trocar de zona de disponibilidade ou seguir o fluxo de reembolso.

Verificação do precipício de cache de disco

Depois da vinculação de NUMA, a largura de banda ainda está colada no teto, falta a última prova: usar o precipício de cache para separar "memória lenta" de "disco lento". O procedimento é fazer primeiro uma leitura quente e depois uma leitura fria do mesmo arquivo, e ver em qual tamanho de conjunto de trabalho a largura de banda cai.

# 1) 热路径：让 page cache 命中，测的是缓存速度
fio --name=hot --filename=/data/blob --rw=read --bs=1M \
    --size=4G --direct=0 --runtime=30 --time_based

# 2) 冷路径：清缓存后测真实内存→IO 通路
sync && echo 3 > /proc/sys/vm/drop_caches
fio --name=cold --filename=/data/blob --rw=read --bs=1M \
    --size=4G --direct=1 --runtime=30 --time_based

Pontos de interpretação:

• A largura de banda de leitura fria, conforme o conjunto de trabalho cresce de 256M para 4G, apresenta uma queda suave, o que é o comportamento normal da hierarquia de memória e da pré-busca;
• Cair formando um precipício (por exemplo, cair pela metade perto de 2G), e o ponto de quebra for muito menor que o L3/cache esperado nominal da instância, normalmente indica que a largura de banda da memória está sendo limitada, e não que o disco não aguenta primeiro;
• Aproveite para olhar bi/bo e si/so em vmstat 1; se o IO não estiver alto mas a taxa de transferência despencar, a culpa provavelmente está no lado da memória.

Este também é o ponto em que "benchmark real vs configuração nominal" mais dá errado: uma instância de 8GB com DDR4/DDR5 e capacidade nominais não está errada, mas assim que o KV cache de inferência de IA ou a busca vetorial empurra o conjunto de trabalho para fora do cache, a largura de banda cai primeiro, e a latência logo oscila. Junte o ponto do precipício, a largura de banda antes e depois da vinculação de NUMA e %steal com o preço unitário que você realmente paga para calcular a taxa de sobrepreço, e só então decida se faz upgrade, troca de zona de disponibilidade ou pedido de reembolso — isso é bem mais eficaz do que reiniciar repetidamente. Se precisar de um modelo de evidências pronto, você pode aplicá-lo diretamente em /app.

Em uma frase: atingir a capacidade é só o ingresso; a verificação de largura de banda de memória de servidor em nuvem precisa ver onde está o ponto de inflexão da queda de velocidade e, depois dele, por qual preço você ainda está pagando.

Comparação de benchmarks e decisão sobre sobrepreço

Nos textos anteriores, já obtivemos três conjuntos de dados concretos: Copy/Triad do STREAM, a diferença de largura de banda antes e depois da vinculação NUMA, e a curva de %steal. Agora só falta o último passo — alinhá-los à fatura. O método é simples: escreva “nominal vs. medido” da mesma instância em duas colunas:

# 实测带宽（GB/s）
sysbench memory --memory-block-size=1M --memory-total-size=10G run | grep transferred
# 单价（元/GB 内存/月）= 月费 / 标称容量
# 性价比 = 实测带宽 / 单价

As linhas de interpretação podem ser mais grosseiras, mas precisam ter números:

• Largura de banda medida atinge mais de 70% dos valores públicos de DDR4/DDR5 da mesma geração, e %steal normalmente abaixo de 2%: compartilhamento normal, continue usando;
• Largura de banda em apenas 50%–70% do esperado nominal, e a vinculação NUMA consegue recuperar 15%+: é um problema de escalonamento; trocar de zona de disponibilidade ou especificar afinidade de vCPU geralmente sai mais barato que aumentar a configuração;
• Largura de banda abaixo de 50%, %steal acima de 5% por longos períodos e queda abrupta de Cache aparecendo mais cedo: este é o sinal típico de overselling de VPS, a prova concreta de detecção de overselling de servidor cloud.

Calcule o custo-benefício antes de falar em ação. Suponha uma instância de 8 GB com mensalidade de 120 yuans, e a largura de banda medida é só 60% de uma instância AMD EPYC no mesmo preço; então sua taxa de sobrepreço é, na verdade, 40% — nesse caso, aumentar para 16 GB muitas vezes só amplia o “cada GB mais caro”; trocar o tipo de instância ou pedir reembolso é mais vantajoso. Calcule a taxa de sobrepreço antes de fazer upgrade, guarde evidências antes de pedir reembolso: envie juntos a saída bruta dos três benchmarks, o %steal do vmstat e a captura de tela do numactl --hardware; no ticket, escreva apenas dados, não adjetivos, e a chance de reverter é muito maior. Rode o mesmo teste antes de renovar, para evitar que a renovação reduza a configuração sem aviso. A tabela completa de coleta de evidências e o modelo de ticket estão em /guides/memory-bandwidth-checklist, e podem ser copiados diretamente.

Lembre-se da conclusão: capacidade dentro do padrão não significa largura de banda dentro do padrão. Use STREAM mais Steal Time e vinculação NUMA para fazer uma verificação cruzada, e então compare com a taxa de sobrepreço para decidir se faz upgrade ou pede reembolso.