Performances I/O aléatoires sur SSD

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