io_uring pas perf du tout pour gros iops c'est quoi le trick

Question

salut à tous on essaie de tirer le max de nos nvme pour une db custom et on a migré notre moteur i/o sur io_uring mais on voit pas les gains de perf escomptés c'est même parfois pire qu'avec libaio. on pousse des millions de petites écritures aléatoires c'est sur un kernel 5.15// extrait du code de setup io_uringstruct io_uring_params p;memset(&p, 0, sizeof(p));p.flags = IORING_SETUP_SQPOLL;p.sq_thread_cpu = 0; // tenter de pinner le thread sqint ring_fd = io_uring_setup(depth, &p);if (ring_fd < 0) {    perror("io_uring_setup");    return 1;}io_uring_queue_init_params(depth, &ring, &p);

lroux · Answer

pour des petites écritures aléatoires IORING_SETUP_SQPOLL c'est bien mais t'as tuné les paramètres du SQ thread ? genre le temps qu'il reste actif avant de dormir

alain-ollivier · Answer

j'ai laissé les valeurs par défaut pour l'instant

lroux · Answer

cherche io_uring_register_ring_fd ou regarde les sysctls associés t'as sq_thread_idle et sq_thread_lap t'as besoin de les baisser pour la latence des petits i/o

alain-ollivier · Answer

ah je vois en gros le thread poll s'endort trop vite c'est ça ?

lroux · Answer

exactement pour de petites I/O à haute fréquence tu veux qu'il soit hyper réactif. le cpu c'est pas le problème là c'est le réveil du thread

lroux · Answer

t'as regardé les métriques io_uring via bpftrace ou perf ? ça peut te donner des indices sur où le temps est passé

alain-ollivier · Answer

non pas encore bpftrace j'ai juste perf pour le moment j'ai vu des context switches pas mal

lroux · Answer

les context switches c'est le symptôme le sq_thread_idle qui est trop haut ou pas assez d'événements pour le maintenir actif

lroux · Answer

essaie de jouer avec ioring_setup_iopoll aussi si tes devices supportent les async notify pour compléter les cqs sans polling actif par le cpu

alain-ollivier · Answer

iopoll ça demande que le device soit en mode polling aussi non ? mes nvme sont pas tous configurés comme ça

lroux · Answer

oui c'est ça il faut un kernel patché ou un driver qui gère le polling direct mais c'est pas toujours nécessaire déjà sqpoll c'est un bon début

alain-ollivier · Answer

je vais baisser les idle times du sq_thread via /proc/sys/kernel/io_uring/sq_thread_idle

lroux · Answer

faut le faire via io_uring_register_ring_fd pour être propre c'est plus granulaire pour ton application seulement

alain-ollivier · Answer

ok j'ai trouvé la doc pour io_uring_register_ring_fd avec IORING_REGISTER_SQ_RING_FDS pour contrôler les idle times. Je vais le coder

lroux · Answer

n'oublie pas le IORING_REGISTER_SQ_RING_FDS c'est pour enregistrer des fds supplémentaires c'est IORING_REGISTER_RING_FDS avec IORING_RING_OP_SET_SQ_THREAD_IDLE

alain-ollivier · Answer

oups merci pour la précision j'ai relu. en gros j'appelle io_uring_register pour set les params du sq_thread. ok j'implémente ça

alain-ollivier · Answer

incroyable ! j'ai set l'idle timeout à 0ms et le lap à 1ms et le throughput a fait x3 en lectures et x2 en écritures. et les context switches ont quasi disparu

lroux · Answer

nickel c'est l'optimisation classique pour io_uring quand tu fais du high-perf low-latency i/o c'est pas intuitif au début

alain-ollivier · Answer

carrément j'aurais jamais pensé à aller dans ces tréfonds sans aide thx pour le coup de main

io_uring pas perf du tout pour gros iops c'est quoi le trick

19 commentaires

Laisser une réponse

Lire et écrire dans un fichier dans le langage de programmation Go

Conclusion du cours d'initiation à GoLang

Cours complet d'introduction à la SDL 2

La supervision dans kubernetes

L'IA Redéfinit l'Architecture Logicielle : Vers des Systèmes Auto-Conçus en DevOps

Rejoindre la communauté