Combien de fichiers dans un répertoire est trop? (Téléchargement de données à partir du net)

19

Salutations,

J'écris des scripts pour traiter les images de divers sites de photos. En ce moment, je stocke toutes ces données dans des fichiers texte individuels dans le même répertoire.

Le répertoire est accessible sur le Web. Un utilisateur final appelle un service Web qui renvoie le chemin d'accès au fichier dont l'utilisateur aura besoin.

Je me demandais à quelle étape verrais-je un impact sur les performances en ayant tous ces fichiers dans le même répertoire? (Si seulement)

performance optimization web-services

— Steve
source

Quelques chiffres pour MacOS ici

— smci

en relation: superuser.com/q/453348/453247

— Stephen R

12

Les performances varient en fonction du système de fichiers que vous utilisez.

FAT: oubliez ça :) (ok, je pense que la limite est de 512 fichiers par répertoire)
NTFS: Bien qu'il puisse contenir 4 milliards de fichiers par dossier, il se dégrade relativement rapidement - environ un millier, vous commencerez à remarquer des problèmes de performances, plusieurs milliers et vous verrez que l'explorateur semble se bloquer pendant un bon moment.
EXT3: la limite physique est de 32 000 fichiers, mais la performance souffre également après plusieurs milliers de fichiers.
EXT4: théoriquement illimité
ReiserFS, XFS, JFS, BTRFS: ce sont les bons pour beaucoup de fichiers dans un répertoire car ils sont plus modernes et conçus pour gérer de nombreux fichiers (les autres ont été conçus à l'époque où les disques durs étaient mesurés en Mo et non en Go) . Les performances sont bien meilleures pour de nombreux fichiers (avec ext4) car ils utilisent tous deux un algorithme de type de recherche binaire pour obtenir le fichier que vous souhaitez (les autres utilisent un algorithme plus linéaire).

— gbjbaanb
source

6

C'est faux. Il n'y a pas de limite de 32 000 fichiers dans EXT3. Il y a une limite de 32 000 sous-répertoires. J'ai un répertoire ici avec plus de 300 000 fichiers et il fonctionne très bien.

— davidsheldon

1

tout à fait vrai - la limite de fichiers est la limite totale du système de fichiers sur les inodes, mais vous êtes limité à 32k liens (c'est-à-dire les sous-répertoires).

— gbjbaanb

L'instruction pour NTFS actuel n'est également pas vraie, elle peut contenir jusqu'à 4 294 967 295 (2 ^ 32 - 1): technet.microsoft.com/en-us/library/cc781134%28WS.10%29.aspx

— Fleshgrinder

Ne confondez PAS les sous-répertoires avec les fichiers, sur la machine CentOS, j'avais 32000 sous-répertoires, j'ai atteint la limite, j'ai déplacé tous les FICHIERS dans ce répertoire et fonctionne toujours bien.

— adrianTNT

Quelques chiffres pour MacOS ici

— smci

8

Je stocke des images pour les servir par un serveur Web et j'ai plus de 300 000 images dans un répertoire sur EXT3. Je ne vois aucun problème de performances. Avant de configurer cela, j'ai fait des tests avec 500k images dans un répertoire, et accédant aléatoirement à des fichiers par nom, et il n'y a eu aucun ralentissement significatif avec 500k sur 10k images dans le répertoire.

Le seul inconvénient que je vois, c'est que pour synchroniser les nouveaux avec un deuxième serveur, je dois parcourir rsynctout le répertoire et ne peux pas simplement lui dire de synchroniser un sous-répertoire contenant le millier le plus récent.

— davidsheldon
source

Eh bien, pour synchroniser avec un deuxième serveur, je pense que vous devez créer une structure et un algorithme qui conservent les modifications, alors ce journal peut vous faire gagner beaucoup de temps.

— Bahadir Tasdemir

+1 Cela répond en fait à la question.

— kubanczyk

Un inconvénient, si vous utilisez un client FTP comme FileZilla et que vous souhaitez répertorier le contenu du dossier, cela prend un certain temps.

— Kai Noack

3

La quantité de fichiers dans un dossier pourrait théoriquement être illimitée. Cependant, chaque fois que le système d'exploitation accédera au dossier spécifique pour rechercher des fichiers, il devra traiter tous les fichiers du dossier. Avec moins de 500 fichiers, vous ne remarquerez peut-être aucun retard. Mais lorsque vous avez des dizaines de milliers de fichiers dans un seul dossier, une simple commande de liste de dossiers (ls ou dir) peut prendre beaucoup trop de temps. Lorsque ces dossiers seront accessibles via FTP, ce sera vraiment trop lent ...

Les problèmes de performances ne dépendront pas vraiment de votre système d'exploitation, mais de la vitesse du processeur de votre système, des capacités du disque et de la mémoire. Si vous avez autant de fichiers, vous souhaiterez peut-être les combiner en une seule archive et utiliser un système d'archivage optimisé pour contenir un grand nombre de données. Il peut s'agir d'un fichier ZIP, mais mieux encore, stockez-les en tant qu'objets blob dans une base de données avec le nom de fichier comme clé primaire.

— Wim ten Brink
source

Mais l'accès au fichier supprimera-t-il directement les goulots d'étranglement avec les répertoires de recherche ou l'accès à un directy aura-t-il toujours un appel de recherche sous-jacent? (Linux, Debian)

— Steve

3

L'accès direct au fichier atténuera ces problèmes. J'ai fait des tests sur ext3, et accéder à un fichier par son nom dans un répertoire contenant 500000 fichiers n'est pas beaucoup plus lent que celui qui en contient 1000. Évidemment, faire un lsest un problème.

— davidsheldon

Lorsque vous connaissez le nom exact, l'accès doit être rapide. Le problème serait principalement n'importe quel code ou commande qui veut obtenir une liste de fichiers.

— Wim ten Brink

1

Ma règle de base est de diviser les dossiers s'il y a plus de 1000 fichiers et le dossier sera parcouru (c'est-à-dire via Internet ou Explorer) ou 5000 fichiers sinon.

— Bip Bip
source

0

Comme le souligne @skaffman, les limites dépendent du système d'exploitation. Vous êtes susceptible d'être affecté par les limites des anciens systèmes d'exploitation. Je me souviens qu'une ancienne version de Solaris était limitée à 32 768 fichiers par répertoire.

La solution habituelle consiste à utiliser une sorte de hachage, c'est-à-dire que le serveur Cyrus imap divise les utilisateurs par un hachage alphabétique:

/var/spool/imap/a/user/anna/
/var/spool/imap/a/user/albert/
/var/spool/imap/d/user/dan/
/var/spool/imap/e/user/ewan/

— diciu
source

1

Merci, j'aurais définitivement quelque chose en place une fois qu'un répertoire contient plus de 2k fichiers! :)

— steve

Cette question a de bonnes réponses: serverfault.com/questions/95444/...

— Davey

Ma règle générale est que plus de 20 000 fichiers dans un répertoire ne sont pas une bonne idée. La plupart des systèmes de fichiers modernes acceptent ce nombre de fichiers. Une fois que vous avez atteint 32k fichiers dans un répertoire, certains systèmes de fichiers tels que ext3 commenceront à avoir de sérieux problèmes de performances.

— Phil Hollenback

Phil - avez-vous des informations sur les problèmes de performances avec plus de 32k fichiers avec ext3, je n'en vois pas pour le moment avec plus de 300k Peut-être que c'est quelque chose qui n'affecte pas mon mode d'utilisation.

— davidsheldon

Lors de mon travail précédent, un logiciel scientifique générait beaucoup de petits fichiers (quelques k chacun) dans un répertoire. Nous avons certainement vu que pour> 32k fichiers, les temps de lecture des répertoires augmenteraient énormément. L'exécution de 'ls' sur un répertoire contenant autant de fichiers prendrait une minute ou plus.

— Phil Hollenback

0

Si vous accédez directement à un fichier, le nombre de fichiers dans un répertoire n'est pas un problème de vitesse.

Le nombre de fichiers que vous pouvez créer dans un seul répertoire dépend du système de fichiers que vous utilisez. Si vous répertoriez tous les fichiers dans le répertoire ou que vous recherchez, triez, etc., le fait d'avoir de nombreux fichiers ralentira ces opérations.

gbjbaanb a tort dans sa réponse concernant la taille maximale du fichier ext3. Généralement, ext limite le nombre de fichiers sur votre disque en général. Vous ne pouvez pas créer plus de fichiers que vous avez des inodes dans votre table d'inodes. Il a raison de suggérer des reiserfs pour plus de performances avec de nombreux fichiers

— Janusz
source

0

Dossier vérifié avec des fichiers 10K en NTFS (Windows 7, 64 bits). Le dossier contenant des images 10K dans n'importe quelle vue (liste, icône, etc.) fonctionne et défile sans aucun délai sensible.

— Vil
source