Comment le nombre de sous-répertoires affecte-t-il les performances de lecture / écriture du lecteur sous Linux?

J'ai un disque formaté EXT3 sur un serveur Linux CentOS. Il s'agit d'un lecteur de données d'application Web et contient un répertoire pour chaque compte d'utilisateur (il y a 25 000 utilisateurs). Chaque dossier contient des fichiers que cet utilisateur a téléchargés. Dans l'ensemble, ce disque contient environ 250 Go de données.

La structuration du lecteur avec tous ces répertoires a-t-elle un impact sur les performances de lecture / écriture du lecteur? Cela a-t-il un impact sur un autre aspect des performances que je ne connais pas?

Y a-t-il quelque chose de mal ou de mauvais en soi à structurer les choses de cette façon? Peut-être juste le mauvais choix de système de fichiers?

J'ai récemment essayé de fusionner deux lecteurs de données et j'ai réalisé que EXT3 est limité à 32 000 sous-répertoires. Cela m'a fait me demander pourquoi. Il semble stupide que je l'ai construit de cette façon, étant donné que chaque fichier a un identifiant unique qui correspond à un identifiant dans la base de données. Hélas ...

Il est facile de tester les options par vous-même, dans votre environnement et de comparer les résultats. Oui, il y a un impact négatif sur les performances à mesure que le nombre d'annuaires augmente. Oui, d'autres systèmes de fichiers peuvent aider à contourner ces obstacles ou à réduire l'impact.

Le système de fichiers XFS est meilleur pour ce type de structure de répertoires. ext4 est probablement très bien de nos jours. L'accès et les opérations sur le répertoire ralentiront simplement à mesure que le nombre de sous-répertoires et de fichiers augmentera. Ceci est très prononcé sous ext3 et pas tellement sur XFS.

La réponse n'est pas aussi simple que le choix du système de fichiers. Les systèmes de fichiers sensés ont cessé d'utiliser des listes linéaires pour les répertoires il y a longtemps, ce qui signifie que le nombre d'entrées dans un répertoire n'affecte pas le temps d'accès aux fichiers ...

sauf quand c'est le cas.

En effet, chaque opération reste rapide et efficace quel que soit le nombre d'entrées, mais certaines tâches impliquent un nombre croissant d'opérations. Évidemment, faire un simple lsprend beaucoup de temps et vous ne voyez rien tant que tous les inodes n'ont pas été lus et triés. Faire ls -U(non trié) aide un peu parce que vous pouvez voir qu'il n'est pas mort, mais ne réduit pas le temps de façon perceptible. Moins évident est que toute extension générique doit vérifier chaque nom de fichier, et il semble que dans la plupart des cas, l'inode entier doit également être lu.

En bref: si vous pouvez être certain qu'aucune application (y compris l'accès au shell) n'utilisera jamais de wildard, alors vous pouvez obtenir d'énormes répertoires sans aucun remords. Mais s'il peut y avoir des caractères génériques cachés dans le code, mieux vaut garder les répertoires en dessous de mille entrées chacun.

Éditer :

Tous les systèmes de fichiers modernes utilisent de bonnes structures de données pour les gros répertoires, donc une seule opération qui doit trouver l'inode d'un fichier spécifique sera assez rapide même sur des répertoires gigantesques.

Mais, la plupart des applications ne font pas que des opérations simples. La plupart d'entre eux feront soit un répertoire complet, soit une correspondance générique. Ceux-ci sont lents quoi qu'il en soit, car ils impliquent la lecture de toutes les entrées.

Par exemple: disons que vous avez un répertoire avec un million de fichiers appelé 'foo-000000.txt' à 'foo-999999.txt' et un seul 'natalieportman.jpeg'. Ce sera rapide:

• ls -l foo-123456.txt
• open "foo-123456.txt"
• delete "foo-123456.txt"
• create "bar-000000.txt"
• open "natalieportman.jpeg"
• create "big_report.pdf"

ceux-ci échoueront, mais échoueront rapidement aussi:

• ls -l bar-654321.txt
• open bar-654321.txt
• delete bar-654321.txt

celles-ci seront lentes, même si elles retournent très peu de résultats; même ceux qui échouent, échouent après avoir analysé toutes les entrées:

• ls
• ls foo-1234*.txt
• delete *.jpeg
• move natalie* /home/emptydir/
• move *.tiff /home/seriousphotos/

Assurez-vous d'abord que l' dir_indexindicateur est défini sur la partition ext3 .

sudo dumpe2fs /dev/sdaX |grep --color dir_index

S'il est manquant, vous pouvez l'activer. Vous devez démonter le système de fichiers, puis exécuter:

sudo tune2fs -O dir_index /dev/sdaX
sudo e2fsck -Df /dev/sdaX

Montez ensuite le système de fichiers.

Cela ne fait aucune différence jusqu'à ce que vous atteigniez la limite ext3 de 32 000 noms par répertoire. La mise à niveau vers ext4 peut contourner cela, ainsi que les autres avantages qu'ext4 a.

Plus vous aurez d'entrées (fichiers et répertoires) dans un seul répertoire, plus l'accès sera lent. Cela est vrai pour chaque système de fichiers, bien que certains soient pires que d'autres.

Une meilleure solution consiste à créer une hiérarchie de répertoires, comme ceci:

/users/a/aaron/
/users/a/andrew/
/users/b/betty/
/users/b/brian/

Et si vous avez toujours besoin de meilleures performances, vous pouvez étendre plusieurs niveaux:

/users/a/a/aaron
/users/a/n/anna
/users/a/n/andrew

La plupart des systèmes de messagerie utilisent cette astuce avec leurs fichiers de file d'attente de messagerie.

De plus, j'ai trouvé qu'avec certains systèmes de fichiers, le simple fait d'avoir eu dans le passé de nombreuses entrées dans un répertoire rendra cet accès au répertoire lent. Faites un ls -ldsur le répertoire pour voir la taille de l'entrée du répertoire lui-même. S'il s'agit de plusieurs Mo ou plus et que le répertoire est relativement vide, vous obtiendrez peut-être de mauvaises performances. Renommez le répertoire à l'écart, créez-en un nouveau avec le même nom, les mêmes autorisations et la même propriété, puis déplacez le contenu de votre ancien répertoire dans le nouveau. J'ai utilisé cette astuce à plusieurs reprises pour accélérer considérablement les serveurs de messagerie qui avaient été ralentis par le système de fichiers.

J'ai récemment développé un serveur de stockage qui devait créer des dizaines de millions de fichiers et des centaines de milliers de répertoires. J'ai comparé XFS avec ext4 et reiserfs. J'ai trouvé que dans mon cas ext4 était légèrement plus rapide que XFS. Reiser était intéressant mais avait des limites, ce qui a été abandonné. J'ai également trouvé que ext4 était beaucoup plus rapide qu'ext3.

Lorsque vous obtenez beaucoup de fichiers par répertoire, le temps d'ouverture des fichiers commence à souffrir. Les E / S de fichiers ne le font pas. Le temps de suppression des fichiers en souffre également. Cependant, ce n'est pas trop lent sur ext4. C'est assez visible sous ext3 cependant. XFS et ext4 sont assez rapides à ce sujet.

La dernière fois que j'ai regardé XFS et mesuré les avantages et les inconvénients de l'utilisation de XFS par rapport à ext4, j'ai trouvé des rapports de perte de données avec XFS. Je ne suis pas sûr que ce soit toujours un problème ou s'il l'a jamais été, mais cela m'a rendu assez nerveux pour rester clair. Comme ext4 est le fs par défaut dans Ubuntu, il l'emporte facilement sur XFS.

Donc, en plus de la suggestion de tylerl qui vous aidera du point de vue de la gestion, je vous suggère de passer à ext4. La limite par répertoire est de 64 000 entrées avec ext4

Un autre avantage est que le temps fsck est beaucoup plus rapide. Je n'ai jamais eu de problème de corruption.

La bonne chose à propos d'ext4 est que vous pouvez monter un volume ext3 sur ext4 pour l'essayer. Voir: Migration d'un système en direct d'un système de fichiers ext3 vers ext4

Une citation de ce lien:

Si vous n'êtes pas affecté par les limites de ext3 et que vous ne souhaitez pas prendre de risques, cela n'en vaut peut-être pas la peine. D'autre part, une fois la procédure de migration terminée avec succès, votre système peut fonctionner plus rapidement, subir des vérifications de système de fichiers raccourcies et avoir une fiabilité accrue sans effets néfastes.

Alors, allez-y et essayez-le. Je vous suggère de sauvegarder d'abord.

Cela va certainement avoir des conséquences. Le principal va être la lecture / écriture IO. Au-delà de cela, c'est juste une façon très effrayante de traiter ce type de données (à cette échelle).

Dans le passé, j'ai utilisé XFS pour contourner avec succès les limites d'Ext3.

La première liste du contenu des systèmes de fichiers prendra un certain temps jusqu'à ce que le système ait lu toutes les informations du répertoire / fichier. Les opérations supplémentaires seront plus rapides car le noyau a maintenant les informations mises en cache.

J'ai vu des administrateurs exécuter régulièrement 'find / somepath 2> & 1> / dev / null' dans cron pour garder le cache actif, ce qui améliore les performances.

J'ai quelques questions et quelques conclusions possibles de goulot d'étranglement.

Tout d'abord, s'agit-il d'un système CentOS 5 ou 6? Parce qu'en 6, nous avons un outil incroyable appelé blktrace qui est idéal pour mesurer l'impact dans ce genre de situations.

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html

Nous pouvons ensuite analyser la sortie avec btt et obtenir où se trouve le goulot d'étranglement, l'application, le système de fichiers, le planificateur, le stockage - dans quel composant l'IO passe la plupart du temps.

Maintenant, en théorie, cela augmentera le nombre d'inodes et à mesure que vous continuez à créer ou à accéder à des fichiers ou des répertoires nouveaux ou existants dans des répertoires, le temps d'accès augmentera. Le noyau doit traverser une hiérarchie de système de fichiers plus vaste et, par conséquent, cela représente sans aucun doute une surcharge.

Un autre point à noter est que lorsque vous augmentez le nombre de répertoires, l'utilisation du cache d'inode et de dentry augmente, ce qui signifie une consommation de RAM supplémentaire. Cela relève de la mémoire de la dalle, donc si votre serveur manque de mémoire, c'est un autre point de pensée.

En parlant d'un exemple du monde réel, j'ai récemment vu que sur un ext3 fs hautement imbriqué, la création d'un sous-répertoire pour la première fois prend environ 20 secondes alors que sur ext4, cela prend environ 4 secondes. En effet, la façon dont l'allocation de blocs est structurée dans différents systèmes de fichiers. Si vous utilisez XFS ou ext4, il va sans dire que vous obtiendrez une amélioration des performances, aussi minime soit-elle.

Donc, si vous demandez simplement quel est le bon choix de système de fichiers, ext3 est un peu dépassé. C'est tout ce que je peux offrir sans données supplémentaires ni référence.

Ce n'est pas une option sur CentOS 5, et je ne sais pas combien c'est une option sur CentOS 6, mais j'ai l'impression qu'un arbre B ou une solution basée sur l'arbre B *, c'est-à-dire BTRFS, fournirait des performances cohérentes, sinon significativement meilleures, dans votre cas particulier. scénario, si seulement on pouvait lui confier ses précieuses données avec une conscience claire (je ne le ferais toujours pas).

Mais si vous pouvez vous le permettre, vous pouvez le tester.