9 commentaires
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
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
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 ?
pour les gros fichiers ext4 gère pas toujours le preallocation aussi bien que xfs. as-tu vérifié l'utilisation de
fallocateok 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
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
Laisser une réponse
Vous devez être connecté pour poster un message !
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 ?