Détecter la survente de l'EC2 du cloud public avec Steal Time

Deux mesures pour révéler la vérité de la survente

Mis à jour 2026-09-01 · CloudWorth

Steal Timedétection de surventeECSFinOpspreuveCloudWorthSurvente VPSBenchmark VPS

Un Steal Time élevé indique que le CPU est survendu ; combiné au gouffre de cache et au taux de prime, il permet de recueillir des preuves et de faire valoir vos droits.

Deux règles pour détecter la surallocation

Pour juger si une instance EC2 de cloud public est surallouée, on ne peut pas se fier uniquement au taux d'inactivité du CPU, car l'inactivité dans la VM ne signifie pas que la machine physique n'est pas occupée. La première règle est Steal Time (steal%), qui vous indique directement : le temps CPU qui aurait dû vous être alloué a été discrètement détourné par l'hôte au profit d'un voisin gourmand. Lorsque steal% dépasse 10% en continu, on peut fondamentalement suspecter que l'hôte est en surallocation.

Mais regarder steal ne suffit pas—certaines instances (comme la série t d'AWS) ont un mécanisme de crédits CPU, et un steal élevé pendant les pics peut simplement être dû à l'épuisement des crédits. C'est là qu'intervient la deuxième règle : la chute de cache disque. Les hôtes suralloués supportent souvent de nombreuses requêtes IO. Lorsque vous utilisez fio pour tester des lectures aléatoires, le taux de hit du cache de pages ou la latence peuvent chuter brutalement, ce qui coïncide fortement dans le temps avec le steal CPU. Les deux règles se corroborent mutuellement pour former des preuves complètes.

Vous voulez un test rapide ? Nous avons précédemment compilé un script de détection de surallocation de serveur cloud, qui peut directement générer les métriques steal et cache pour vous aider à éviter les pièges avant l'achat.

Tests et preuves sur instances réelles

Nous effectuons un test comparatif entre les dernières instances Alibaba Cloud ECS g9i et AWS EC2 m7i. Le script de charge est fixe : stress-ng --cpu 4 --timeout 300, avec un échantillonnage de steal% toutes les 5 secondes via mpstat ; puis on exécute une lecture aléatoire 4K avec fio pour enregistrer les IOPS et la latence p99.

# CPU steal 采样
mpstat -P ALL 5 > steal.log &
# 磁盘 cache 断崖测试
fio --name=cachetest --rw=randread --bs=4k --size=1G --runtime=120 --iodepth=32

Dans nos tests, pendant les heures de pointe en journée, la moyenne de steal du g9i atteint 12.4%, avec un pic à 18.1%. La latence p99 de fio passe de 0.8ms à 12ms, révélant une chute de cache évidente. Pendant la même période, le steal du m7i reste stable sous les 2%, avec une latence lisse. Remarque : pour les instances burstables bas de gamme comme la série t, il est normal que le steal dépasse occasionnellement 10%, mais si les instances optimisées pour le calcul comme la série m ou g9i dépassent ce seuil en continu, c'est la preuve concrète de surprovisionnement.

Points clés pour la collecte de preuves : enregistrez l'horodatage de chaque échantillon, l'ID d'instance, la version de l'image, et capturez les données brutes de CloudWatch / Cloud Monitor. Ces journaux et captures d'écran sont les preuves principales pour les tickets ultérieurs.

Taux de surcoût et recours

Le plus difficile à détecter dans la survente : vous payez une prime, mais vous n'obtenez qu'une puissance de calcul incomplète. D'un point de vue FinOps, le rapport qualité-prix réel = prix unitaire ÷ temps CPU effectif. Le temps effectif peut être estimé avec la formule : heures-cœurs disponibles = nombre de vCPU × (1 - steal% moyen) × durée.

Exemple : le g9i à 1,2 yuan/heure (4 vCPU), avec un steal moyen de 15 %, ne fournit que 3,4 vCPU·h effectifs, ce qui augmente le coût réel par vCPU effectif de 17,6 %. En comparaison, le m7i de même spécification n'est pas survendu, et le taux de surcoût se retrouve inversé par la « taxe de survente » — cela signifie souvent que vous payez plus cher pour un service de moins bonne qualité.

Après avoir rassemblé les preuves, le recours ne repose pas sur une simple plainte pour « lenteurs ». Préparez un PDF contenant : le graphique de la série temporelle du steal%, la sortie de fio montrant la chute brutale du cache, le tableau comparatif avec d'autres instances de mêmes spécifications, ainsi que le calcul du taux de surcoût. Lors de la soumission du ticket, exigez clairement « une réduction de la configuration ou un remboursement de la différence basé sur la puissance de calcul effective mesurée ». Alibaba Cloud et AWS ne reconnaissent généralement pas la survente, mais face à des données concrètes, ils proposent des crédits ou une compensation par mise à niveau en invoquant « la contention des ressources de l'hôte ». Avant d'acheter votre prochaine instance cloud, mesurez avec deux règles, ne laissez pas votre prime acheter une survente.