Surveillance de disques

De Justine's wiki
Aller à la navigation Aller à la recherche

Linux : commandes globalement utiles

iostat

https://www.linuxtechi.com/monitor-linux-systems-performance-iostat-command/

On commence par installer le paquet sysstat si cela est nécessaire: 

apt install sysstat

Ensuite, on dispose de la commande iostat, qui donne des informations sur les IO sous tous les angles : CPU, disque. La commande est très complète et permet en général de savoir tout ce dont l'on a besoin. Dans son fonctionnement, iostat va lire les fichiers système:

  • /proc/diskstats for disk stats
  • /proc/stat for system stats
  • /sys for block device stats
  • /proc/devices for persistent device names
  • /proc/self/mountstats for all the network filesystems
  • /proc/uptime for information regarding system uptime

Usage

L'usage par défaut:

<source lang="bash"> [justine@Argonaut ~]$ iostat Linux 5.5.8-1-MANJARO (Argonaut) 24/03/2020 _x86_64_ (8 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle 

          9,00    0,00    3,80    0,15    0,00   87,05

Device tps kB_read/s kB_wrtn/s kB_dscd/s kB_read kB_wrtn kB_dscd loop0 0,03 0,47 0,00 0,00 2135 0 0 loop1 0,02 0,24 0,00 0,00 1094 0 0 loop2 0,00 0,00 0,00 0,00 4 0 0 sda 0,11 2,79 0,01 0,00 12690 32 0 sdb 20,18 362,11 254,93 2186,65 1647836 1160089 9950676 scd0 0,00 0,00 0,00 0,00 2 0 0 </source>

Les valeurs en dessous sont assez explicites.

Il existe de nombreuses, très nombreuses options !

  • iostat -c : Seulement infos CPU
  • iostat -d : Seulement infos sur les Devices
  • iostat -x : Infos détaillées
  • iostat -xd : Infos détaillées et séparées par devices
  • iostat -p sda : I/O seulement pour sda
  • iostat -N : Rapport LVM
  • iostat -z : Rapport seulement sur les devices actifs.
  • iostat -t : Pour avoir un timestamp
  • iostat -j : On peut donner un blkid juste après pour voir seulement ce device là
  • nfsiostat : Variante pour les systèmes nfs

Temporalité

La commande iostat est intéressante pour faire du troubleshooting, mais il vaut mieux l'utiliser "en continu"; si je ne la lance qu'une fois, je peux tomber en plein dans un pic ou dans un creux. Le plus intéressant est ce type d'usage:

<source lang="bash"> [justine@Argonaut ~]$ iostat 2 5 Linux 5.5.8-1-MANJARO (Argonaut) 24/03/2020 _x86_64_ (8 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle 

          8,89    0,00    3,89    0,14    0,00   87,08

Device tps kB_read/s kB_wrtn/s kB_dscd/s kB_read kB_wrtn kB_dscd loop0 0,02 0,41 0,00 0,00 2135 0 0 loop1 0,02 0,21 0,00 0,00 1094 0 0 loop2 0,00 0,00 0,00 0,00 4 0 0 sda 0,10 2,41 0,01 0,00 12691 32 0 sdb 18,05 313,86 239,16 1904,36 1649982 1257277 10011192 scd0 0,00 0,00 0,00 0,00 2 0 0


avg-cpu: %user %nice %system %iowait %steal %idle 

          8,10    0,00    4,61    0,06    0,00   87,22

Device tps kB_read/s kB_wrtn/s kB_dscd/s kB_read kB_wrtn kB_dscd loop0 0,00 0,00 0,00 0,00 0 0 0 loop1 0,00 0,00 0,00 0,00 0 0 0 loop2 0,00 0,00 0,00 0,00 0 0 0 sda 0,00 0,00 0,00 0,00 0 0 0 sdb 0,00 0,00 0,00 0,00 0 0 0 scd0 0,00 0,00 0,00 0,00 0 0 0 </source>

Ici, je lance deux rapports à 5 secondes d'intervalle. Si je ne passe qu'un seul chiffre, ce sera le temps d'intervalle entre deux rapports. Par exemple un: 

iostat 5

...me donnera un rapport toutes les 5 secondes.

sar

Sar, aussi comprise dans sysstats, est une commande permettant d'afficher le contenu du systat. Il faut d'abord activer la collecte des données avec: 

systemctl start sysstat

Il suffit ensuite d'utiliser la commande sar pour avoir des statistiques.

Linux : Surveiller un NFS

Une super doc RedHat

NFS permet de monter des disques réseau d'une façon simple et efficace; cependant, comme il dépend du réseau, le moindre problème sur celui-ci peut affecter les performances. Les deux outils les plus importants pour le surveiller sont nfsstat et nfsiostat.

Ils font partie du paquet nfs-utils.

nfsstat

Cette commande affiche des informations statistiques sur le NFS et les interfaces RPC (Remote Procedure Call, un protocole permettant à un programme d'exécuter une sous-routine sur un autre ordinateur, de façon transparente).

Côté Serveur

La commande est la suivante : 

nfsstat -s

Et l'affichage du type : <source> Server rpc stats: calls badcalls badfmt badauth badclnt 133707 0 0 0 0

Server nfs v4: null compound 3 0% 133704 99%

Server nfs v4 operations: op0-unused op1-unused op2-future access close 0 0% 0 0% 0 0% 85 0% 43 0% commit create delegpurge delegreturn getattr 271 0% 0 0% 0 0% 16 0% 101862 20% getfh link lock lockt locku 38 0% 0 0% 0 0% 0 0% 0 0% lookup lookup_root nverify open openattr 34 0% 0 0% 0 0% 47 0% 0 0% open_conf open_dgrd putfh putpubfh putrootfh 0 0% 0 0% 132926 26% 0 0% 6 0% read readdir readlink remove rename 30706 6% 13 0% 0 0% 25 0% 1 0% renew restorefh savefh secinfo setattr 0 0% 0 0% 1 0% 0 0% 62 0% setcltid setcltidconf verify write rellockowner 0 0% 0 0% 0 0% 95012 19% 0 0% bc_ctl bind_conn exchange_id create_ses destroy_ses 0 0% 0 0% 4 0% 3 0% 1 0% free_stateid getdirdeleg getdevinfo getdevlist layoutcommit 0 0% 0 0% 0 0% 0 0% 0 0% layoutget layoutreturn secinfononam sequence set_ssv 0 0% 0 0% 3 0% 133697 27% 0 0% test_stateid want_deleg destroy_clid reclaim_comp allocate 0 0% 0 0% 1 0% 3 0% 0 0% copy copy_notify deallocate ioadvise layouterror 0 0% 0 0% 0 0% 0 0% 0 0% layoutstats offloadcancel offloadstatus readplus seek 0 0% 0 0% 0 0% 0 0% 0 0% write_same 0 0% </source> (Mon exemple vient d'un vieux serveur et la sortie peut changer un peu sur un OS qui ne date pas de cro-magnon).

C'est touffu. La mention la plus importante à vérifier est badcalls (tout en haut, dans les stats RPC). Elle représente le nombre total d'appels rejetés par la couche RPC. Si elle est supérieure à 0, il peut y avoir des problèmes ou de la latence dans le réseau. Il est important que serveur et client soient dans le même sous-réseau pour avoir les meilleures performances.

Côté client

La commande est quasi la même: 

nfsstat -c

Et la sortie ressemble à ça : <source> Client rpc stats: calls retrans authrefrsh 126781 0 126797

Client nfs v4: null read write commit open open_conf 0 0% 30720 24% 95001 74% 271 0% 30 0% 0 0% open_noat open_dgrd close setattr fsinfo renew 17 0% 0 0% 43 0% 62 0% 6 0% 0 0% setclntid confirm lock lockt locku access 0 0% 0 0% 0 0% 0 0% 0 0% 64 0% getattr lookup lookup_root remove rename link 234 0% 32 0% 2 0% 25 0% 1 0% 0 0% symlink create pathconf statfs readlink readdir 0 0% 0 0% 4 0% 125 0% 0 0% 12 0% server_caps delegreturn getacl setacl fs_locations rel_lkowner 10 0% 16 0% 14 0% 0 0% 0 0% 0 0% secinfo exchange_id create_ses destroy_ses sequence get_lease_t 0 0% 0 0% 2 0% 2 0% 1 0% 72 0% reclaim_comp layoutget getdevinfo layoutcommit layoutreturn getdevlist 0 0% 2 0% 0 0% 0 0% 0 0% 0 0% (null) 2 0% </source> (Ici aussi, la sortie pourrait changer un peu sur un OS plus récent) Ici, la mention la plus importante est retrans, qui trahit les retransmissions. Si des retransmissions excessives sont constatées, il est peut être utile de modifier les valeurs de rsize et wsize dans la commande mount du client.

Voir les paquets transférés / perdus

Sur le client comme sur le serveur, la commande 

nfsstat -o net

...permet de voir les stats en termes de paquets.

nfsiostat

Cette commande est similaire à iostat, mais elle est utilisée pour surveiller les points de montage nfs. Elle utilise dans /proc/self/mountstats comme entrée et fournit des informations sur les entrées / sorties des partages NFS du système. Elle s'utilise sur le client pour checker ses performances lors de la communication avec le serveur.

Le faire tourner sans argument ressemble à : <source> 

  op/s		rpc bklog
 11.88	   0.00

read: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms) 2.918 2988.853 1024.305 0 (0.0%) 18.046 21.518 write: ops/s kB/s kB/op retrans avg RTT (ms) avg exe (ms) 8.868 8170.599 921.400 0 (0.0%) 4.008 178.702 </source> Points importants :

  • retrans : Nombre de retransmissions.
  • avg RTT (ms) : Temps entre le moment où le kernel du client envoie la requête RPC et celui où il reçoit une réponse.
  • avg exe (ms) : Durée entre le moment où le client fait une requête RPC et le moment où elle est complétée. Inclue le RTT.

Un retrans ainsi qu'un RTT élevés trahissent de la latence réseau; tout comme la latence affecte les IO. Le client sera alors lent.

Récupérée de « https://wiki.squi.fr/index.php?title=Surveillance_de_disques&oldid=2104 »