Comment fonctionne le système de fichiers Linux : tout ce qui se trouve dans le nœud d'index et dans l'entrée du répertoire est un fichier

Comment fonctionne le système de fichiers LinuxNœuds d'indexation et entrées de répertoire

Tout sous Linux est un fichier. Les fichiers, répertoires, périphériques de bloc, sockets et canaux ordinaires doivent également être gérés via un système de fichiers unifié.

Linux alloue deux structures de données à chaque fichier, un nœud d'index et une entrée de répertoire, qui sont principalement utilisées pour enregistrer les méta-informations et la structure de répertoire du fichier.

Le nœud d'index est le seul identifiant de chaque fichier. L'entrée de répertoire maintient la structure arborescente du système de fichiers. La relation entre l'entrée de répertoire et le nœud d'index est plusieurs à un. peut avoir plusieurs noms.

Les alias créés pour les fichiers via des liens physiques correspondront à différentes entrées de répertoire. Ces entrées de répertoire sont essentiellement toujours liées au même fichier, leurs nœuds d'index sont donc les mêmes.

La plus petite unité d'un disque c est une piste (512B). Cependant, chaque lecture et écriture est si petite et l'efficacité est très faible. Par conséquent, le système de fichiers organise les pistes continues en blocs logiques. Chaque fois, le bloc logique est utilisé comme la plus petite unité pour gérer les données. Chaque fois, le bloc logique est utilisé comme la plus petite unité pour gérer les données. 4 Ko, qui est composé de continu Composé de 8 pistes.

Deux points à noter :

Système de fichiers virtuel

Les entrées de répertoire, les nœuds d'index, les blocs logiques et les superblocs constituent les quatre éléments majeurs du système de fichiers Linux. Afin de prendre en charge différents systèmes de fichiers, Linux introduit une couche concrète entre le processus utilisateur et le système de fichiers, à savoir le système de fichiers virtuel VFS.

VFS définit un ensemble de structures de données et de sockets standard pris en charge par tous les systèmes de fichiers.

E/S du système de fichiers

Classification des E/S : E/S tamponnées et non tamponnées, E/S directes et indirectes, E/S bloquantes et non bloquantes, E/S synchrones et asynchrones.

Espace insuffisant, df a vérifié le lecteur C et a constaté qu'il restait beaucoup d'espace disponible

Bien que non seulement les données de fichiers mais également les nœuds d'index occupent également l'espace du lecteur c, utilisez la commande suivante :

df-i

Lorsque vous constatez qu'il n'y a pas suffisamment d'inodes et d'espace suffisant sur le lecteur C, cela peut être dû à un trop grand nombre de petits fichiers. Ce problème peut être résolu en supprimant ces petits fichiers ou en les connectant à d'autres lecteurs C avec suffisamment de nœuds d'index.

Le noyau utilise le mécanisme Slab pour gérer le cache des entrées de répertoire et des nœuds d'index. /proc/meminfo ne donne que la taille globale de Slab. Pour chaque cache Slab, vous devez également vérifier /proc/slabinfo.

Principe de fonctionnement des E/S du système de stockage :

Les E/S du système de stockage sont généralement le maillon le plus lent de tout le système. Par conséquent, Linux utilise divers mécanismes de mise en cache pour optimiser l’efficacité des E/S. Par exemple, afin d'optimiser les performances d'accès aux fichiers, divers mécanismes de mise en cache tels que le cache de pages, le cache de nœuds d'index et le cache d'entrées de répertoire sont utilisés pour réduire les appels directs vers les périphériques de bloc de couche supérieure. De même, afin d'optimiser l'efficacité d'accès des périphériques bloc, des tampons sont utilisés pour mettre en cache les données des périphériques bloc.

c drive indicateurs de performance

L'utilisation prend uniquement en compte s'il y a des E/S, pas la taille des E/S. En d'autres termes, lorsque l'utilisation est de 100 %, le lecteur C peut toujours accepter de nouvelles demandes d'E/S

Vous ne pouvez pas comparer un certain indicateur isolément, mais vous devez l'analyser de manière globale en combinant le rapport lecture-écriture, le type d'E/S (aléatoire ou continue) et la taille des E/S en lecture-écriture aléatoire dans les bases de données, un grand nombre de ; petits fichiers, etc. Dans davantage de scénarios avec Linux intégré, les IOPS peuvent mieux refléter les performances globales du système ; dans les scénarios avec des lectures et des écritures plus séquentielles telles que le multimédia, le débit peut mieux refléter les performances globales du système 

Lorsque vous rencontrez ces scénarios de « journalisation folle », vous pouvez utiliser iostat, strace, lsof et d'autres outils pour localiser le processus de journalisation, trouver le fichier journal correspondant, puis ajuster le niveau de journalisation via le socket de l'application pour résoudre le problème. Si l'application ne peut pas ajuster dynamiquement le niveau de journalisation, vous devrez peut-être également modifier la configuration de l'application et redémarrer l'application pour que la configuration prenne effet.

Pourquoi strace trace ce processus mais ne détecte aucun appel système d'écriture ?

Étant donné que l'écriture des fichiers est effectuée par des threads enfants, tous les processus de suivi strace ne voient pas l'appel système d'écriture. Vous pouvez afficher les informations sur le thread du processus via pstree, puis utiliser strace pour suivre ou suivre tous les threads via strace-fppid

.

Anatomie de la requête lente

top et iostat ont analysé l'utilisation du processeur et du lecteur c du système et ont découvert le dilemme d'E/S du lecteur c. Ensuite, nous avons utilisé pidstat et avons découvert que le problème était causé par mysqld. Ensuite, nous avons utilisé strace et lsofoptimisation du système de fichiers Linux pour trouver le fichier que mysqld lisait. En même temps, selon le nom et le chemin du fichier, nous avons découvert la base de données et la table de données que mysqld exploite. Sur la base de ces informations, nous avons déterminé qu'il s'agissait d'un problème de requête lente dû à la non-utilisation d'un index.

Après l'arrêt du service de données, le problème d'E/S disparaîtra. Pourquoi ?

La table de données accessible par l'application de cas est basée sur le moteur MyISAM, et une caractéristique de MyISAM est qu'elle met uniquement en cache l'index dans la mémoire vidéo et ne met pas en cache les données. Par conséquent, lorsque la phrase de requête ne peut pas utiliser l'index, la table de données doit être lue depuis le fichier de base de données vers la mémoire vidéo, puis traitée.

dataservice libérera constamment le cache de fichiers, empêchant MySQL d'utiliser le cache du lecteur C.

Redis a d'abord utilisé top et iostat pour analyser l'utilisation du processeur, de la mémoire et du lecteur C du système, mais a constaté qu'il n'y avait aucun dilemme concernant les ressources système. Afin d'approfondir votre analyse, vous devez avoir une certaine compréhension du fonctionnement du système et des applications. Par exemple, dans le cas de demain, bien qu'il n'y ait pas de dilemme dans les E/S du disque C, selon le principe de Redis, il ne devrait pas y avoir un grand nombre d'opérations d'écriture d'E/S sur le disque C lors de l'interrogation du cache. Dans cette optique, nous avons continué à utiliser une série d'outils tels que pidstat, strace, lsof et nsenter pour détecter deux problèmes potentiels. L'un était la configuration déraisonnable de Redis et l'autre était l'abus de Redis par les applications Python. Outils de test de référence d'E/S

fio(flexibleI/OTester)

Optimisation des performances d'E/S

Optimisation de l'application

Remplacez les écritures aléatoires par des écritures ajoutées, réduisez les dépenses d'interrogation et augmentez le taux d'écritures d'E/S en cacheOptimisation du système de fichiers Linux, utilisez pleinement le cache système pour augmenter le nombre d'E/S réelles. . Créez votre propre mise en cache ou utilisez un système de mise en cache externe tel que Redis. De cette façon, d'une part, les données mises en cache et leur cycle de vie peuvent être contrôlés au sein de l'application ; d'autre part, cela peut également réduire l'impact des autres applications utilisant le cache sur elles-mêmes. Les fonctions de bibliothèque telles que fopen et fread fournies par la bibliothèque standard C utiliseront le cache de la bibliothèque standard pour réduire le fonctionnement du lecteur C. Lorsque vous utilisez directement des appels système tels que open et read, vous ne pouvez utiliser que le cache de page et le tampon fournis par le système d'exploitation, et aucun cache de fonctions de bibliothèque n'est disponible si vous devez lire et écrire fréquemment le même espace disque C. , vous pouvez utiliser mmap au lieu de read. /write, réduisez le nombre de copies de la mémoire vidéo. Dans les scénarios où une écriture synchrone est requise, essayez de fusionner les requêtes d'écriture au lieu d'écrire chaque requête sur le lecteur c de manière synchrone. vous pouvez utiliser fsync() au lieu de O_SYNC pour partager le même fichier dans plusieurs applications Lorsque vous utilisez la gestion de la mémoire Linux sur le lecteur c, afin de garantir que les E/S ne sont pas entièrement occupées par une application, il est recommandé d'utiliser. le sous-système d'E/S des groupes de contrôle pour limiter les IOPS et le débit du processus/groupe de processus. Lorsque vous utilisez le planificateur CFQ, vous pouvez utiliser ionice pour ajuster la priorité de planification d'E/S du processus, en particulier pour améliorer la priorité d'E/S. des applications principales. ionice prend en charge trois classes de priorité : Idle, Best-effort et Realtime. Parmi eux, Best-effort et Realtime prennent également en charge respectivement les niveaux de 0 à 7. Plus la valeur est petite, plus le niveau de priorité est élevé.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!