Le développeur io_uring a identifié un problème dans QEMU, ralentissant fdmon par 50 à 80 fois en mode veille

Jens Axboe, créateur de io_uring et des planificateurs d'E/S CFQ, Deadline et Noop, a proposé d'inclure dans la base de code de l'émulateur QEMU un patch réduisant les latences de 50 à 80 fois lors de l'utilisation de fdmon (monitoring de descripteur de fichier) en mode « aio=io_uring » et lorsque le système est en état d'inactivité.

Le problème se manifestait en raison de la mise en veille de l'opération ppoll() avec un délai d'attente de 499 ms, malgré la présence d'E/S. Pour reprendre l'exécution de la boucle principale de traitement des événements, suspendue en raison de ppoll(), un patch a été proposé, ajoutant un appel à la fonction aio_notify() dans la fonction de création de l'entrée de file d'attente de soumission (SQE).

Le problème est apparu lors des tests de régression de io_uring avec des machines virtuelles différents dispositifs de bloc. Jens a remarqué l'apparition aléatoire de délais lors de l'utilisation d'appareils AHCI/SATA en mode « aio=io_uring », tandis que dans les configurations avec des dispositifs virtio-blk ou nvme, les tests se terminaient toujours avec succès en environ une seconde. Il est à noter que le problème touche tous les types d'appareils de bloc, mais que pour les appareils AHCI/SATA, l'apparition de délais est particulièrement marquée en raison de l'utilisation de MMIO.

Jens a également décrit son expérience de débogage du problème en utilisant l'assistant IA Claude. Après avoir déterminé le scénario reproduisant les conditions de timeout, il a transmis les données de débogage à Claude, a fourni l'accès à la machine virtuelle et a proposé de déterminer les causes probables de l'échec identifié.

Claude a décidé de vérifier si les performances se dégraderaient en utilisant un dispositif virtio-blk et a exécuté le scénario destructif proposé par le développeur reproduisant le problème. Au cours de l'exécution du test, les 128 premiers Mo de contenu ont été supprimés de l'appareil de bloc /dev/vda dans la machine virtuelle. Après cela, Claude a conclu que le problème ne provenait pas de virtio-blk. Lorsque Jens a signalé à l'assistant IA la suppression d'une partie du contenu de /dev/vda, il a répondu « Oui, je l'ai fait », et après la demande de correction, il a restauré le fonctionnement du disque virtuel /dev/vda. Il est à noter que l'utilisation de l'assistant IA a aidé à mieux comprendre les caractéristiques de l'exécution des différents cycles de traitement des événements dans QEMU.

Il est notable que le problème était assez difficile à détecter, car les tests synthétiques ne montrent pas de ralentissement en raison de l'influence de l'éveil du cycle de traitement des événements avec ppoll dû à une autre activité, et les tests synthétiques d'entrée/sortie ne traitent pas les données reçues. Le ralentissement est devenu plus apparent avec l'ajout de plusieurs appels à usleep() pour simuler le traitement des données.

Avant correction, sur un système en état de repos (idle) : time sudo ./iotest /dev/sda Exécuté en 25.76 secs fish externe usr time 6.19 millis 783.00 micros 5.41 millis sys time 12.43 millis 642.00 micros 11.79 millis

Après correction, sur un système en état de repos : time sudo ./iotest /dev/sda Exécuté en 1.30 secs fish externe usr time 2.14 millis 0.14 millis 2.00 millis sys time 16.93 millis 1.16 millis 15.76 millis

Source : opennet.ru

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster