Limiter la bande passante d'une VM pour tester des commandes BPF

Le protocole de test sera très simple. Il s’agira du lancement d’une application web Java tout ce qu’il y a de plus standard (Spring PetClinic). Avant le lancement de l’application, une commande bio* sera exécutée pour le surveiller.

Le protocole de test sera joué deux fois. Une fois sur une machine non bridée. Une fois sur une machine pour laquelle la bande passante du disque est limitée à 1 Mo/s.

En utilisant l’outil VBoxManage de VirtualBox, il est possible d’accéder à beaucoup plus de paramètres que ceux disponibles dans l’interface graphique.

Ici, on va s’intéresser plus particulièrement aux commandes VBoxManage storageattach et VBoxManage bandwidthctl. Avec bandwidthctl, on va créer une limite à la bande passante disque utilisable par une VM. Avec storageattach, on va associer le disque dur d’une VM à la limite précédemment créée.

Je dispose d’une VM nommée Archlinux. Elle a un unique disque dur sur lequel tous les fichiers sont stockés (OS, /home et /boot, restons simples). Tout d’abord, il faut créer une limite. On la dimensionnera très largement pour être sur qu’elle ne ralentit pas le démarrage de la VM. Car oui, j’ai essayé avec une valeur de base à 1 Ko/s, Grub a mis plusieurs minutes pour pouvoir charger ses propres fichiers.

Ensuite, il faut associer le disque dur de la VM à cette limite.

Pour démarrer l’application, un simple java -jar target/*.jar suffira. Entre deux redémarrages, il sera nécessaire de vider le cache Linux avec echo 3 | sudo tee /proc/sys/vm/drop_caches. On pourra également vérifier que le jar principal n’est pas en cache avec la commande vmtouch.

Avant de lancer l’application, on vérifie que le jar de petclinic n’est pas en cache.

Lorsque l’application est lancée, on peut voir que le processus java charge plusieurs dizaines de Mo depuis le disque. Cela correspond non seulement à l’uberjar mais également à tous les fichiers dont la JVM a besoin, y compris le fichier rt.jar. Ces I/O sont réalisées avec une latence excellente (<1 ms en moyenne).

Une fois l’application stoppée, on peut constater que le jar est bien dans le FS cache. On peut donc au choix utiliser vmtouch -e ou bien echo 3 | sudo tee /proc/sys/vm/drop_caches pour l’en supprimer. Puisqu’on veut avoir le plus d’I/O possible, je choisis de vider entièrement le cache.

Cette fois, je choisis de limiter la bande passante disque à 1 Mo/s. J’ai essayé avec des valeurs plus faibles mais cela figeait parfois la VM. Il semble que le bruit de fond soit suffisant pour parfois atteindre cette limite. Quoi qu’il en soit, 1 Mo/s est une bonne limite sachant que le jar de PetClinic fait 45 Mo.

J’exécute donc la commande ci-dessous.

Cette fois, le résultat est bien différent. Je constate déjà un temps de chargement beaucoup plus long de l’application. Sans l’avoir formellement mesuré, je peux déjà affirmer que la limitation de bande passante fonctionne bien.

Mais c’est surtout la sortie de biotop qui est révélatrice. On voit bien que le processus java ne peut pas lire les données plus rapidement que 1 Mo/s. Mais en plus, on constate que pour lire ce Mo, la latence moyenne est située entre 50 et 100ms. Soit entre 50x et 100x plus que comparé au premier run.

On voit donc comment détecter une saturation disque avec biotop.

J’avais initialement prévu de tester trois autres commandes. Mais cela n’a pas été possible.

La commande biosnoop liste chaque ouverture de fichier. Au chargement d’une JVM, cela représente bien trop de bruit pour être utilisable.

La commande bitesize indique la taille des I/O demandées par l’application. Elle ne prend pas en compte la bande passante effectivement disponible pour ces I/O. Elle s’adresse dont à une autre problématique.

Pour finir, la commande biolatency était intéressante mais elle met l’accent sur la latence disque, comme son nom l’indique. Dans le listing précédent, on voit que la latence est plus élevée. Mais s’agissant d’un problème de bande passante avant tout, je pense que biotop est plus adapté.

La commande VBoxManage bandwidthctl peut également être appliquée sur une carte réseau. Ce sera l’occasion de tester d’autres nouveaux outils comme soconnect et détecter des congestions.

Le livre BPF Performance Tools regorge de nouveaux outils. Je suis curieux de voir comment des cas d’étude peuvent être créés en totale isolation pour expérimenter chacun de ces outils.

Si vous avez des questions ou voulez me faire part de vos commentaires, envoyez moi un tweet (@pingtimeout). Et si vous avez apprécié cet article et voulez soutenir mon travail, vous pouvez toujours m’offrir un café sur BuyMeACoffee ☕️.