Membre depuis le 04/10/2024
salut
ext4 et gros fichiers ça peut être sensible au groupement des écritures et à la fragmentation. t'as vérifié la taille des blocs de ton filesystem lors du mkfs.ext4 ? si c'est petit pour des gros fichiers ça va fragmenter plus vite et générer plus d'ops i/o
Membre depuis le 14/08/2024
et ton atime est activé ? sur ext4 le atime par défaut c'est lourd. essaie de monter ton filesystem avec l'option
noatime ou relatime dans ton fstab ça peut aider pas mal
Membre depuis le 25/03/2019
la taille des blocs c'est 4k standard. pour le atime oui il était en relatime. j'ai switché en noatime y a 2h mais pas de changement significatif pour l'instant
Membre depuis le 19/10/2024
check aussi ton scheduler i/o. par défaut sur nvme ça devrait être mq-deadline ou none/noop. si c'est cfq ou bfq c'est pas opti pour du nvme et ça peut créer des latences.
cat /sys/block/nvme0n1/queue/scheduler pour voir
Membre depuis le 25/03/2019
le scheduler est bien en none. j'ai l'impression qu'on tape dans un truc un peu plus profond. y a des options de mount spécifiques à ext4 pour la performance sur des gros fichiers ou du random i/o ?
Membre depuis le 03/09/2019
pour les gros fichiers ext4 gère pas toujours le preallocation aussi bien que xfs. as-tu vérifié l'utilisation de
fallocate dans ton application ? si c pas fait explicitement ça peut ralentir les écritures initiales
Membre depuis le 04/10/2024
et le journal d'ext4 ? si tu as beaucoup d'écritures synchrones sur des gros fichiers, la taille du journal ou le mode de journalisation (
data=ordered, data=writeback) peut avoir un impact énorme. data=writeback est plus rapide mais moins sûr
Membre depuis le 25/03/2019
ok alors j'ai creusé le truc du journal et il était en data=ordered. j'ai essayé de passer en data=writeback pour tester la perf mais ça a pas été très concluant. par contre le souci est venu d'ailleurs en fait
Membre depuis le 25/03/2019
on a identifié que le cache de la base de données (sur le même fs) était très mal configuré. beaucoup de petits accès concurrents sur la même zone du disque en même temps que les gros fichiers. c'est ça qui créait l'i/o wait. on a déplacé les caches de la db sur un autre volume et l'i/o wait est retombé à 5-10%. le combo ext4 + db mal config sur gros fichiers était fatal. merci à tous pour les pistes
Vous devez être connecté pour poster un message !
Recevoir les derniers articles gratuitement en créant un compte !
S'inscrire
mathilde-perrier
Membre depuis le 25/03/2019
hello la compagnie
on a une prod qui galère depuis quelques jours avec un i/o wait énorme sur un de nos serveurs, on parle de 60-80% d'i/o wait. le truc c'est qu'on a migré de xfs vers ext4 récemment et c'est depuis ça déconne.
c'est un serveur qui fait bcp de reads et writes sur des très gros fichiers (plusieurs dizaines de go). on a des disques nvme et avant sur xfs tout était ok. le
nous montre que le device est à 100% d'utilisation quasiment en permanence.une idée de ce qui pourrait plomber ext4 à ce point là sur des nvme avec des gros fichiers ?