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.
eric-pichon
Membre depuis le 18/12/2024
yo alors iowait ça veut dire que le cpu est en attente d'opérations d'i/o. ça peut être le disque mais pas que. ça peut être le réseau la mémoire les périphériques block. si le disque est pas busy ça peut être une latence très élevée des requêtes i/o. le disque est pas saturé en débit mais il répond lentement. c'est un disque réseau (nfs iscsi) ou local ?
hugues13
Membre depuis le 20/11/2024
c'est un disque local un nvme. mais le serveur est un vm sur vsphere. on a eu des soucis de storage perf avec vsphere dans le passé. ptete que ça vient de là ? mais d'habitude iostat le montre. là il dit que le disque est chill.
raymond88
Membre depuis le 04/09/2024
si c'est vsphere regarde du côté du host esxi les métriques de latence i/o genre guest latency et kernel latency. c'est possible que le problème vienne du storage sous-jacent et que la vm ne voit pas la saturation directe mais juste les délais de réponse. t'as aussi des options scheduler i/o au niveau kernel. t'es sur quel scheduler vmware noop cfq deadline ?
kpotier
Membre depuis le 02/09/2024
exact les latences. essaie de lancer un fio sur ton nvme avec un blocsize petit et un iodepth genre 1 ou 2 pour voir la latence de base en ms. et un dd simple genre dd if=/dev/zero of=/tmp/test.img bs=1M count=1000 oflag=direct pour voir le débit pur et le temps. ça peut isoler le problème.
madeleine-fabre
Membre depuis le 25/08/2024
autre piste moins fréquente des fois c'est un problème de cache disque ou de sync. genre si t'as une appli qui fait beaucoup de fsync() ou O_DIRECT et que le backend storage est lent pour flush le cache ça peut causer du iowait sans que le débit soit élevé.
vaillant-anais
Membre depuis le 26/10/2024
c'est aussi possible que ce soit pas le disque nvme qui pose problème mais un autre device block ou même une operation réseau qui est classifiée comme i/o. vérifie les kworker processes avec ps et strace s'il y a un kworker qui est bloqué sur une syscall.
hugues13
Membre depuis le 20/11/2024
ok j'ai regardé sur vsphere et le guest latency est parfois énorme genre 50ms alors que d'habitude c'est 2-3ms. le %util du disque dans la vm reste bas car c'est pas le débit qui est le souci mais la latence des requêtes. c'est clairement un problème de backend storage sur l'esxi. je vais ouvrir un ticket avec l'équipe infra. thx pour les coups de main les gars c'était bien la latence le truc.