Réponse rapide
Qu'est-ce que le CPU steal time et comment le vérifier sur mon VPS ?
Le CPU steal time est la part du temps où votre vCPU était prêt à s'exécuter pendant que l'hyperviseur faisait tourner une autre machine ; à 10 % de steal, une tâche chargée perd environ un dixième de son temps. Au 2 novembre 2026, aucun des 22 hébergeurs crypto sans KYC promettant du CPU dédié ne publiait de mesure de steal, et Cobaltfell non plus. Linux affiche le steal sous la forme st dans top et %steal dans mpstat.
Qu'est-ce que le steal time exactement ?
Le steal time compte les moments où votre processeur virtuel voulait travailler et où le processeur physique était occupé par un autre invité. Les outils Linux le décrivent de trois façons légèrement différentes :
top: « time stolen from this vm by the hypervisor ».mpstat: le pourcentage d'« involuntary wait » pendant que l'hyperviseur « was servicing another virtual processor »./proc/stat: « the time spent in other operating systems when running in a virtualized environment », compté depuis Linux 2.6.11.
La documentation KVM du noyau ajoute le détail qui rend le compteur utile : le steal est le temps pendant lequel le vCPU n'a pas tourné, et le temps pendant lequel le vCPU est inactif n'est pas compté comme du steal. Un VPS inactif ne peut pas afficher de steal, aussi chargé que soit l'hôte. Le chiffre n'apparaît que lorsque vous demandez du CPU et que vous ne l'obtenez pas.
La valeur vient de l'hyperviseur, qui la partage avec le noyau invité. Un invité ne peut compter que ce que l'hyperviseur lui rapporte, ce qui est une raison de plus de confirmer une valeur basse par un benchmark répété.
Comment vérifier le steal time ?
Quatre commandes l'affichent ; lancez-les pendant que votre charge réelle tourne, pas sur une machine inactive. top et vmstat sont fournis avec le paquet procps sur toutes les distributions courantes. mpstat est fourni avec sysstat (apt install sysstat sur Debian et Ubuntu, dnf install sysstat sur AlmaLinux et Rocky).
topvmstat 1 60mpstat -P ALL 1 60a=($(head -n1 /proc/stat)); sleep 10; b=($(head -n1 /proc/stat))
# fields 1-8: user nice system idle iowait irq softirq steal
all=0; for i in 1 2 3 4 5 6 7 8; do all=$((all + b[i] - a[i])); done
awk -v st=$((b[8] - a[8])) -v all=$all 'BEGIN { printf "steal: %.2f%%\n", 100 * st / all }'La première ligne de /proc/stat additionne tous les vCPU, en unités de USER_HZ (un centième de seconde sur la plupart des systèmes). Le script la lit deux fois, à dix secondes d'intervalle, et divise le steal accumulé par tout le temps écoulé. Pour confirmer que vous êtes bien sur une machine virtuelle, systemd-detect-virt affiche le type d'hyperviseur, kvm sur KVM.
Comment lire les chiffres ?
Aucune norme ne fixe une « bonne » valeur de steal, mais l'arithmétique est simple : une tâche qui a besoin du CPU en permanence obtient au plus 100 % moins le steal. À 5 % de steal, elle obtient environ 95 % du temps qu'elle demande ; à 25 %, environ les trois quarts. Lisez la tendance, pas un seul échantillon.
| Ce que vous voyez | Ce que cela signifie | Que faire |
|---|---|---|
| 0 sur chaque vCPU pendant que votre tâche tourne à pleine charge | Rien ne vous est pris, ou l'hyperviseur ne signale aucun steal | Confirmez avec le même benchmark à deux heures différentes |
| Quelques échantillons non nuls, puis 0 de nouveau | Contention brève sur l'hôte | En général rien ; gardez un journal si votre tâche est sensible à la latence |
| Un steal constant sous charge, chaque seconde | Votre vCPU fait la queue derrière d'autres invités | Notez les heures, mesurez sur une journée, envoyez le journal à l'hébergeur |
Du steal sur un seul vCPU dans mpstat -P ALL | Un de vos threads atterrit sur une partie plus chargée de l'hôte | Mentionnez le numéro du vCPU dans votre ticket |
| Un steal qui monte aux mêmes heures chaque jour | Des voisins avec un planning : sauvegardes, tâches par lots, pic de trafic | Décalez les tâches lourdes vers d'autres heures, ou passez au vCPU dédié |
| Un steal persistant sur une offre vendue comme dédiée | La promesse n'est pas tenue à ce moment-là | Demandez à l'hébergeur de s'expliquer ou de déplacer le VPS |
Mon CPU est-il partagé avec des voisins bruyants ?
Si le steal augmente quand vous chargez le CPU et que la hausse suit l'horloge plutôt que votre propre travail, d'autres locataires partagent votre temps processeur. Trois vérifications permettent de cerner le problème :
- Chargez-le vous-même. Lancez votre vrai travail, ou un test gourmand en CPU, et gardez
mpstat -P ALL 1ouvert dans un second terminal. Un steal qui suit votre charge indique que l'hébergeur a moins de CPU libre que votre offre ne le suggère. - Comparez les heures. Lancez le même benchmark le matin et le soir. Sur un vCPU dédié, les deux résultats devraient être proches ; comment benchmarker un VPS avec YABS ou Geekbench 6 donne les commandes.
- Lisez l'offre. Une offre vendue avec vCPU partagé a le droit d'afficher du steal ; c'est ce qui la rend moins chère. La page sur la différence entre un vCPU partagé et un vCPU dédié explique ce que chacun apporte.
Un VPS lent avec un steal à zéro désigne autre chose : attentes disque (la colonne wa, temps d'attente des I/O), pression mémoire ou l'application elle-même.
Qu'est-ce qui cause le steal time, et comment y remédier ?
Le steal augmente quand l'hébergeur a vendu plus de vCPU actifs qu'il n'a de threads matériels pour les exécuter. Quand tous les invités demandent du CPU en même temps, certains doivent attendre, et cette attente est comptée comme steal chez chacun d'eux.
Ce que vous pouvez faire, du moins au plus d'effort :
- Déplacer le gros du travail vers des heures où l'hébergeur est plus calme, si votre charge le permet.
- Demander à l'hébergeur de déplacer votre VPS vers un nœud moins chargé ; un journal de
mpstatrend la demande concrète. - Changer de type d'offre. Un vCPU dédié retire les autres invités de vos threads. Les hébergeurs qui en vendent, avec les termes employés par chacun et le prix par cœur, sont listés dans ce que coûte un VPS CPU dédié par cœur en novembre 2026.
Selon l'enquête de Cobaltfell du 2 novembre 2026, 22 hébergeurs VPS sur 51 qui acceptent la crypto sans pièce d'identité promettaient par écrit un CPU dédié, et aucun d'eux n'affichait de mesure du steal time sur les pages que nous avons lues.
Ajouter du vCPU partagé aide rarement : plus de threads issus du même hébergeur surchargé attendent dans la même file.
Sur une base de données, le steal se voit d'abord dans les requêtes les plus lentes, comme expliqué dans comment le CPU steal affecte la latence p99 de PostgreSQL sur un VPS.
Quel steal un VPS Cobaltfell devrait-il afficher ?
Sur un vCPU dédié, le steal time devrait être nul ou proche de zéro. Nous publierons la valeur que nous mesurons sur nos propres machines, avec sa date, et jamais une estimation. Chaque vCPU est réservé à un seul VPS : Un vCPU correspond à un thread matériel du processeur hôte. Les vôtres sont épinglés un à un à votre VPS et ne sont jamais prêtés à un autre client, et les deux threads d'un cœur physique restent ensemble : ainsi, chaque 2 vCPU forment un cœur entier que nul voisin ne partage.
Nos propres résultats YABS et Geekbench 6, ainsi que le steal time que nous mesurons, seront publiés avec leur date dès la livraison de notre première machine de test. D'ici là, nous ne citons aucune performance de notre cru. Tant que cette page ne porte pas de chiffre daté, lancez les commandes ci-dessus sur votre propre VPS ; si le steal reste élevé pendant que votre travail tourne, le journal suffit pour un ticket. Les meilleurs fournisseurs de VPS CPU dédié en 2026 sont comparés sur les mêmes critères écrits, le nôtre compris. Une personne répond aux e-mails du support sous 12 heures, sept jours sur sept, y compris pour l'aide sur les clés SSH, les réinstallations et les règles de pare-feu.
Quelles autres questions se posent sur le steal time CPU ?
Le steal time est-il la même chose que l'iowait ?
Non. Le steal (st) est le temps pendant lequel votre vCPU voulait s'exécuter mais où l'hyperviseur a exécuté un autre invité. L'iowait (wa) est le temps pendant lequel le CPU est resté inactif à attendre le disque ou d'autres I/O. Un iowait élevé pointe vers le stockage, un steal élevé vers la contention CPU.
Pourquoi top n'affiche-t-il pas de valeur st ?
Le manuel de top signale que le champ st peut ne pas être affiché selon la version du noyau. Sur les distributions actuelles, il apparaît dans la ligne %Cpu(s) ; sur un vieux noyau ou hors d'une machine virtuelle, il peut manquer ou rester à zéro.
Un serveur dédié peut-il afficher du steal time ?
Un système qui tourne directement sur le matériel, sans hyperviseur en dessous, n'a personne pour lui voler du temps ; le compteur reste donc à zéro. Le steal n'existe que pour un invité exécuté sous un hyperviseur.
Quelle valeur de steal est trop élevée ?
Aucune norme ne fixe de limite. Faites le calcul : à 10 % de steal, un travail gourmand en CPU obtient environ 90 % du temps dont il a besoin. Sur une offre vendue avec vCPU dédié, le steal devrait rester à zéro ou proche de zéro pendant que vous travaillez.
Le steal time affecte-t-il la latence autant que le débit ?
Oui. Chaque attente retarde la requête qui s'exécutait sur ce vCPU ; le steal apparaît donc d'abord dans les requêtes les plus lentes, le p99 d'une base de données ou d'une API, avant de déplacer la moyenne.
Sources (6)
- MSR spécifiques à KVM : MSR_KVM_STEAL_TIME — The Linux Kernel documentation (checked 2026-11-02)
- proc_stat(5) : statistiques noyau/système — man7.org (Linux man-pages 6.19) (checked 2026-11-02)
- page de manuel top(1) — man7.org (procps-ng) (checked 2026-11-02)
- page de manuel vmstat(8) — man7.org (procps-ng) (checked 2026-11-02)
- page de manuel mpstat(1) — man7.org (sysstat) (checked 2026-11-02)
- page de manuel systemd-detect-virt(1) — man7.org (systemd) (checked 2026-11-02)