Sujet :
RÉSOLU
Liste des sujets Répondre Créer un sujet
Membre depuis le 26/06/2024
salut les pros ! j'ai un souci sur mes VMs debian qui tournent sur de l'nvme cloud (aws i3). les perfs I/O sont super aléatoires, parfois ça fuse parfois ça traîne la patte grave. on a des containers docker qui écrivent pas mal sur ces disques. j'ai testé avec fio et ça confirme que c'est pas stable. scheduler par défaut c'est mq-deadline. des idées pour stabiliser ça ?
# exemple de commande fio
fio --name=random-write --ioengine=libaio --iodepth=16 --rw=randwrite --bs=4k --size=1G --numjobs=1 --filename=/mnt/data/testfile --group_reporting
vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
henri-leroux
Membre depuis le 11/07/2024
avec l'nvme le
mq-deadlineest souvent un bon choix mais t'as essayé de passer surnoneounooppour voir si ça change quelque chose ? sur les nvme modernes le scheduler est souvent mieux géré par le hardware lui-même. check aussi la version de ton kernel ptete une vieille version qui gère mal leblk-mqlenoir-astrid
Membre depuis le 20/06/2024
si t'as docker qui écrit regarde comment est configuré ton storage driver pour docker. si c'est du
overlay2avec des grosses écritures ça peut générer de la fragmentation et du overhead. et la taille desdirect-lvmblock devices si t'en utilisesgauthier-cecile
Membre depuis le 20/01/2025
y'a aussi le souci du
trim/discard. si c'est pas activé ou mal configuré ton SSD peut se retrouver en état de surcharge et les perfs dégringolent. unfstrim -v /mnt/datarégulier ou undiscardà l'écrire peut aider. regarde tesiopset taqueue depthdansiostatquand ça rameemmanuelle-valette
Membre depuis le 26/06/2024
alors j'ai testé
noopça a l'air un peu mieux mais pas encore stable. le kernel est un 5.10 donc pas super vieux. côté docker on est enoverlay2j'ai pas pensé à ça. j'ai checké lefstrimil est bien activé via un service. je vais investiguer le storage driver de dockerhenri-leroux
Membre depuis le 11/07/2024
si
noopdonne une petite amélioration c'est qu'il y a un souci plus profond avec l'overhead du scheduler. essaie de limiter l'iodepthdans tes testsfioou dans les configs de tes apps docker. des fois trop dequeue depthdégrade les perfs sur certaines configs nvme. et check la métriqueDiskQueueDepthsi t'es sur cloudwatchemmanuelle-valette
Membre depuis le 26/06/2024
j'ai mis les conteneurs qui écrivent le plus sur des volumes séparés et j'ai forcé
noopsur tous les devices nvme et ça semble stabiliser pas mal les perfs ! le souci venait d'un mix de la fragmentationoverlay2et d'uniodepthtrop agressif sur une seule partition. merci pour les pistes les gars !