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

J'ai une application qui écrit dans un répertoire ext3 qui, au fil du temps, a atteint environ trois millions de fichiers. Inutile de dire que la lecture de la liste des fichiers de ce répertoire est insupportablement lente.

Je ne blâme pas ext3. La bonne solution aurait été de laisser le code d'application écrire dans des sous-répertoires tels que ./a/b/c/abc.extplutôt que d'utiliser uniquement ./abc.ext.

Je passe à une telle structure de sous-répertoires et ma question est simplement: à peu près 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 j'ai besoin de stocker trois millions de fichiers dans la structure, combien de niveaux la ./a/b/c/abc.extstructure doit-elle avoir?

Évidemment, c'est une question à laquelle on ne peut pas répondre exactement, mais je cherche une estimation du parc à billes.

À condition d'avoir une distribution qui prend en charge la dir_indexcapacité, vous pouvez facilement avoir 200 000 fichiers dans un seul répertoire. Je le garderais à environ 25 000 cependant, juste pour être sûr. Sans dir_index, essayez de le maintenir à 5 000.

Faites très attention à la façon dont vous sélectionnez la division du répertoire. "a / b / c" sonne comme une recette de désastre pour moi ...

Ne vous contentez pas de créer aveuglément une structure profonde de plusieurs répertoires, par exemple 100 entrées au premier niveau, 100 entrées au deuxième niveau, 100 entrées au troisième. J'y suis allé, j'ai fait ça, j'ai récupéré la veste et j'ai dû la restructurer quand 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 tuait. 3 à 6 heures pour faire un "du" dans cette structure de répertoires. Le sauveur ici était SSD, ils n'étaient pas disposés à réécrire cette partie de leur application, et un SSD a réduit ce temps de quelques heures à quelques minutes.

Le problème est que chaque niveau de recherche de répertoire prend des recherches, et les recherches sont extrêmement coûteuses. La taille du répertoire est également un facteur, donc l'avoir plus petit que plus grand est une grande victoire.

Pour répondre à votre question sur le nombre de fichiers par répertoire, 1 000 ont été considérés comme «optimaux», mais les performances à 10 000 semblent être bonnes.

Donc, ce que je recommanderais, c'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 3800 répertoires au niveau supérieur. Vous pouvez ensuite contenir 14 millions de fichiers avec ces sous-répertoires contenant 3800 fichiers, soit environ 1 000 fichiers par sous-répertoire pour les fichiers 3M.

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

Je vous suggère d'essayer différentes tailles de répertoire avec un outil d'analyse comparative tel que le cachet de la poste , car il existe de nombreuses variables comme la taille du cache (à la fois dans le système d'exploitation et dans le sous-système de disque) qui dépendent de votre environnement particulier.

Ma règle de base personnelle est de viser une taille de répertoire de <= 20k fichiers, bien que j'aie vu des performances relativement décentes avec jusqu'à 100k fichiers / répertoire.

J'ai tous les fichiers dans des dossiers comme:

téléchargements / [date] / [heure] /yo.png

et n'ont pas de problèmes de performances.

http://en.wikipedia.org/wiki/Ext3#Functionality - Ceci mentionne qu'un répertoire ne peut avoir qu'environ 32000 sous-répertoires, mais ne fait aucune mention de fichiers.

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

Aussi, je déteste 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.

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

D'après mon expérience, la meilleure approche consiste à ne pas sur-concevoir la structure des fichiers à 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 problèmes de performances.

Le problème que j'ai rencontré le plus fréquemment est la convivialité sur le plan administratif. Le moins de travail que vous pouvez faire pour diminuer le nombre de fichiers dans un répertoire est probablement l'approche dont vous avez besoin en ce moment.

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 diviser 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 le même que le 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 chacun nommé foobar???.txt. Il existe des moyens d'accomplir une répartition plus uniforme, comme le hachage basé sur la valeur d'un nombre particulier de bits de la somme MD5 de chaque nom de fichier, mais je vais oser deviner que ce serait exagéré pour ce que vous essayez d'accomplir.

Hmm, j'ai lu cet article récemment . Essentiellement, vous tirez parti de 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 nombre final de sous-répertoires / fichiers- répartition par répertoire pour un ensemble de données donné, mais il est difficile de trouver des preuves empiriques sur les organisations de répertoires / fichiers optimales. Cet article donne un aperçu des différences de performances entre les systèmes de fichiers (certaines mesures intéressantes), mais rien sur les organisations optimales.

Je pense que vous y réfléchissez trop. Si vous choisissiez même un seul niveau supplémentaire de répertoires et pouviez équilibrer les choses de manière égale, vous auriez 1732 * répertoires et 1732 fichiers par répertoire.

Sauf si vous prévoyez d'avoir besoin de dizaines de milliards de fichiers, vous pouvez à peu près choisir un nombre compris entre 1000 et 100 000 et obtenir de bons résultats.

* racine carrée de 3 millions.