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
laurent-fabre
Membre depuis le 21/01/2025
t'as regardé les logs du kernel ? dmesg | grep 'I/O error' ou des trucs comme ça. des fois c'est juste le disque qui a une micro-panne côté hyperviseur. et iostat -xm 5 pour voir les latences directes sur le device. regarde la colonne await et avgqu-sz
bpayet
Membre depuis le 25/03/2024
et si c'est pas le disque direct, c'est ptete le scheduler I/O. quel scheduler est actif sur ton device ? cat /sys/block/sdX/queue/scheduler. si t'es sur un SSD c'est souvent noop ou mq-deadline qui est mieux que cfq. cfq est bien pour les hdd mais pas les ssd
paul54
Membre depuis le 23/10/2024
ok j'ai checké iostat, les latences sont bien là. pas d'erreurs kernel. mais le scheduler... j'étais en cfq ! je viens de le passer en mq-deadline avec echo mq-deadline > /sys/block/nvme0n1/queue/scheduler et les perfs sont redevenues stables instantanément. c'était bien ça ! merci pour le coup de main c'était pas du tout aws le pb