système de fichiers pour des millions de petits fichiers


44

Quel système de fichiers Linux choisiriez-vous pour la meilleure vitesse dans le scénario suivant:

  • cent millions de fichiers
  • ~ 2k taille de fichier en moyenne
  • > 95% d'accès en lecture
  • joli accès aléatoire
  • haute simultanéité (> 100 processus)

Remarque: Les fichiers sont stockés dans une arborescence hiérarchique profonde pour éviter les répertoires volumineux. Chaque répertoire feuille contient environ mille fichiers.

Comment le compareriez-vous?


3
Il y a quelques informations supplémentaires nécessaires. Par exemple, stockez-vous tous les fichiers dans un répertoire plat ou dans des répertoires imbriqués (triés)? Cela peut avoir un impact considérable sur les performances des temps d'accès aux fichiers. Le tri sélectif de 100 000 000 entrées dans un arrangement «à plat» entraînera des frais généraux importants, quel que soit le type de société de services; Dans le meilleur des cas, vous envisagez une sorte d’arborescence qui nécessite encore plusieurs recherches pour arriver à votre fichier. Si vous catégorisez les fichiers dans des sous-répertoires, le temps d'accès sera considérablement réduit car il y a moins d'entrées à rechercher à chaque niveau.
Avery Payne

Le fichier est-il accessible en série ou simultanément?
Steve Schnepp

Réponses:


19

Voici quelques résultats comparant tous les principaux FS Linux avec Bonnie ++ que vous pouvez utiliser comme point de départ.

En termes de recherche aléatoire, Reiser gagne, suivi de EXT4, suivi de JFS. Je ne suis pas sûr que cela corresponde exactement aux recherches dans l'annuaire, mais il semble que ce soit un indicateur. Vous devrez faire vos propres tests pour cela en particulier. EXT2 bat tout le pantalon pour tout le temps de création de fichier, probablement en raison de son absence de journal, EXT4 bat toujours tout sauf Reiser que vous ne voudrez peut-être pas utiliser en raison du statut actuel de hans reiser.

Vous voudrez peut-être examiner les lecteurs prenant en charge NCQ et vous assurer que votre installation est configurée pour l'utiliser. Sous forte recherche, il devrait fournir un coup de pouce de vitesse.

Enfin, assurez-vous que votre machine a une tonne de bélier. Comme les fichiers ne sont pas souvent mis à jour, Linux finira par mettre en cache la plupart d’entre eux dans la RAM si elle dispose de l’espace libre. Si vos habitudes d'utilisation sont correctes, cela vous donnera un gain de vitesse considérable.


1
le problème de Bonnie ++ est qu'il ne teste même pas mon scénario d'utilisation de manière approximative
bene

2
Vous n'avez pas à tester les recherches dans les répertoires, mais honnêtement, si c'est votre problème, vous feriez mieux de transférer vos données dans une vraie base de données. Les systèmes de fichiers ne fonctionnent pas aussi bien sur les petits objets que la plupart des bases de données sont conçues pour être utilisées
Andrew Cholakian

7
@AndrewCholakian Link est maintenant mort.
Don Scott

8

Je suis d'accord avec la plupart des propos d'Andrew, sauf que je recommanderais Reiser4 ou l'ancien ReiserFS (mais mieux pris en charge) . Comme ces tests (et la documentation de ReiserFS) l'indiquent, il est conçu pour la situation à propos de laquelle vous vous posez la question (grand nombre de petits fichiers ou de répertoires). J'ai utilisé ReiserFS dans le passé avec Gentoo et Ubuntu sans aucun problème.

En ce qui concerne le statut de Hans Reiser, je ne considère pas que cela pose un problème avec le code ou la stabilité du système de fichiers lui-même. Reiser4 est même sponsorisé à la fois par la DARPA et Linspire. Par conséquent, bien que je convienne que le développement ultérieur du système de fichiers Reiser est indéterminé, je ne pense pas que cela devrait être un facteur déterminant pour décider si quelqu'un doit l'utiliser ou non.


3
J'ai utilisé ReiserFS pendant longtemps. En fait, je l’ utilise toujours sur un ancien serveur Gentoo que je n’ai pas encore réinstallé. Cette installation a 4 ans en mai. Ce que je peux vous dire, c’est que cela a considérablement ralenti. Ce phénomène s'est produit au fil du temps sur tous les systèmes de fichiers utilisant ReiserFS qui sont utilisés activement en lecture / écriture sur toutes les machines dotées de tels systèmes de fichiers, sans exception - par conséquent, si vous souhaitez l'utiliser sur une période prolongée, gardez-le en mémoire. à l'esprit. Je m'en suis éloigné, utilisant maintenant XFS pour les gros systèmes de fichiers.
Mihai Limbăşan

3

Je sais que ce n'est pas une réponse directe à votre question, mais dans ces cas, je pense qu'une base de données pourrait être plus appropriée pour héberger cela. Les petits fichiers peuvent être stockés au format binaire dans une table de base de données et récupérés au format wil. Le logiciel qui utilise ces fichiers devrait pouvoir supporter cela cependant ...


1
Qu'est-ce qu'un système de fichiers, si ce n'est une simple base de données hiérarchique? Votre proposition ajoute des niveaux d'abstraction, de complexité et de logiciels qui ne sont probablement pas garantis. En outre, le propriétaire de la question accomplit sa tâche avec "UNIX Philosophy". Je suppose que vous n'aimez pas être plus du genre Windows?
Stu Thompson

3
Tout d'abord, je n'ai rien contre Unix ou quoi que ce soit d'autre dans ce domaine. Il existe de grandes différences entre les systèmes de fichiers et les bases de données et c'est pourquoi les deux technologies ont été développées. Les bases de données sont conçues pour fonctionner avec une quantité énorme de petites entités, dans lesquelles elles font un meilleur travail que la plupart des systèmes de fichiers. Je faisais simplement remarquer qu'il pourrait y avoir un autre chemin que vous pouvez emprunter avec cela.
Jeroen Landheer

1
Et il est beaucoup plus facile de "nettoyer / vider" un fichier db que de défragmenter un système de fichiers sur Linux. La plupart / tous les fs ne fournissent pas cette fonctionnalité, disant que ce n'est pas nécessaire. En notant le commentaire de Mihai ci-dessus, vous pouvez voir que ce n'est pas strictement vrai.
Gringo Suave

3

Quelqu'un sur Unix StackExchange a créé un benchmark (avec source) pour tester uniquement ce scénario:

Q: Quel est le système de fichiers Linux le plus performant pour stocker de nombreux petits fichiers (disque dur, pas SSD)?

Les meilleures performances de lecture semblent provenir de ReiserFS.


Btrfs semble avoir des résultats meilleurs ou comparables dans tout sauf supprimer. Mais combien de fois supprimez-vous les fichiers 300k? J’ai aimé les rfs dans le passé, mais btrfs pourrait être un meilleur pari pour l’avenir.
Gringo Suave

3

D'après mon expérience, ext2 souffle ext4 hors de l'eau pour les petits fichiers. Si vous ne vous souciez pas de l'intégrité de l'écriture, c'est génial. Par exemple, subversion crée de nombreux petits fichiers que ext4 et d'autres systèmes de fichiers (XFS) bloquent (exécuter un travail cron qui synchronise les données vers ext4 d'ext2 toutes les demi-heures environ résout le problème).

L'exécution de ces commandes rend ext2 encore plus rapide (même si la plupart de ces options rendent le système de fichiers instable après un crash, sauf si vous exécutez sync avant qu'il ne se bloque). Ces commandes n’ont pratiquement aucun effet sur ext4 avec de petits fichiers.

echo 15 > /proc/sys/vm/swappiness
echo 10 > /proc/sys/vm/vfs_cache_pressure
echo 99 > /proc/sys/vm/dirty_ratio
echo 50 > /proc/sys/vm/dirty_background_ratio
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
echo "2000" > /proc/sys/vm/vfs_cache_pressure

1

Je suppose que ext3 (ou ext4), peut-être que JFS serait une bonne solution. Je me méfierais avec ext4 et btrfs (les systèmes de fichiers sont délicats - préparez-vous avec des sauvegardes si vous voulez utiliser les éléments les plus récents et les plus récents).

Il existe également différents paramètres que vous pouvez modifier pendant le temps de mkfs pour ajuster le système de fichiers à votre guise.

Je recommanderais certainement contre XFS. Pas parce que c'est un mauvais système de fichiers, mais la création / suppression est une opération coûteuse.


Pour éviter les problèmes de recherche dans les annuaires, utilisez un schéma de nommage intelligent, par exemple:

<first letter of id>_<last letter of id>/<id>

ou des systèmes similaires, plus compliqués. Cela accélérera vos recherches dans l'annuaire et donc les vitesses d'accès globales. (C'est un vieux truc Unix, de retour de la V7, je pense)


1
quel est l'avantage d'utiliser la première et la dernière lettre et pas seulement les n premières lettres?
bene

c'est juste un des schémas possibles - le fait que ce soit un avantage dépend de la "clé" utilisée pour l'indexation. Ce schéma particulier que j'avais vu référencé avec une application qui stockait des données sur des personnes dans une organisation, leur permettait ainsi une meilleure indexation. Comme toujours, vous devez l'adapter à vos données, puis profiler jusqu'à ce que vous trouviez des réponses exactes :)

1

La plupart des FS vont s'étouffer avec plus de 65K fichiers dans un répertoire, je pense que cela reste vrai pour ext4. Les systèmes de fichiers Reiser n’ont pas cette limite (les gens de mp3.com ont payé pour s’assurer de cela). Pas sûr de rien d'autre, mais c'est l'un des scénarios d'utilisation pour lequel ReiserFS a été conçu.


1
C'est ReiserFS, pas RieserFS
Daniel Rikowski

Ce week-end, j'avais un répertoire sur ext4 avec 1 000 fichiers. Tant que vous ne le faites pas lsou que vous complétez la tabulation, cela fonctionne rapidement. Probablement à cause de l'index.
Ole Tange

ext4 a une extension dir_index, qui accélère de nombreux fichiers dans un répertoire.
Alfonx
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.