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
matthieu-bonnin
Membre depuis le 30/06/2024
hello. t'as jeté un oeil à l'i/o scheduler configuré sur tes disques nvme dans le kernel linux ? par défaut, souvent c'est mq-deadline ou none pour NVMe. si t'es sur CFQ ou BFQ, ça peut expliquer les inconstances pour des workloads random. regarde avec
cat /sys/block/nvme0n1/queue/schedulermarchal-franck
Membre depuis le 23/08/2024
ouais et quelle est la taille de tes queues i/o ? et c'est quel type de workload ? random read/write ? sequential ? les NVMe sont sensibles au depth de la queue. t'as benché avec fio pour avoir des métriques plus fines ?
henri-ribeiro
Membre depuis le 16/07/2024
@user_key_2 j'ai checké c'est sur
mq-deadline. voici l'output@user_key_3 c'est majoritairement du random read/write, des bases de données quoi. pas encore fait de fio mais je vais m'y mettre
matthieu-bonnin
Membre depuis le 30/06/2024
mq-deadline est pas mal pour NVMe. mais des fois pour certains workloads random le
nonescheduler (ounoopsur les anciens kernels) est encore meilleur car il laisse le hardware NVMe gérer directement l'ordonnancement. tu peux essayer de passer ennone:echo none > /sys/block/nvme0n1/queue/schedulerfleclerc
Membre depuis le 25/06/2024
attention aussi à l'alignement des partitions et des blocks. si t'as une misconfiguration entre la vm et le stockage sous-jacent ça peut dégrader les perfs. et checke aussi les driver virtio-scsi ou nvme utilisés par l'hyperviseur pour la VM, des fois faut les mettre à jour
marchal-franck
Membre depuis le 23/08/2024
oui la queue depth est cruciale. sur esxi assure toi que ton scsi controller pour le nvme a bien la bonne config de queue depth. et côté vm la config
nr_requestssous/sys/block/nvme0n1/queue/peut jouer aussihenri-ribeiro
Membre depuis le 16/07/2024
ok j'ai switché en
noneet là c'est le jour et la nuit ! les perfs sont beaucoup plus stables et je vois plus de pics de latence. je vais quand même faire des fio pour confirmer mais c'est déjà bien mieux. merci pour l'astuce de l'scheduler !