Linux: combien d'E / S de disque faut-il pour lire un fichier? Comment le minimiser? [dupliquer]

10

Selon cet article sur Haystack de Facebook:

" En raison de la façon dont les appliances NAS gèrent les métadonnées de l'annuaire, placer des milliers de fichiers dans un annuaire était extrêmement inefficace car la carte de blocs de l'annuaire était trop grande pour être mise en cache efficacement par l'appliance. Par conséquent, il était courant d'engager plus de 10 opérations sur le disque pour récupérer un image unique. Après avoir réduit la taille des répertoires à des centaines d'images par répertoire, le système résultant subissait généralement 3 opérations de disque pour récupérer une image: une pour lire les métadonnées du répertoire en mémoire, une seconde pour charger l'inode en mémoire et une troisième pour lire le contenu du fichier. "

J'avais supposé que les métadonnées et l'inode du répertoire du système de fichiers seraient toujours mis en cache dans la RAM par le système d'exploitation et qu'une lecture de fichier ne nécessiterait généralement qu'un seul disque IO.

Est-ce que ce problème "d'E / S sur plusieurs disques pour lire un seul fichier" décrit dans ce document est unique aux appliances NAS, ou Linux a-t-il le même problème aussi?

Je prévois d'exécuter un serveur Linux pour servir des images. De toute façon, je peux minimiser le nombre d'E / S disque - en s'assurant idéalement que le système d'exploitation met en cache toutes les données de répertoire et d'inode dans la RAM et que chaque fichier lu ne nécessiterait pas plus de 1 disque E / S?

linux filesystems

— user9517
source

1

Pas une réponse à la question, mais vous pouvez toujours utiliser Varnish (Facebook l'utilise) qui maintient les fichiers en mémoire. De cette façon, si une image devient chaude (beaucoup de demandes pour le même fichier), le disque IO ne sera pas du tout utilisé pour la servir

Darhazer - Varnish n'aiderait pas ici car le cache de fichiers Linux (sur lequel Varnish s'appuie) met déjà en cache les fichiers chauds en mémoire. Mettre Varnish devant Nginx pour le service de fichiers statiques n'ajoute vraiment rien. Ma question est de savoir quand les fichiers sont trop gros / trop nombreux pour être mis en cache en mémoire. Je voudrais toujours m'assurer qu'au moins les données de répertoire et les inodes sont mis en cache pour réduire le disque IO à seulement 1 par lecture.

De nombreux systèmes de fichiers stockent l'inode dans le répertoire, ce qui réduit le nombre de demandes d'une unité et augmente considérablement les risques de succès du cache. Mais ce n'est pas une question de programmation.

— Ben Voigt

Vous pouvez changer la taille de bloc du système de fichiers lors de sa création, par exemple avec le mke2fs -b 32768pour le rendre 32k. Cependant, cela n'est utile que si vous n'avez pas de petits fichiers sur ce système de fichiers.

5

Linux a le même "problème". Voici un article qu'un de mes étudiants a publié il y a deux ans, où l'effet est montré sur Linux. Les multiples E / S peuvent provenir de plusieurs sources:

Recherche de répertoire à chaque niveau de répertoire du chemin de fichier. Il peut être nécessaire de lire l'inode de répertoire et un ou plusieurs blocs d'entrée de répertoire
Inode du fichier

Dans un modèle d'E / S normal, la mise en cache est vraiment efficace et les inodes, les répertoires et les blocs de données sont alloués de manière à réduire les recherches. Cependant, la méthode de recherche normale, qui est en fait partagée par tous les systèmes de fichiers, est mauvaise pour le trafic hautement aléatoire.

Voici quelques idées:

1) L'aide des caches liés au système de fichiers. Un grand cache absorbera la plupart des lectures. Cependant, si vous souhaitez placer plusieurs disques dans une machine, le rapport Disque sur RAM limite la quantité de mémoire cache.

2) N'utilisez pas des millions de petits fichiers. Les agréger dans des fichiers plus volumineux et stocker le nom de fichier et le décalage dans le fichier.

3) Placez ou mettez en cache les métadonnées sur un SSD.

4) Et bien sûr, utilisez un système de fichiers qui n'a pas un format de répertoire sur disque totalement anarchique. Un répertoire de lecture ne doit pas prendre plus de temps linéaire, et l'accès direct aux fichiers, idéalement juste du temps logarithmique.

Garder des répertoires petits (moins de 1 000 environ) ne devrait pas être très utile, car vous auriez besoin de plus de répertoires avec lesquels vous devez être mis en cache.

— dmeister
source

Et bien sûr, utilisez un système de fichiers qui n'a pas un format de répertoire sur disque totalement archaïque. Un répertoire de lecture ne doit pas prendre plus de temps linéaire, et l'accès direct aux fichiers, idéalement juste du temps logarithmique.

— jørgensen

J'ai ajouté cela à la réponse comme 4ème point

— dmeister

@dmeister Bonnes choses. +1

— Magellan

@dmeister Votre lien est mort.

— Don Scott

1

Cela dépend du système de fichiers que vous prévoyez d'utiliser. Avant de lire le système de données de fichiers:

Lire le fichier répertoire.
Lire l'inode de votre fichier
Lire les secteurs de votre dossier

Si le dossier contient un grand nombre de fichiers, c'est très rassurant sur le cache.

Si vous répertoriez les accès d'E / S, il peut être plus intéressant de séparer ceux effectués par open()de ceux effectués par read(). La page win.tue.nl/~aeb/linux/vfs/trail.html montre une belle présentation des différents concepts du noyau impliqués. (Peut-être que c'est dépassé? Je ne pourrais pas le dire.)

— adl

0

Vous ne pourrez probablement pas conserver toutes les données de répertoire et d'inode dans la RAM, car vous avez probablement plus de données de répertoire et d'inode que de RAM. Vous pouvez également ne pas vouloir, car cette RAM pourrait être mieux utilisée à d'autres fins; dans votre exemple d'image, ne préféreriez-vous pas que les données d'une image fréquemment consultée soient mises en cache dans la RAM plutôt que l'entrée de répertoire d'une image rarement consultée?

Cela dit, je pense que le bouton vfs_cache_pressure est utilisé pour contrôler cela. "Lorsque vfs_cache_pressure = 0, le noyau ne récupérera jamais les dentiers et les inodes en raison de la pression de la mémoire et cela peut facilement conduire à des conditions de mémoire insuffisante."

— Samuel Edwin Ward
source