Benchmark des serveurs cloud et specs gonflées : identifier et éviter les pièges des vieux CPU

Trois preuves pour démasquer le mensonge de la prime des vieux CPU

Mis à jour 2026-08-25 · CloudWorth

benchmarkspecs gonfléesSteal Timesurventerapport qualité-prixCloudWorthSurvente VPSBenchmark VPS

Triple vérification avec Steal Time, cache disque et benchmark réel : refusez de payer la prime pour les vieux CPU.

À quel point les benchmarks réels diffèrent des spécifications annoncées

L'écart entre les performances réelles d'un serveur cloud et sa configuration annoncée est souvent plus grand qu'on ne l'imagine. En particulier pour les anciens CPU vantant une « haute fréquence », comme les Xeon E5-2690 v4 et E5-2680 v4 datant d'environ 2016 : la fréquence monocœur paraît élevée, mais un test réel montre que le score monocœur peut n'être que la moitié de celui d'un Xeon de génération récente. Les causes principales de ces benchmarks « gonflés » sont deux : la différence de génération matérielle, et la flambée du Steal Time due à la surallocation.

Après virtualisation d'une ancienne plateforme, le champ steal dans /proc/stat vous indique le temps CPU volé par l'hyperviseur. Si mpstat -P ALL 1 affiche un %steal supérieur à 10 % sur une période prolongée, cela signifie qu'un voisin rivalise avec vous pour les ressources ; dans ce cas, quel que soit le niveau annoncé, les benchmarks sont instables. Un autre indicateur discret est le décrochage du cache disque — avec un ancien CPU équipé d'un ancien stockage, une fois le cache épuisé, les IOPS chutent de moitié et la courbe de benchmark présente une chute nette.

Pour quantifier l'écart, vous pouvez exécuter yabs ou sysbench cpu --threads=1 run et comparer avec les spécifications officielles. J'ai rencontré une ancienne plateforme annoncée à 3,5 GHz dont le score monocœur réel était 40 % inférieur à celui d'une nouvelle plateforme à 2,9 GHz. Autrement dit, pour votre argent dépensé en « haute fréquence + ancienne configuration », la moitié pourrait n'être qu'une prime pour du matériel d'occasion. C'est précisément le coût négatif le plus typique en FinOps : pour le même budget, choisir une nouvelle plateforme ou une instance certifiée officiellement donne un coût par unité de calcul plus faible.

Ne vous fiez donc pas uniquement aux spécifications annoncées. Je vous conseille de filtrer les instances dans CloudWorth selon les benchmarks réels et les seuils de Steal Time, et de dépenser votre budget pour de la véritable performance.

Steal Time pour démasquer la surréservation

Pour repérer la fausse configuration des serveurs cloud, la première étape consiste à surveiller le steal time. Cet indicateur est le clin d'œil de l'hyperviseur : lorsque le CPU physique est attribué par le propriétaire à la machine virtuelle voisine, votre vCPU n'a plus qu'à attendre. Utilisez top, appuyez sur C pour accéder à la liste des CPU, puis sur t pour voir la colonne steal, ou exécutez directement vmstat 1 pour observer le champ st. Échantillonnez pendant quelques minutes : si la moyenne de st dépasse 5 %, voire avec des pics à 20 % et plus, félicitations, vous partagez le même cœur physique avec une bande de voisins hostiles.

# 连续采样 10 次，每次间隔 1 秒，取 st 平均值
vmstat 1 10 | awk 'NR>3 {sum+=$16} END {print "avg steal:", sum/(NR-3), "%"}'

Les pics de Steal Time sont plus alarmants qu'une valeur élevée stable — ils indiquent que la surréservation est dynamique et que, aux heures de pointe, votre temps de réponse aura des à-coups aléatoires, comme un électrocardiogramme. Combiné à la chute brutale du cache disque mentionnée dans la section précédente, cela confirme qu'il s'agit d'un ancien hôte, sous-loué à répétition sur une machine physique vieillissante.

D'un point de vue FinOps, c'est une fraude sur la prime typique : vous payez le prix du matériel neuf, mais vous recevez les restes d'un vieux CPU découpé, avec une prime qui frôle le triple de celle du cloud public. Ne vous laissez pas aveugler par la fréquence élevée ; même si un vieux Xeon a un cœur puissant, il ne résiste pas aux empiétements de son voisin. Avant de lancer un benchmark, vérifiez d'abord le steal ; sinon, même si les chiffres Geekbench sont impressionnants, ce n'est qu'un mirage sur le champ de la surréservation. Cet indicateur est gratuit, reproductible et plus honnête que toutes les promesses des fournisseurs.

Enquête sur le gouffre du cache disque

Précédemment, nous utilisons Steal Time pour détecter la sur-vente, mais certains anciens centres de données lissent fortement l'ordonnancement du CPU, rendant les données Steal plutôt acceptables. Dans ce cas, ne vous précipitez pas à conclure — tournez votre attention vers le cache disque, qui est l'un des matériels les moins susceptibles de mentir.

En pratique, j'ai l'habitude d'exécuter fio deux fois de suite : d'abord une écriture bufferisée avec le cache de pages, puis une écriture directe contournant le cache. Les commandes ressemblent à ceci :

# Première passe : écriture bufferisée (utilise le cache mémoire)
fio --name=cache-test --rw=write --bs=1M --size=2G --direct=0 --ioengine=libaio --runtime=30 --time_based

# Deuxième passe : écriture directe (contourne le cache, écrit directement sur disque)
fio --name=direct-test --rw=write --bs=1M --size=2G --direct=1 --ioengine=libaio --runtime=30 --time_based

Concentrez-vous sur le « ratio de chute brutale » entre les deux valeurs. Pour un nouveau disque cloud NVMe, l'écriture directe représente environ 60 % à 80 % de l'écriture bufferisée ; pour un ancien disque mécanique ou un stockage partagé, l'écriture directe peut chuter en dessous de 10 %. Si la vitesse annoncée est de 2000 Mo/s, mais que l'écriture directe n'atteint que 150 Mo/s, c'est un cas typique de rupture de cache — les données vous trompent d'abord, et le disque révèle la vérité.

Cette preuve doit être examinée parallèlement au Steal Time. Un Steal élevé indique que vos voisins monopolisent le CPU, tandis qu'un gouffre de disque indique que le canal de stockage est également saturé — en combinant ces deux indices, on peut quasiment conclure à une sur-vente, et pas une sur-vente ordinaire, mais celle où le matériel sous-jacent est complètement obsolète.

Du point de vue FinOps, ces machines devraient être facturées à leur « valeur résiduelle ». Si la prime correspondant à la configuration annoncée dépasse 30 % par rapport à une nouvelle machine, négociez directement ; si vous ne parvenez pas à négocier, changez de fournisseur. Après tout, vous payez pour des spécifications, pas pour un mirage sur le cache. Pour une liste complète des pièges à éviter, consultez Guide d'auto-vérification des spécifications gonflées des serveurs cloud.

Arbre de décision sur la prime et les pièges à éviter

Quand vous recevez un serveur cloud avec un « vieux CPU à haute fréquence », ne vous précipitez pas pour payer. Calculez d'abord le taux de prime : (paiement mensuel réel - prix du marché d'un nouveau CPU à configuration équivalente) / prix du marché d'un nouveau CPU à configuration équivalente. Si la prime dépasse 30 %, vous pouvez pratiquement conclure que vous payez une taxe sur la crédulité pour du matériel retraité. Une approche plus agressive consiste à quantifier directement d'un point de vue FinOps : avec le même argent, pouvez-vous obtenir un AMD EPYC avec 2 fois plus de cœurs ou un nouvel Intel de 3 ans ? Si oui, cet achat ne devrait pas être validé.

Ensuite, suivez mon arbre de décision en trois étapes de vérification :

1. Steal Time pour détecter les mauvais voisins

   vmstat 1 10 | awk '{print $17}'  # 看 st 列

Si la moyenne de st sur des échantillons consécutifs est > 5 %, ou si des pics supérieurs à 20 % apparaissent, l'hôte est gravement sur-engagé et le temps CPU est volé par les voisins ; réduire la configuration est la seule façon de limiter les pertes.

1. Test de chute du cache disque

   dd if=/dev/zero of=/tmp/test bs=1M count=1024 conv=fdatasync

La première écriture en cache atteint 1,5 Go/s, la seconde chute à 150 Mo/s, le cache se vide : c'est un cas typique de sur-engagement du stockage partagé. Vieille configuration + chute du disque = double fausse spécification.

1. Comparaison de vrais benchmarks

   curl -sL yabs.sh | bash

Score Geekbench 5 monocœur inférieur à 700, mais fréquence annoncée à 3,5 GHz ? Apportez directement ce rapport au support client pour demander un remboursement de la différence de prix avec un nouveau CPU 4 cœurs ou une migration.

Enfin, une règle stricte : toute page marketing annonçant « haute performance » mais ne fournissant pas de lien de benchmark avant la vente doit être traitée comme une fausse spécification. Ne vous fiez qu'à vos propres benchmarks et ne payez la prime que pour un nouveau CPU.