Détection de bande passante mémoire sur serveur cloud : pourquoi le débit chute malgré une capacité conforme

Une capacité suffisante ne signifie pas une bande passante suffisante ; seule une triple analyse forensique permet d'y voir clair.

Mis à jour 2026-10-07 · CloudWorth

bande passante mémoireSTREAMNUMAdétection de surventeFinOpsCloudWorthSteal TimeSurvente VPSBenchmark VPS

Une capacité conforme n'égale pas une bande passante conforme. Utilisez STREAM avec Steal Time et la liaison NUMA en contre-expertise, puis comparez au taux de surcoût pour décider d'un upgrade ou d'un remboursement.

Testez d'abord la capacité, puis la bande passante

Lors de l'achat d'un serveur cloud, presque tout le monde regarde d'abord la capacité mémoire : 8 Go, 16 Go, 32 Go. La capacité figure sur la page de commande, elle est visible et vérifiable, et on la considère donc par défaut comme « sans problème ». Mais la capacité n'est que la surface de l'entrepôt ; la bande passante est la vitesse du chariot élévateur — une instance de 8 Go peut parfaitement avoir une capacité entièrement au vert alors que son débit mémoire n'atteint que la moitié de la valeur nominale de sa génération.

C'est le scénario classique où la capacité est conforme mais le débit chute : pour des charges comme l'inférence IA, la recherche vectorielle, les grandes valeurs Redis ou la copie dans le tas JVM, la sensibilité aux Go/s est bien plus forte qu'aux Go ; une capacité suffisante se heurte alors d'abord au plafond de bande passante.

Commencez par séparer deux étapes :

1. Côté capacité : free -h pour voir total/available, puis comparez avec les spécifications de la commande pour confirmer qu'il n'y a pas eu de récupération par un pilote balloon caché. Sous KVM, vous pouvez vérifier avec dmesg | grep -i balloon.
2. Côté bande passante : une capacité conforme ne garantit pas une bande passante conforme ; il faut un test dédié au débit mémoire, que nous détaillons dans la section suivante.

L'ordre doit être : d'abord la capacité, ensuite la bande passante. Si la capacité n'est pas conforme, c'est une fausse déclaration : demandez directement le remboursement. Si la capacité est conforme mais que la bande passante chute, il s'agit d'un problème plus discret de survente / limitation de débit, qui nécessite la chaîne de preuves ci-dessous.

Un critère empirique : si vous achetez une instance « de capacité équivalente mais à un prix nettement inférieur », considérez par défaut que la bande passante est suspecte, plutôt que de supposer avoir fait une bonne affaire. Ce type de bon marché provient souvent d'une surallocation CPU, d'une disposition NUMA inter-nœuds ou d'un abaissement de la fréquence mémoire, et finit par se retourner sous la forme d'un taux de prime sur le rapport performance/prix — vous avez payé la capacité, mais pas le débit.

Après avoir enregistré les données brutes (spécifications de l'instance, région, image, type de facturation, heure de commande), passez aux tests réels. Cet enregistrement constitue la preuve pour les futurs tickets et les décisions de réduction de configuration ; un ticket indiquant seulement « la mémoire est très lente » n'aura presque jamais de traitement efficace.

Mesures réelles avec STREAM et sysbench

Le test de bande passante mémoire dispose de deux outils complémentaires : STREAM mesure le débit vectoriel soutenu (Copy/Scale/Add/Triad), tandis que sysbench memory mesure des scénarios plus proches de « petites lectures/écritures par blocs ». Le débat sysbench vs STREAM memory bandwidth test for cloud servers n'a pas de sens : il faut exécuter les deux, car leurs biais vont dans des directions différentes : STREAM est trop favorable au cache L3 des petites instances, sysbench est trop sensible au coût des instructions ; seul un recoupement permet d'éviter de se faire tromper par un chiffre isolé.

Utilisation de STREAM (compilation possible dans le répertoire home sans 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

Réglez la taille du tableau entre 1/4 et 1/2 de la mémoire ; trop petite, elle tiendra entièrement dans le cache et donnera une « bande passante artificiellement élevée » ; sinon, vous mesurez le L3, pas la DRAM.

Côté 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

Trois critères d'évaluation :

• Mono-cœur vs tous les cœurs : exécutez séparément taskset -c 0 et tous les cœurs, et relevez les GB/s. Si le passage à tous les cœurs n'apporte presque rien, cela signifie que la bande passante est plafonnée, et non que le nombre de cœurs est insuffisant.
• Comparaison avec les valeurs annoncées : l'écart générationnel entre DDR4 et DDR5 est de l'ordre de 1,5 à 2 fois ; entre instances cloud de même génération et même fréquence, un écart de deux à trois fois ne devrait pas apparaître ; s'il apparaît, c'est anormal.
• Conversion en bande passante par vCPU : bande passante totale / nombre de vCPU est l'indicateur le plus pratique pour détecter une survente de bande passante mémoire. Les instances mutualisées n'ont souvent que la moitié de la bande passante par vCPU des instances dédiées, ce qui constitue l'une des véritables sources du taux de surcoût des serveurs cloud.

Exécutez trois fois et prenez la médiane, en évitant les pics de charge des voisins à l'heure pile. Pour convertir automatiquement ces chiffres en bande passante par vCPU et en taux de surcoût, vous pouvez créer un modèle dans /app, y saisir ensemble STREAM, sysbench et le prix de l'instance, et générer un profil coût-performance comparable. La section suivante utilise Steal Time et NUMA pour attribuer la « perte de vitesse » à des causes précises.

Steal Time et analyse forensique NUMA

La section précédente ne prouve qu'une chose : « ça a ralenti ». L'attribution nécessite deux autres indicateurs : Steal Time et la topologie NUMA. C'est aussi la couche la plus souvent ignorée dans la détection de bande passante mémoire des serveurs cloud — la capacité est suffisante, un test isolé est conforme, mais le goulot d'étranglement se cache dans l'ordonnancement et l'affinité mémoire. Les pages de configuration nominale n'indiquent jamais ces deux éléments, et l'écart des scores réels vient souvent de là.

Regardons d'abord st :

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

Un st durablement >3 % et synchronisé avec la baisse de bande passante indique que le temps vCPU est emprunté par les voisins. Sur un KVM mutualisé, la corrélation entre le CPU steal et la bande passante mémoire est très élevée : c'est toute la chaîne qui est affectée, pas seulement la puissance de calcul.

Passons à 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

Si lier le processus au nœud local fait nettement remonter la bande passante, il s'agit d'une pénalité inter-nœuds (souvent 20 % à 40 %), pas d'une surallocation ; si après liaison la bande passante reste collée au plafond par personne, c'est un vrai bridage.

Prenez trois captures d'écran — st, topologie NUMA, bande passante avant/après liaison — pour ouvrir un ticket : c'est bien plus efficace que de dire simplement « c'est devenu plus lent ». Pour en faire un modèle d'analyse forensique réutilisable, vous pouvez, dans /app, regrouper ces trois chiffres avec le prix unitaire que vous payez, calculer clairement le taux de surcoût, puis décider d'augmenter la configuration, de changer de zone de disponibilité ou d'engager une procédure de remboursement.

Vérification par falaise de cache disque

Après liaison NUMA, la bande passante reste collée au plafond ; il manque une dernière preuve : utiliser la falaise de cache pour séparer « mémoire lente » et « disque lent ». La méthode consiste à faire d'abord une lecture à chaud, puis une lecture à froid du même fichier, afin de voir à quelle taille d'ensemble de travail la bande passante s'effondre.

# 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

Points d'interprétation :

• La bande passante en lecture à froid diminue de façon régulière lorsque l'ensemble de travail passe de 256M à 4G ; c'est un comportement normal de la hiérarchie mémoire et de la prélecture ;
• Une chute en falaise (par exemple, une réduction de moitié autour de 2G), avec un point de rupture bien inférieur au L3/cache annoncé de l'instance, indique généralement que la bande passante mémoire est bridée, et non que le disque lâche en premier ;
• Regardez aussi bi/bo et si/so dans vmstat 1 ; si l'IO n'est pas élevé mais que le débit s'effondre, le problème vient presque sûrement du côté mémoire.

C'est aussi là que « benchmark réel vs configuration annoncée » dérape le plus souvent : une instance 8GB annoncée DDR4/DDR5 avec sa capacité n'a rien de faux, mais dès que le KV cache d'inférence IA ou la recherche vectorielle pousse l'ensemble de travail hors du cache, la bande passante chute d'abord, puis la latence se met à osciller. Mettez côte à côte le point de falaise, la bande passante avant/après liaison NUMA, %steal et le prix unitaire que vous payez réellement pour calculer le taux de surcoût, puis décidez s'il faut augmenter la configuration, changer de zone de disponibilité ou demander un remboursement : c'est bien plus efficace que de redémarrer en boucle. Si vous avez besoin d'un modèle de preuve prêt à l'emploi, vous pouvez l'appliquer directement dans /app.

En une phrase : atteindre la capacité annoncée n'est qu'un ticket d'entrée ; ce que la détection de bande passante mémoire d'un serveur cloud doit regarder, c'est où se situe le point de retournement de la chute de débit, et à quel prix vous continuez de payer après ce point.

Comparaison des benchmarks et décision de surcoût

Dans les parties précédentes, nous avons déjà obtenu trois ensembles de données objectives : Copy/Triad de STREAM, l'écart de bande passante avant/après épinglage NUMA, ainsi que la courbe %steal. Il ne reste plus qu'une étape : les aligner avec la facture. La méthode est simple : pour une même instance, écrivez « nominal vs mesuré » sur deux colonnes :

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

Les seuils d'interprétation peuvent être approximatifs, mais ils doivent être chiffrés :

• La bande passante mesurée atteint plus de 70 % des valeurs publiques de DDR4/DDR5 de la même génération, et %steal reste habituellement sous 2 % : mutualisation normale, continuez à l'utiliser ;
• La bande passante n'atteint que 50 % à 70 % de la valeur nominale attendue, et l'épinglage NUMA permet de récupérer 15 %+ : il s'agit d'un problème d'ordonnancement ; changer de zone de disponibilité ou spécifier l'affinité vCPU est souvent moins cher qu'une montée en configuration ;
• La bande passante est inférieure à 50 %, %steal reste durablement au-dessus de 5 %, et la chute brutale du Cache apparaît plus tôt que prévu : c'est le signal typique d'une survente VPS, une preuve concrète de détection de survente de serveurs cloud.

Calculez le rapport performance-prix avant d'envisager une action. Supposons qu'une instance de 8 Go coûte 120 yuans par mois et que sa bande passante mesurée n'atteigne que 60 % de celle d'une instance AMD EPYC au même prix : votre taux de surcoût est alors en réalité de 40 % — dans ce cas, passer à 16 Go ne fait souvent qu'amplifier le « prix plus élevé par Go » ; changer de type d'instance ou demander un remboursement est plus avantageux. Avant de mettre à niveau, calculez le taux de surcoût ; avant de demander un remboursement, conservez les preuves : soumettez ensemble les sorties brutes des trois benchmarks, %steal dans vmstat et une capture d'écran de numactl --hardware ; dans le ticket, n'écrivez que des données, pas d'adjectifs, et vos chances d'obtenir un revirement seront bien plus élevées. Exécutez les mêmes tests avant le renouvellement, pour éviter une baisse de configuration dissimulée au moment du renouvellement. Le tableau de collecte de preuves complet et le modèle de ticket se trouvent dans /guides/memory-bandwidth-checklist, et peuvent être copiés directement.

Retenez la conclusion : une capacité conforme ne signifie pas une bande passante conforme ; recoupez les preuves avec STREAM, Steal Time et l'épinglage NUMA, puis comparez avec le taux de surcoût pour décider entre montée en configuration et remboursement.