11 commentaires
yo t'as checké l'i/o scheduler de tes disques ? sur du nvme le scheduler par défaut c'est souvent mq-deadline ou none/noop. si t'es sur deadline ou cfq ça peut introduire de la latence et de l'instabilité sur des ssds. essaie de passer en noop ou none.
cat /sys/block/nvme0n1/queue/scheduler
echo noop > /sys/block/nvme0n1/queue/scheduler
c'est sur mq-deadline par défaut. j'ai switché en noop et ça a l'air un peu mieux mais les drops sont toujours là. moins fréquents mais présents. est-ce que ça peut venir du filesystem ?
oui le filesystem peut jouer. ext4 c'est ok mais t'as des options de mount particulières ? genre noatime ou data=writeback ? data=ordered (le défaut) est plus sûr mais peut être moins performant. et quelle taille de bloc t'utilises pour ton ext4 ?
perso sur du NVMe je conseille none pour le scheduler pas noop. none c'est vraiment le plus direct. noop a encore une petite couche. et regarde si t'as pas des dirty_ratio ou dirty_background_ratio trop élevés qui font que le kernel flush tout d'un coup quand la mémoire est pleine.
et ton kernel version ? les noyaux plus récents ont de meilleures optimisations pour les nvme. un vieux kernel peut avoir des soucis avec le blk-mq. et check si t'as des snapshots du disque qui se font en arrière-plan ça peut impacter grave les perfs
kernel 5.15 donc assez récent. pas de snapshots. j'ai passé en none pour le scheduler et mis noatime et data=writeback sur le mount point. ça a l'air de stabiliser un peu plus les perfs. le dirty_ratio c'est 20 et dirty_background_ratio c'est 10.
ok les dirty ratios sont raisonnables. mais t'as vérifié si t'as pas de latence réseau vers ton bloc storage ? même si c NVMe c du réseau derrière sur aws. les burst credits des instances i3.large sont une ressource finie et une fois épuisés ça throttle. c ça qui te donne des perfs aléatoires
exact les burst credits sur les i3.large c le piège. si tu tapes fort dessus pendant un moment t'épuises ton "crédit" de perf et après tu te retrouves avec des perfs de base. il te faut des instances i3en ou plus gros si tu as besoin de perfs constantes sur la durée.
aaaah les burst credits ! je les avais complètement oubliés sur ces instances. ça colle parfaitement avec le pattern "des fois rapide des fois lent". on a effectivement des charges en rafale. on va tester avec des instances plus grosses i3en.large pour voir. merci les gars c'était la bonne piste !
nickel pour le retour. toujours penser aux limites cloud quand les perfs sont en montagnes russes.
clairement ! c'est con mais on se fait avoir à chaque fois. thanks
Laisser une réponse
Vous devez être connecté pour poster un message !
salut les pros ! j'ai un souci avec des perfs I/O hyper instables sur des VMs linux. on est sur des instances cloud avec des NVMe SSDs (genre i3.large sur aws). des fois les perfs sont dingues, genre 150k IOPS, et des fois ça tombe à 5k IOPS pendant plusieurs secondes sans raison apparente. on utilise du ext4. qqun a déjà vu ça ?