Une équipe base de données signale des latences disque « au-delà de 30 ms » et un import de dump qui plafonne. Côté Prism, rien d’alarmant. Ce billet ne livre pas de cause, le dossier n’est pas clos : il décrit la méthode qui a évité de conclure trop vite, dans un sens comme dans l’autre.
Deux points de mesure, deux latences
Côté invité, les DBA lisent iostat : w_await inclut le temps passé en file dans l’invité et le temps de service. Côté Nutanix, l’API v4 des stats VM donne controllerAvgWriteIoLatencyMicros, la latence moyenne mesurée au contrôleur de stockage. Dans l’architecture décrite par la Nutanix Bible, c’est le domaine de Stargate, le processus de la CVM qui traite toutes les I/O des VM, avec un vdisk controller par vdisk.
Sur des fenêtres proches (import : 25 minutes côté invité, 16 minutes côté contrôleur) :
- les volumes concordent : 63 contre 66 Mo/s en lecture, des écritures de 24,5 Ko contre 25 à 28 Ko pendant l’import ;
- les latences divergent : 8,45 ms invité contre 3,2 ms contrôleur sur la journée, 7,24 contre 4,55 ms pendant l’import, soit 1,6 à 2,6 fois plus.
Les deux outils voient les mêmes I/O, mais 2,7 à 5,3 ms se perdent entre le device de l’invité et le contrôleur. Une partie peut naître dans la VM elle-même, puisque l’await compte sa propre file. L’API expose aussi hypervisorAvgIoLatencyMicros (« average I/O latency of the VM ») : candidat pour couper ce trajet en deux, pas encore exploité ici.
Calculer la file avant de parler de saturation
La loi de Little relie nombre moyen en cours, débit et temps de séjour. Pour un disque :
QD = IOPS × latenceUne file moyenne sous 1 signifie qu’il n’y a pas d’attente : y invoquer un « plafond de parallélisme » est faux par construction. Sur le vdisk en cause, la file moyenne relevée tournait autour de 1,2. Mais au pic, il montait à une file d’environ 50 et 106 ms de latence d’écriture, pic invisible dans les métriques de l’hôte et du cluster. Calculez donc sur la moyenne et sur le pic. La loi porte sur des moyennes de long terme d’un système stationnaire : sur une fenêtre courte, prenez le résultat comme un ordre de grandeur.
Même piège de dilution : 4,2 ms en moyenne sur l’heure, 4,55 ms sur les 16 minutes de l’import. N’opposez jamais une moyenne horaire à une mesure de fenêtre.
MAX n’est pas un p99
Les « plus de 30 ms » étaient des maxima de graphe : 35,6 ms au pire pendant l’import, pour 7,24 ms de moyenne. Côté API, $statType choisit l’opérateur de sous-échantillonnage (SUM, MIN, MAX, AVG, COUNT, LAST). MAX garde l’échantillon le plus haut d’une série dont chaque point est déjà une moyenne. Aucun des deux n’est un percentile : exigez un p95 ou un p99 avant d’enquêter sur un pic.
Dater la doctrine
Premier réflexe : « un seul vdisk, donc un seul thread de contrôleur, donc plafond ». C’était vrai avant AOS 6.1. Depuis, le vdisk sharding répartit les I/O d’un vdisk entre plusieurs contrôleurs, jusqu’à 4 selon l’annonce de la version ; Nutanix a mesuré +78 % de taux de transactions sur un test HammerDB et SQL Server. Un guide de bonnes pratiques de 2019 qui argumente sur l’ancien modèle ne vaut plus comme preuve. Avant de citer une limite d’architecture, confrontez la date de la source à la version d’AOS déployée.
Comparer ce qui est comparable
Deux VM aux noms jumeaux étaient un primaire et un standby, sur deux sites et deux clusters : le standby écrit moins, la comparaison ne prouve rien. Le seul témoin recevable partage le cluster et le container.
Situez aussi la VM dans sa population : elle était au 86e centile de son cluster en latence d’écriture, et le « vdisk de données unique » qu’on s’apprêtait à lui reprocher était la configuration d’environ trois VM sur quatre. Imputer un symptôme à la norme, c’est condamner tout le parc.
Ce qu’il faut retenir
- Nommez le point de mesure de chaque latence : await invité, hyperviseur, contrôleur.
- Volumes concordants et latences divergentes : le temps se perd vraisemblablement en amont du contrôleur.
- Calculez
QD = IOPS × latencesur la moyenne et sur le pic. - Remplacez tout MAX par un percentile, ou annoncez-le comme un MAX.
- Datez la doctrine : depuis AOS 6.1, un vdisk n’est plus limité à un thread de contrôleur.
In English
A latency complaint on database VMs, and two sources that disagree. The method: name the measurement point, compute the queue with Little's law, reject MAX values in favor of p95 or p99, and date the doctrine against the deployed version. Guest iostat await and the v4 API controller latency do not measure the same path.
Sources & vérification
Testé sur : API v4 Prism Central (stats VM), invités Linux, 2026
- Nutanix Bible, Data I/O Path nutanixbible.com
- Single vDisk Performance Improvement (nutanix.dev, 2022) nutanix.dev
- AOS 6.1 (STS) Released next.nutanix.com
- Stats VM de l'API v4, client Go officiel pkg.go.dev
- DownSamplingOperator, client Go officiel pkg.go.dev
- Statistiques d'entités en API v4 (nutanix.dev, 2024) nutanix.dev
- iostat(1) man7.org
- proc_loadavg(5) man7.org
- Loi de Little en.wikipedia.org
- Expérience directe de l’auteur, en production (versions ci-dessus)