Perf IO disque pourries sur nos VMs prod

Posté par nmuller le 20/10/2024
RÉSOLU

nmuller

Membre depuis le 17/01/2020

salut. j'ai un souci de perf i/o sur nos vms linux de prod. on a des bases de données et des applications critiques qui tournent dessus (vmware et kvm). les latences disque sont horribles, on a des pics à 500ms sur des opérations basiques alors que le storage backend est rapide. on utilise les schedulers i/o par défaut (cfq sur les vieilles, mq-deadline sur les plus récentes)

Commentaires

lucie-etienne

Membre depuis le 08/04/2020

t'as fait un

iostat -x 1
pour voir les queues et le
%util
? et le
vmstat -d
pour les stats disque plus globales ? ça donne déjà une idée si c'est vraiment le disque ou si le kernel est juste overbooké

lucy74

Membre depuis le 08/08/2019

si c'est des vm, le scheduler i/o dans le guest linux devrait être

noop
ou
mq-deadline
si ton kernel le supporte. le storage array sous-jacent fait déjà l'optimisation. cfq c'est pour du desktop ou des cas d'usage très spécifiques ça doit pas être sur une prod db

madeleine-mahe

Membre depuis le 01/03/2019

et au niveau de la vm elle-même, comment elle est configurée ? contrôleur scsi paravirtualisé (pvscsi sur vmware, virtio-blk sur kvm) ou émulation ? ça change tout en terme de perfs i/o. et l'alignment des partitions aussi

lucie-etienne

Membre depuis le 08/04/2020

regarde aussi les options de mount de tes filesystems. par exemple

noatime
pour éviter les écritures inutiles, ou le journal du fs (ext4 avec
data=ordered
ou
data=writeback
selon ton besoin de durabilité vs perf)

nmuller

Membre depuis le 17/01/2020

ok alors iostat montre des

%util
à 100% par moments et des latences de dingue. je suis sur pvscsi et virtio-blk, c'est configuré correctement. je vais passer les schedulers à
noop
sur les ext4 et
mq-deadline
sur les xfs pour voir

lucy74

Membre depuis le 08/08/2019

pense aussi au

read_ahead_kb
du bloc device. par défaut c'est souvent 128 ou 256. pour des bdd ça peut être utile d'augmenter si tu fais bcp de lecture séquentielle massive. mais attention, faut tester

madeleine-mahe

Membre depuis le 01/03/2019

et la version de ton kernel. des fois y'a des régressions sur l'i/o. t'as quelle version de linux et de kernel ?

nmuller

Membre depuis le 17/01/2020

je suis passé en

noop
partout et j'ai augmenté le
read_ahead_kb
à 2048 sur les disques des bdd. là ça a l'air beaucoup mieux, les latences sont revenues à la normale et le
%util
est plus raisonnable. la db respire. thx les gars !

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