i/o wait bizarre sur ext4 avec gros fichiers

Posté par mathilde-perrier le 30/10/2024
RÉSOLU

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

iostat -x 1
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 ?

Commentaires

tbrunel

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

ubigot

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

mathilde-perrier

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

denis65

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

mathilde-perrier

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 ?

pires-chantal

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

tbrunel

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

mathilde-perrier

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

mathilde-perrier

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

Laisser une réponse

Vous devez être connecté pour poster un message !

Rejoindre la communauté

Recevoir les derniers articles gratuitement en créant un compte !

S'inscrire