Je n'écris pas ceci comme un avis négatif sur AVA Hosting.
C'est simplement une de mes journées de développeur : un serveur se comporte mal, les explications évidentes ne collent pas, puis Linux finit par montrer ce qui se passe réellement.
J'avais un petit VPS KVM chez AVA Hosting avec :
1 vCPU
2 GB RAM
25 GB NVMeUne charge de production normale y tournait. Nginx fonctionnait. Le backend fonctionnait. Il restait de la mémoire disponible. Le disque n'était pas plein.
Et pourtant, le serveur n'arrivait pas à suivre.
J'ai donc effectué une observation passive de 60 secondes sous trafic de production normal. Aucun stress test, aucun flood HTTP synthétique, aucun benchmark disque.
Résultat :
vCPU count: 1
Average CPU user: 52.52%
Average CPU system: 8.07%
Average CPU softirq: 6.69%
Average CPU steal: 32.73%
Average CPU iowait: 0.00%
Average CPU idle: 0.00%
Maximum runnable queue: 11La valeur décisive était 32,73 % de CPU steal. À partir de là, le diagnostic a complètement changé.
Pourquoi cela m'a surpris
AVA Hosting présente actuellement son offre VPS avec la formule “Guaranteed resources — no sharing”. Ses pages VPS parlent également d'une allocation vCPU fixe ou dédiée et indiquent que les performances ne devraient pas être affectées par les autres clients. Dans sa documentation Linux VPS, AVA va plus loin : une charge CPU intensive d'un autre tenant sur le même hôte ne pourrait pas introduire de steal time dans votre instance. Une autre page affirme que le CPU steal est éliminé au niveau de l'hyperviseur.
Ce sont des affirmations très précises. Il ne s'agissait pas simplement d'une page indiquant 1 vCPU sans préciser le modèle d'allocation CPU. AVA annonçait explicitement une protection contre exactement le type de contention CPU que Linux semblait mesurer dans ma VM.
Ce que signifie CPU steal
steal est une métrique CPU normale de Linux dans les environnements virtualisés. Elle représente le temps pendant lequel le système invité avait du travail exécutable, mais où le CPU virtuel ne s'exécutait pas réellement.
C'est différent d'une application qui consomme simplement toute sa capacité CPU. Si j'avais observé environ 100 % en user/system, 0 % en steal et 0 % en idle, j'aurais conclu que ma charge avait simplement besoin de davantage de puissance de calcul.
À la place, environ un tiers du temps CPU comptabilisé apparaissait en steal.
Depuis la VM, je ne peux pas voir l'hyperviseur d'AVA. Je ne connais ni la charge du nœud physique, ni le nombre de VM voisines, ni la politique de CPU pinning, ni le taux d'overcommit. Ce que je peux voir, c'est ce que Linux signalait à ma VM : le vCPU cessait régulièrement de s'exécuter alors que du travail attendait.
Ce n'était pas un pic d'une seconde
Une seule mauvaise mesure CPU ne m'aurait pas convaincu. J'ai donc observé la machine en continu pendant 60 secondes. Je n'ai volontairement lancé ni stress test, ni flood HTTP synthétique, ni benchmark disque.
Les échantillons seconde par seconde ressemblaient régulièrement à ceci :
%usr %sys %soft %steal %idle
53.54 10.10 5.05 31.31 0.00
56.44 6.93 5.94 30.69 0.00
51.52 7.07 6.06 35.35 0.00
55.45 6.93 5.94 31.68 0.00
51.49 8.91 5.94 33.66 0.00
52.53 7.07 7.07 33.33 0.00
52.48 6.93 7.92 32.67 0.00Vers la fin de l'observation, le même schéma était toujours présent :
50.98 10.78 6.86 31.37 0.00
48.48 8.08 9.09 34.34 0.00
55.00 5.00 7.00 33.00 0.00La moyenne complète était :
user: 52.52%
system: 8.07%
softirq: 6.69%
steal: 32.73%
iowait: 0.00%
idle: 0.00%Ce n'était donc pas une brève anomalie de scheduling. Pendant la majeure partie de la minute, le steal restait autour de 30 % ou davantage, tandis que le CPU idle restait à zéro.
Pour donner une idée, 32,73 % d'une minute correspondent à environ 19,64 secondes. Cela ne signifie pas que le VPS s'est figé pendant 19,64 secondes d'affilée : les petits intervalles pendant lesquels le vCPU n'était pas planifié se sont simplement cumulés jusqu'à cette durée approximative.
Le backend n'arrivait pas à rattraper son retard
Le problème CPU était également visible au niveau applicatif. Avant la mesure, la file d'écoute du backend affichait :
Recv-Q: 168
Send-Q: 511Après 60 secondes :
Recv-Q: 166
Send-Q: 511Les chiffres exacts importent peu. Ce qui compte, c'est que la file ne se vidait pratiquement pas. L'application avait une minute entière pour rattraper son retard et restait pourtant en difficulté.
Il y avait également beaucoup de connexions CLOSE-WAIT. Je n'attribuerais pas ce seul état à l'hôte, car la gestion des connexions côté application peut aussi en être responsable. Mais l'ensemble était cohérent :
1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not drainingLe serveur était vivant, mais pas en bonne santé.
La RAM et le disque n'étaient pas les goulots d'étranglement évidents
J'ai vérifié les causes habituelles. Côté mémoire :
RAM total: ~1.9 GiB
RAM available: ~959 MiB
Swap total: 2 GiB
Swap used: ~33 MiBIl restait donc une quantité importante de mémoire disponible, sans événement OOM évident permettant d'expliquer le comportement.
Côté système de fichiers :
24 GB total
14 GB used
9.4 GB available
60% usedLe CPU I/O wait moyen était de 0.00%. Dans le même temps, la pression CPU restait proche de 99 %, le load average tournait autour de 3,5–4 sur une VM à un seul vCPU, et la runnable queue montait jusqu'à 11.
Toutes ces mesures indiquaient la même chose : la machine manquait de temps CPU, sans être manifestement bloquée par la RAM ou le stockage.
La contradiction avec le discours d'AVA
C'est la partie que je trouve la plus intéressante.
AVA affirme “Guaranteed resources — no sharing”. Les performances ne devraient pas être affectées par d'autres clients. Sa documentation Linux VPS indique qu'un autre tenant ne peut pas provoquer de steal time, et une autre page affirme que le CPU steal est éliminé au niveau de l'hyperviseur.
Mon VPS AVA affichait pourtant :
Average CPU steal: 32.73%Depuis l'intérieur de la VM, je ne peux pas prouver exactement pourquoi cela s'est produit. Je ne peux pas démontrer un overselling volontaire, identifier une charge voisine précise ni reconstruire la configuration CPU côté hôte d'AVA.
Je ne prétends pas non plus que tous les VPS d'AVA Hosting se comportent ainsi. J'en ai testé un.
Mais je peux dire que le comportement que j'ai mesuré est très difficile à concilier avec ces affirmations précises sur l'isolation CPU. Cela suffit pour cet article.
Pourquoi je n'ai pas simplement pris une offre supérieure
La réaction évidente aurait été d'acheter davantage de vCPU.
Si le VPS avait affiché pratiquement zéro steal et si mon application avait simplement saturé un cœur entier, une montée en gamme aurait été logique. Ici, environ un tiers du temps CPU observé était du steal.
Je ne voulais pas payer pour davantage de CPU virtuels avant de comprendre pourquoi une part aussi importante du temps d'exécution du premier vCPU était déjà signalée comme indisponible. J'ai donc annulé le VPS et demandé un remboursement.
AVA a remboursé la totalité rapidement
Cette partie de l'expérience s'est bien passée.
AVA Hosting m'a remboursé l'intégralité du montant. Le remboursement a été traité rapidement et ils n'ont pas passé des jours à contester mes mesures CPU. J'ai expliqué le problème, demandé mon argent, et ils me l'ont rendu.
Je l'apprécie.
Mon expérience aboutit donc à deux conclusions distinctes : le VPS que j'ai reçu avait un sérieux problème de disponibilité CPU, et AVA a correctement géré mon remboursement. Les deux sont vraies.
Ce que j'en retiens
Je ne juge plus un VPS uniquement sur une fiche technique du type 1 vCPU / 2 GB RAM / NVMe / KVM. Ces chiffres indiquent ce qui a été provisionné, pas à quel point le CPU sera disponible de façon prévisible sous une charge réelle.
Désormais, parmi les premières choses que je vérifie sur une nouvelle VM :
mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60La leçon la plus utile de mon expérience avec AVA Hosting n'est pas qu'un seul vCPU est forcément insuffisant. C'est qu'un processus actif, de la RAM disponible et un disque apparemment sain peuvent masquer un problème complètement différent.
Dans mon cas, Linux l'a rendu particulièrement évident :
CPU steal: 32.73%
CPU idle: 0.00%
CPU pressure: ~99%AVA Hosting annonce des ressources CPU sans partage et affirme que les charges voisines ne devraient pas provoquer de steal. Mon VPS a rapporté autre chose.
Je l'ai annulé. AVA m'a remboursé intégralement, rapidement et sans discussion.
Et cette journée de débogage s'est terminée là.