Pile des systèmes de fichiers : lsof, cachestat, filetop, etc.

Au sein d’un système d’exploitation tel que GNU/Linux, chaque composant est considéré comme un fichier. Le stockage de ces objets est donc organisé au sein d’un espace appelé système de fichiers et présenté le plus souvent au système grâce à un point de montage.

Chaque étage de cette pile d’administration permet de tracer et de vérifier l’ensemble des événements survenus au sein du système. La pile elle-même peut se représenter comme suit :

Au niveau de la couche VFS (Virtual File System), on peut facilement utiliser un outil comme lsof permettant de lister les utilisateurs ou les processus utilisant tel ou tel fichier.

Exemple : afficher les processus actifs pour un système de fichiers /myfs :

$ lsof /myfs

On peut aussi récupérer ainsi tous les fichiers ouverts pour un périphérique donné :

$ lsof /dev/sda2

Il existe également un autre utilitaire permettant de fournir la liste des fichiers mis en cache. Par exemple, pour lister les trois premiers fichiers "cachés", on doit alors exécuter :

$ sudo pcstat --top 3 --bname

Cette commande lit le contenu des fichiers se trouvant dans le pseudo-système de fichiers /proc/<pid>/stat dont les processus associés, ont un champ rss différent de zéro. On peut également utiliser la commande cachestat, issue des fonctionnalités eBPF/BCC, qui permet de comptabiliser des statistiques (exprimées en secondes) concernant le cache du tampon (aussi appelé buffer cache) ainsi que celles du cache de page (aussi appelé page cache) et du cache atteints (appelé cache hits) ou encore celles du cache manqué (appelé cache misses). Cela permet, entre autres choses de visualiser les métriques des entrées dirty buffer entries au sein du cache et d’en déduire le cache hit ratio.

Exemple : lister le cache hit ration des différentes statistiques sur les pages du cache :

# cachestat

Il existe également d’autres fonctions eBPF que l’on peut facilement utiliser telles que :

• dcsnoop
• mountsnoop
• filetop
• fileslower

Pour ces deux dernières commandes, on peut les utiliser essentiellement pour lister les entrées/sorties par processus sur des périphériques de type bloc :

# filetop

On peut également tracer les entrées/sorties vis-à-vis de fichiers synchrones plus lents qu’une milliseconde :

# fileslower 1 -p <n°PID>

Au niveau du système de fichiers lui-même, il existe également un éventail d’outil, en commençant par celui que l’on utilise quotidiennement. J’ai nommé df au sein des systèmes GNU/Linux :

# df -h

Il existe également, à ce niveau, des outils eBPF, concernant particulièrement les systèmes de fichiers de type ext4 tombés en latence (précision du 1er paramètre) pour un nombre d’itérations spécifique (2ème paramètre) :

# ext4dist 1 10

On trouve également un éventail d’outils eBPF propres aux autres types de système de fichiers : btrfs, xfs, zfs. Ainsi, on peut se servir des fonctions xfsslower ou xfsdist…

Sous la couche des systèmes de fichiers, on trouve le niveau du gestionnaire de volumes, pour lequel on peut utiliser la commande lvm ainsi que différents outils de manipulation des volumes logiques : vgdisplay, lvdisplay, pvdisplay.

REMARQUE : on peut utiliser également la commande dmsetup. Il s’agit d’une enveloppe logique de commandes, permettant la communication avec le mapper de périphériques. Si l’on souhaite obtenir des informations concernant les périphériques LVM, on alors exécuter l’une des options info, ls, status, deps de la commande dmsetup.

Exemple : lister les informations concernant le périphérique srv01vg00-home :

# dmsetup info srv01vg00-home

Name :                srv01vg00-home
State :                 ACTIVE
Read Ahead :      8192
Tables present :  LIVE
Open count :       1
Event number :   0
Major, minor :    253, 3
Number of targets :2
UUID : LVM-JL8zts87fonmrDpckO4h2uN438i4ZNCyw2jX2YpPKo1T9xmYs06gh1aW8NgLnZHh

Dans le cas où l’on dispose également de matrice RAID, on peut également récupérer de l’information via la commande mdadm :

# mdadm --detail /dev/md0

RAPPEL : lorsque l’on se trouve en présence de matrices RAID sur un système GNU/Linux, on peut aussi éditer le contenu du fichier /proc/mdstat, retraçant ce qu’affiche la commande mdadm.

Par défaut, la vitesse d’écriture est assez faible lorsque l’on synchronise des volumes d’une matrice RAID entre eux. Mais, il est possible d’augmenter cette limite. Par exemple, si l’on souhaite autoriser une écriture à 100MB/s sur un disque, on devra alors exécuter la commande suivante :

# echo 1000000 > /proc/sys/dev/raid/speed_limit_max

Il est également possible de définir une valeur plancher d’écriture à 10MB/s en exécutant l’instruction suivante :

# echo 100000 > /proc/sys/dev/raid/speed_limit_min

Enfin, on trouve là encore à ce niveau un utilitaire eBPF appelé mdflush permettant de tracer les événements survenus dans le cadre de l’administration d’une matrice RAID et des commandes md :

# mdflush

En dernier ressort, concernant cette pile, on trouve le niveau de la couche d’administration des périphériques de type bloc (généralement pilotés au sein d’un stockage de type SAN). Pour l’ensemble de ces composants on doit être en mesure de débusquer les problèmes de performance et de contention, concernant les processus linux. On peut alors utiliser la commande pidstat, qui affiche la consommation en pourcentage pour les différents espaces : utilisateur, système, invité, ainsi que le pourcentage de CPU consommé :

# pidstat -p ALL

REMARQUE : si l’on souhaite plutôt disposer d’informations plus quantitatives, on peut exécuter la commande ci-dessous :

# pidstat -d

En ce qui concerne les entrées/sorties, il est possible d’utiliser la commande iotop ou encore htop, permettant de gérer les informations des différents processus, et ce, de façon un peu plus graphique, pour ce qui est de la commande htop.

A ce niveau encore, on trouve également des fonctions eBPF permettant d’obtenir des informations sur les périphériques bloc :

• biotop
• biosnoop
• biolatency
• ttysnoop
• bitesize (capture la taille des bits manipulés au sein d’un programme)
• hardirqs (concernant les interruptions matérielles)

En ce qui concerne les périphériques bloc, comme ils sont adressés par des volumes de stockage SAN, leur chemin d’accès est généralement sécurisé en démultipliant leur path. Ainsi, il existe une commande multipath permettant de fournir les informations d’accès à ces différents chemins :

# multipath -ll

Enfin, il ne faut surtout pas négliger de scruter également le Ring Buffer via la commande dmesg à la recherche des indications mentionnées dans ce journal de traces lors des phases de démarrage ou d’interruption des différents périphériques :

# dmesg

Le plus souvent, on peut y trouver des informations spécifiques sur les processus, leur initialisation, les périphériques et leur performance avérées ainsi que sur les systèmes de fichiers.