(Un gars de Windows demande) Mesurer la latence du disque sous Linux: est-ce que ça me dérange?


11

Sous Windows, chaque fois que je veux valider / confirmer qu'il peut y avoir des problèmes liés aux E / S sur un volume sur lequel vit une base de données ou une autre application à faible latence, je vérifie la latence du disque.

Si je vois constamment le compteur de moyenne de sec / transfert de disque Windows > 18-20 ms, alors mon canari dans une mine de charbon vient de mourir et je dois enquêter davantage. Drop-dead simple.

Je regarde Linux maintenant, et je ne vois pas de métrique similaire basée sur la latence. La recherche rapide que j'ai faite indique que je ne voudrais peut-être même pas ... Je vois beaucoup de références à l'attente d'E / S étant la façon dont la plupart des gens suivent cela.

Y a-t-il une règle approximative que vous utilisez à cet égard? Par exemple, est-ce que TOUTES les E / S attendent, je vois mal pour le volume d'une base de données? Existe-t-il une commande iostat simple qui me donne un meilleur aperçu de la santé globale du disque qu'un simple regard TOP?

Merci beaucoup!


4
Vous pouvez rechercherioping
ewwhite

Merci, @ewwhite. Je suppose que je me demande simplement si j'ai besoin de changer complètement d'orientation et de surveiller cela d'une manière différente, vous savez?
Russell Christopher

2
Activez la collecte sysstat sur vos systèmes. Ensuite, vous pouvez examiner le pourcentage de CPU iowait, ce qui est très utile pour diagnostiquer la lenteur liée aux E / S.
EEAA

2
@RussellChristopher Vous pouvez voir un exemple de sarsortie ici . Faites attention à la %iowaitcolonne.
EEAA

@Matt bien qu'il soit TRÈS similaire, le focus est légèrement différent. Cet AQ est davantage axé sur la réalisation de tests dans un environnement simulé, alors que ce Q semble être davantage axé sur la surveillance des performances actuelles dans l'environnement de production.
BeowulfNode42

Réponses:


12

Personnellement, j'utilise la commande iostat -xk 10et regarde la awaitcolonne.

  • -x Affiche les statistiques étendues.
  • -k Affiche les statistiques en kilo-octets par seconde. Ou utilisez m pour mégaoctets / s.
  • 10 intervalles d'affichage en secondes

Il s'agit d'une métrique pratiquement identique à la moyenne de Windows Disk Sec / Transfer et est répertoriée en ms au lieu de secondes. Des règles empiriques similaires pourraient donc être appliquées, bien que cela dépende de toutes sortes de choses. Je trouve généralement que les utilisateurs commencent à grogner à 15 ms et 20 ms est très mauvais.

Appuyez sur ctrl + c pour quitter ou spécifiez le nombre d'itérations à afficher avec le paramètre count. Notez que le résultat de la première itération est fortement biaisé en raison du petit échantillon de temps utilisé lors de la première itération.

Depuis la man iostatpage

wait Temps moyen (en millisecondes) pour les demandes d'E / S émises vers le périphérique à traiter. Cela inclut le temps passé par les demandes en file d'attente et le temps passé à les traiter.

Edit: await est la métrique principale que j'utilise pour regarder un disque sous charge de production pour voir si son débit et ses iops sont capables de répondre à la demande.

La statistique% iowait concerne davantage l'équilibre entre le processeur et l'utilisation du disque. % iostat restera plus faible que prévu si les deux cpu et l' activité du disque sont élevés. D'un autre côté, à partir de niveaux d'utilisation de disque assez bas,% iostat peut être relativement élevé si le processeur est inactif. Cela étant dit, l'attente doit également être prise avec un grain de sel. S'il y a beaucoup de lecture / écriture séquentielle, cela inclinera le chiffre à une valeur inférieure, et votre règle de base de 18 ~ 20 ms ne sera pas utile dans ces conditions car la plupart des morceaux en cours d'écriture seront les données séquentielles et seront entretenus par le disque très rapidement, tandis que l'autre io aléatoire attendra, en raison du système NCQ (Native-Command-Queuing) intégré au disque pour optimiser le débit en laissant le disque choisir la séquence de traitement des demandes.


Merci @ beowulfNode42. Est-ce la principale mesure que vous utilisez en termes de "mauvais disque"? New Relic, semble se concentrer sur le pourcentage d'attente d'E / S et d'utilisation du disque (lecture et écriture) ... Cela me fait me demander si je poursuis la mauvaise métrique, ou si ILS signalent simplement des informations moins utiles ....
Russell Christopher

@RussellChristopher les autres statistiques fournissent le contexte requis pour interpréter les informations en attente. par exemple, y a-t-il beaucoup d'iops (r / et w / s), beaucoup de Mo / s, la taille moyenne de la demande (avgrq-sz) est-elle grande ou petite, et quelle est la taille moyenne de la file d'attente (avgqu-sz). Oui, avec les métriques liées au processeur% iowait,% user,% system etc. pour voir si le disque ralentit le processeur ou vice-versa.
BeowulfNode42
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.