Perf IO dégueu sur serveur DB avec workload bizarre

cecile-tessier 05/01/2025
RÉSOLU

salut les linuxistes ! on a mis en prod un nouveau serveur DB (mysql) sur une VM avec du NVMe mais les perfs IO sont pas du tout au rdv. iostat me montre des await de ouf (centaines de ms) par intermittence alors que le r/w n'est pas si énorme. genre on a des pics de 10-20MB/s mais l'await explose. ca rend la db super lente par moments. une idée du truc à cheker dans le kernel ?

# extrait iostat -x 1 5
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.10    0.00    2.50   15.30    0.00   77.10

Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util
nvme0n1         12.00   85.00    102.00    965.00     0.00     0.00   0.00   0.00  12.50  180.20     3.20     8.50    11.35   2.50  24.00
05/01/2025 à 17:18

6 commentaires

dufour-zacharie
Membre Actif Secouriste
Avatar de dufour-zacharie
dufour-zacharie
Membre Actif Secouriste

hello. première chose à regarder c'est ton IO scheduler. pour du NVMe, il faut être sur noop ou none (souvent alias de noop maintenant). les schedulers traditionnels comme cfq ou deadline sont pas faits pour les SSDs rapides. cat /sys/block/nvme0n1/queue/scheduler pour voir.

Modifié le 23/05/2026 à 16:20

ouais j'ai déjà vérifié ça, on est bien sur noop. le truc c'est que ça arrive par à-coups, c'est pas constant. la plupart du temps c'est ok. mais les pics sont violents.

Modifié le 23/05/2026 à 16:20
dufour-zacharie
Membre Actif Secouriste
Avatar de dufour-zacharie
dufour-zacharie
Membre Actif Secouriste

hmm ok si noop est bon, alors regarde les tunables kernel pour le dirty page cache. vm.dirty_ratio et vm.dirty_background_ratio. si ils sont trop hauts, le kernel peut accumuler une tonne de données en RAM et tout d'un coup décider de les flusher sur disque, créant des pics d'IO. pour une DB, souvent on les réduit pas mal.

Modifié le 23/05/2026 à 16:20

ah ça c'est une bonne piste ! je viens de vérifier, vm.dirty_ratio est à 20 et vm.dirty_background_ratio est à 10. c'est peut-être trop pour une DB qui écrit pas mal. je vais essayer de les baisser à 5 et 2 et voir ce que ça donne. merci !

Modifié le 23/05/2026 à 16:20
dufour-zacharie
Membre Actif Secouriste
Avatar de dufour-zacharie
dufour-zacharie
Membre Actif Secouriste

oui ça peut faire des merveilles. et un autre truc, c'est comment ton application (mysql) gère ses écritures. utilise-t-elle fsync() de façon intensive ? ou des options comme O_DIRECT ? le nombre de fsync est souvent un killer de perfs sur les SSDs s'il est pas maîtrisé. regarde les iostat -x -c aussi.

Modifié le 23/05/2026 à 16:20

c'était bien un combo des deux. j'ai baissé vm.dirty_ratio et vm.dirty_background_ratio et ça a LISSÉ les petits à-coups. et après discussion avec les dev, mysql était configuré avec innodb_flush_log_at_trx_commit = 1 ce qui fait un fsync à chaque transaction. on a passé ça à 2 pour l'instant et le serveur respire beaucoup mieux. merci pour les conseils précis !

Modifié le 23/05/2026 à 16:20

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