10 commentaires
C'est probablement lié au scheduler par défaut. Sur NVMe, tu devrais basculer en none ou kyber. Le scheduler mq-deadline n'est pas toujours optimal pour les SSD modernes.
Je suis actuellement en none, c'est ce qui est recommandé pour le NVMe normalement, non ?
Regarde si tu as des conflits au niveau de writeback. Si ton application écrit massivement, le kernel peut saturer le buffer de page cache.
Utilise blktrace pour analyser la latence par requête. Ça te permettra de voir si le temps est passé dans le driver ou dans le matériel lui-même.
Bonne idée, je vais lancer blktrace pendant le prochain pic. Est-ce qu'il y a un risque de performance en laissant tourner blktrace en production ?
Oui, ça impacte un peu le CPU. Utilise blkparse en mode différé sur un autre disque pour éviter de polluer les résultats.
As-tu vérifié si ton firmware NVMe est à jour ? J'ai déjà vu des problèmes de thermal throttling qui causaient exactement ce genre de latences irrégulières.
Le firmware est à jour. Je suspecte effectivement un problème de writeback. J'ai réduit dirty_ratio et dirty_background_ratio pour voir si ça lisse les pics.
Bonne approche. Si tu as trop de dirty pages, le kernel bloque les threads d'écriture une fois que le seuil critique est atteint.
Le changement des ratios de dirty pages a stabilisé l'await. Plus de pics à 50ms pour l'instant. Merci pour vos retours.
Laisser une réponse
Vous devez être connecté pour poster un message !
Depuis la migration de certains workloads sur des disques NVMe, j'observe des pics de
iowaitinexpliqués alors que le débit (IOPS) est bien en dessous des limites théoriques du matériel.J'ai utilisé
iostat -xz 1et je vois que leawaitgrimpe parfois à 50ms. Le filesystem est enext4. Est-ce un problème dejournalingou de queue depth au niveau du schedulerblk-mq?