Question Nombre maximum de fichiers dans un répertoire ext3 tout en obtenant des performances acceptables?


J'ai une application en train d'écrire dans un répertoire ext3 qui, avec le temps, a atteint environ trois millions de fichiers. Inutile de dire que la lecture de la liste des fichiers de ce répertoire est extrêmement lente.

Je ne blâme pas Ext3. La solution appropriée aurait été de laisser le code de l'application écrire dans des sous-répertoires tels que ./a/b/c/abc.ext plutôt que d'utiliser seulement ./abc.ext.

Je passe à une telle structure de sous-répertoires et ma question est simple: environ combien de fichiers dois-je m'attendre à stocker dans un répertoire ext3 tout en obtenant des performances acceptables? Quelle est votre expérience?

Ou en d'autres termes; en supposant que je doive stocker trois millions de fichiers dans la structure, combien de niveaux de profondeur le ./a/b/c/abc.ext la structure soit?

Évidemment, il s’agit d’une question à laquelle on ne peut pas répondre exactement, mais je cherche une estimation approximative.


25
2018-04-05 16:12


origine




Réponses:


Pourvu que vous ayez une distribution qui supporte le dir_index capacité, vous pouvez facilement avoir 200 000 fichiers dans un seul répertoire. Je le garderais cependant à environ 25 000, juste pour être en sécurité. Sans pour autant dir_index, essayez de le garder à 5 000.


12
2018-04-05 16:29





Être TRÈS Faites attention à la manière dont vous sélectionnez le groupe de répertoires. "a / b / c" sonne comme une recette pour le désastre pour moi ...

Ne vous contentez pas de créer aveuglément une structure de plusieurs répertoires, par exemple 100 entrées du premier niveau, 100 entrées du deuxième niveau, 100 entrées du troisième. J'ai été là-bas, j'ai fait la veste et j'ai dû la restructurer lorsque les performances ont chuté avec quelques millions de fichiers. :-)

Nous avons un client qui a fait la mise en page "plusieurs répertoires", et finit par mettre un à cinq fichiers par répertoire, et cela les a tués. 3 à 6 heures pour faire un "du" dans cette structure de répertoire. Le sauveur ici était SSD, ils ne voulaient pas réécrire cette partie de leur application, et un SSD le réduisait de quelques heures à quelques minutes.

Le problème est que chaque niveau de recherche de répertoire prend cherche, et cherche sont extrêmement coûteux. La taille du répertoire est également un facteur important, il est donc avantageux de l’avoir plus petit que plus grand.

Pour répondre à votre question sur le nombre de fichiers par répertoire, 1 000 personnes ont déjà été qualifiées d '"optimales", mais la performance à 10 000 semble être satisfaisante.

Donc, ce que je recommanderais est un niveau de répertoires, chaque niveau étant un répertoire de 2 caractères, composé de lettres majuscules et minuscules et des chiffres, pour environ 3 800 répertoires du niveau supérieur. Vous pouvez alors stocker 14 millions de fichiers avec ces sous-répertoires contenant 3 800 fichiers, ou environ 1 000 fichiers par sous-répertoire pour 3 millions de fichiers.

J'ai fait un changement comme celui-ci pour un autre client et cela a fait une énorme différence.


10
2017-09-23 05:09





Je vous suggère d'essayer de tester différentes tailles de répertoires avec un outil d'analyse comparative tel que cachet de la poste, car de nombreuses variables, telles que la taille du cache (dans le système d’exploitation et dans le sous-système de disque), dépendent de votre environnement.

Ma règle personnelle est de viser une taille de répertoire de <= 20 000 fichiers, bien que je connaisse des performances relativement correctes avec un maximum de 100 000 fichiers / répertoire.


6
2018-04-05 16:29





J'ai tous les fichiers vont des dossiers comme:

uploads / [date] / [heure] /yo.png

et ne pas avoir de problèmes de performance.


3
2018-04-05 16:31



Et combien de fichiers obtenez-vous par heure? - Cascabel


http://en.wikipedia.org/wiki/Ext3#Functionality - Cela indique qu'un répertoire ne peut avoir qu'environ 32 000 sous-répertoires, mais ne mentionne aucun fichier.

http://roopindersingh.com/2008/05/10/ext3-handling-large-number-of-files-in-a-directory/

Aussi, je déteste les experts Exchange, mais j'ai lu un commentaire sur cette question qu'il est idéal d'avoir moins de 10-15 000 par répertoire.


2
2018-04-05 16:25





Je peux confirmer sur un serveur assez puissant avec beaucoup de mémoire, sous une charge suffisante, que 70 000 fichiers peuvent causer toutes sortes de dégâts. Je suis allé supprimer un dossier de cache contenant 70 000 fichiers, ce qui a amené Apache à générer de nouvelles instances jusqu'à ce qu'il atteigne 255 maximum et que le système utilise toute la mémoire disponible (16 Go, bien que l'instance virtuelle ait pu être inférieure). Quoi qu'il en soit, le garder à moins de 25 000 est probablement une mesure très prudente


2
2017-10-16 23:07





D'après mon expérience, la meilleure approche consiste à ne pas trop modifier la structure du fichier à l'avance. Comme mentionné dans au moins une autre réponse, il existe des extensions de système de fichiers qui traitent de la fin des performances.

Le problème que j'ai le plus souvent rencontré est la facilité d'utilisation du côté administratif. Le minimum de travail que vous pouvez faire pour réduire le nombre de fichiers dans un répertoire est probablement l'approche dont vous avez besoin actuellement.

sqrt (3_000_000) == 1732

Quelques milliers de fichiers dans un seul répertoire me semblent raisonnables. Soyez votre propre juge pour votre propre situation. Pour ce faire, essayez de fractionner les fichiers en un seul niveau de répertoires de hachage afin que le nombre moyen de fichiers par répertoire soit à peu près identique au nombre de répertoires.

Compte tenu de votre exemple, ce serait ./a/abc.ext, ./ab/abc.ext, ./abc/abc.ext, ...

La propagation des fichiers dépendra fortement des noms de fichiers réels. Imaginez appliquer cette technique à un répertoire d’un million de fichiers nommés foobar???.txt. Il existe des moyens d'obtenir une répartition plus uniforme, comme un hachage basé sur la valeur d'un nombre particulier de bits provenant de la somme MD5 de chaque nom de fichier, mais je vais oser deviner que ce serait trop pour ce que vous essayez d'accomplir.


1
2018-04-05 17:36





Hmm, j'ai lu cet article récemment. Essentiellement, vous exploitez la distribution de votre algorithme de hachage préféré. J'ai commencé à jouer avec les nombres. Un INT signé MySQL a une valeur maximale de 2147483647. Vous pouvez également faire varier le nombre de fichiers souhaité par répertoire et le nombre de sous-répertoires pour régler le dernier nombre de sous-répertoires / fichiers par répertoire diviser pour un ensemble de données donné, mais il est difficile de trouver des preuves empiriques sur les organisations optimales de répertoires / fichiers. Cet article donne un aperçu des différences de performances entre les systèmes de fichiers (quelques métriques intéressantes), mais rien sur les organisations optimales.


1
2017-09-23 04:40





Je pense que vous accordez trop d’importance à cela. Si vous avez même choisi un seul niveau supplémentaire de répertoires et avez été en mesure d’équilibrer les choses de manière égale, vous disposez de 1732 * répertoires et de 1732 fichiers par répertoire.

À moins que vous n'ayez besoin de dizaines de milliards de fichiers, vous pouvez en choisir un nombre compris entre 1 000 et 100 000 et obtenir de bons résultats.

* racine carrée de 3 millions.


0
2018-04-05 17:37