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
adelaide-morvan
Membre depuis le 22/06/2024
t'as regardé ton i/o scheduler ? sur les nvme et ssd il est souvent recommandé de mettre 'noop' ou 'mq-deadline' au lieu de 'cfq' ou 'deadline' qui sont plus adaptés aux hdd. ça peut faire une grosse diff sur les perfs aléatoires
roland34
Membre depuis le 22/07/2024
vérifie aussi la queue depth de tes disques et de ton app. si l'app envoie trop d'i/o et que la queue depth du nvme est trop basse ça peut causer des latences. regarde aussi l'utilisation cpu de ton kernel si le softirq monte ça veut dire que le cpu galère à gérer les i/o
jacqueline-petitjean
Membre depuis le 03/07/2024
bingo le i/o scheduler ! il était sur mq-deadline. j'ai switché sur noop avec
echo noop > /sys/block/nvme0n1/queue/scheduleret les tests fio sont devenus stables et rapides. j'avais zappé ce détail kernel. merci beaucoup