devopssec
n'est en aucun cas responsable du contenu généré par l'utilisateur. Le contenu posté
exprime les opinions de leur auteur seulement.
Les textes et messages publiés sont la propriété de ceux qui les postent.
je fais de mon mieux pour modérer les propos inappropriés qui pourraient être postés ici,
mais je me dégage de toute responsabilité sur ce que vous postez.
Vous demeurez le seul responsable de vos actes et de vos messages au regard de la loi.
Vous acceptez de ne pas utiliser le service pour poster ou lier vers un contenu qui est
diffamatoire, injurieux, haineux, menaçant, spams ou pourriels, étant de nature à offenser,
ayant un contenu réservé aux adultes ou répréhensible, contenant des renseignements
personnels des autres, risquant de violer les droits d'auteurs, encourageant une activité
illégale ou contraire à toutes les lois.
Le respect est la principale qualité de notre communauté. En conséquence, veillez à l'être envers
vos camarades ici présents, en particulier les nouveaux membres qui comme vous, cherchent
à découvrir l'univers DEVOPS, et n'ont pas toutes vos connaissances.
Tout manque de respect à l'encontre d'un membre, néophyte ou non, entraînera également des sanctions,
à savoir avertissements, bannissements voire poursuites selon la gravité de la situation.
devopssec
décline toute responsabilité concernant les rencontres réelles.
Commentaires
goncalves-michelle
Membre depuis le 29/04/2024
slt ! c'est classique avec mysql. t'as quel scheduler i/o sur tes nvme ? deadline noop cfq ? pour les nvme c'est noop ou none qu'il faut en général. et mysql utilise bien de l'i/o asynchrone ? regarde innodb_flush_method = O_DIRECT_NO_FSYNC ou O_DIRECT dans ta config mysql
dlaroche
Membre depuis le 24/04/2024
alors le scheduler est cfq par défaut. je peux le passer à noop sans problème. pour O_DIRECT_NO_FSYNC je l'ai pas dans ma config. c'est quoi le mieux entre O_DIRECT et O_DIRECT_NO_FSYNC ? et comment je check si l'i/o asynchrone est vraiment utilisé côté mysql
goncalves-michelle
Membre depuis le 29/04/2024
pour nvme clairement passe à noop ou none. cfq c'est pour les hdd. O_DIRECT_NO_FSYNC est souvent le plus perf pour mysql sur du ssd si t'as une batterie de cache (bbu) sur ton raid controller mais si c'est du nvme direct sans raid hardware O_DIRECT est plus safe et souvent suffisant. pour l'i/o asynchrone mysql utilise par défaut libaio mais tu peux tester avec io_uring si ton kernel est récent (5.1 ou plus) c'est encore plus efficient
dlaroche
Membre depuis le 24/04/2024
ok j'ai mis noop et O_DIRECT. j'ai vu un léger mieux mais c'est pas encore ça. mon kernel est 5.10 donc io_uring c'est bon. comment je dis à mysql d'utiliser io_uring ? c'est une option de config ? j'ai l'impression que c'est pas direct
goncalves-michelle
Membre depuis le 29/04/2024
oui c'est pas direct dans mysql. il faut que ton système d'exploitation le supporte et que mysql soit compilé avec le support. mais ce qui est plus important c'est de régler les `nr_requests` pour la queue d'i/o de tes disques. c'est le nombre max de requêtes i/o en attente. pour du nvme faut mettre un chiffre élevé genre 2048 ou 4096. le défaut est souvent 128
dlaroche
Membre depuis le 24/04/2024
aha ! j'ai passé nr_requests à 4096 et là miracle. mes iops sont revenus à la vie. le combo noop + o_direct + nr_requests haut c'était ça. en plus j'ai vu des articles qui disent que mysql 8.0 supporte mieux io_uring donc j'ai bon. merci pour l'aide mec
goncalves-michelle
Membre depuis le 29/04/2024
nickel ! content que ça ait marché. c'est souvent ces petits réglages kernel qui font la différence sur les nvme. hésite pas à bench un peu plus finement ton setup pour voir si t'as le max de perf possible