Perf IO dégueu sur serveur DB avec workload bizarre

Posté par cecile-tessier le 05/01/2025
RÉSOLU

cecile-tessier

Membre depuis le 29/06/2023

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

Commentaires

dufour-zacharie

Membre depuis le 01/04/2020

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.

cecile-tessier

Membre depuis le 29/06/2023

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.

dufour-zacharie

Membre depuis le 01/04/2020

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.

cecile-tessier

Membre depuis le 29/06/2023

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 !

dufour-zacharie

Membre depuis le 01/04/2020

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.

cecile-tessier

Membre depuis le 29/06/2023

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 !

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