web-dev-qa-db-fra.com

Performances NTFS et grands volumes de fichiers et de répertoires

Comment Windows avec NTFS fonctionne-t-il avec de gros volumes de fichiers et de répertoires?

Existe-t-il des indications sur les limites de fichiers ou de répertoires que vous pouvez placer dans un seul répertoire avant de rencontrer des problèmes de performances ou d’autres problèmes?

Par exemple. Avoir un dossier contenant 100 000 dossiers à l'intérieur est-il une bonne chose à faire?

177
James Newton-King

Voici quelques conseils de quelqu'un avec un environnement dans lequel nous avons des dossiers contenant des dizaines de millions de fichiers.

  1. Un dossier stocke les informations d'index (liens vers les fichiers et le dossier enfants) dans un fichier d'index. Ce fichier deviendra très volumineux lorsque vous aurez beaucoup d'enfants. Notez qu'il ne fait pas la distinction entre un enfant qui est un dossier et un enfant qui est un fichier. La seule différence est que le contenu de cet enfant est son index de dossiers ou ses données. Note: Je simplifie un peu cela, mais cela fait passer le message.
  2. Le fichier d'index sera fragmenté. Lorsqu'il sera trop fragmenté, vous ne pourrez plus ajouter de fichiers à ce dossier. En effet, le nombre de fragments autorisés est limité. C'est par conception. Je l'ai confirmé auprès de Microsoft lors d'un appel d'incident de support. Ainsi, bien que la limite théorique du nombre de fichiers que vous pouvez avoir dans un dossier soit de plusieurs milliards, nous vous souhaitons bonne chance lorsque vous commencez à traiter des dizaines de millions de fichiers, car vous atteindrez d’abord la limite de fragmentation.
  3. Ce n'est pas tout mauvais cependant. Vous pouvez utiliser l'outil: contig.exe pour défragmenter cet index. Cela ne réduira pas la taille de l'index (qui peut atteindre plusieurs Go pour des dizaines de millions de fichiers), mais vous pouvez réduire le nombre de fragments. Remarque: l'outil de défragmentation de disque ne défragmente PAS l'index du dossier. Il défragmentera les données du fichier. Seul l'outil contig.exe défragmentera l'index. FYI: Vous pouvez également l'utiliser pour défragmenter les données d'un fichier individuel.
  4. Si vous effectuez une défragmentation, n'attendez pas d'avoir atteint le nombre maximal de fragments. J'ai un dossier où je ne peux pas défragmenter car j'ai attendu qu'il soit trop tard. Mon prochain test consiste à essayer de déplacer certains fichiers de ce dossier vers un autre pour voir si je pourrais le défragmenter à ce moment-là. Si cela échoue, je devrais créer un nouveau dossier. 2) déplacez un lot de fichiers dans le nouveau dossier. 3) défragmentez le nouveau dossier. répéter les opérations n ° 2 et n ° 3 jusqu'à ce que cela soit fait, puis 4) supprimer l'ancien dossier et renommer le nouveau dossier pour qu'il corresponde à l'ancien.

Pour répondre plus directement à votre question: Si vous recherchez 100 000 entrées, pas de panique. Allez vous assommer. Si vous regardez des dizaines de millions d'entrées, alors soit:

a) Faites des plans pour les diviser en sous-dossiers (par exemple, disons que vous avez 100 millions de fichiers. Il est préférable de les stocker dans 1 000 dossiers afin de ne disposer que de 100 000 fichiers par dossier plutôt que de les stocker dans un seul gros dossier. créera 1 000 index de dossiers au lieu d’un seul grand qui est plus susceptible d’atteindre le nombre maximal de fragments ou

b) Prévoyez d’exécuter régulièrement contig.exe pour que l’index de votre gros dossier soit défragmenté.

Lisez ci-dessous uniquement si vous vous ennuyez.

La limite réelle ne concerne pas le nombre de fragments, mais le nombre d'enregistrements du segment de données qui stocke les pointeurs sur le fragment.

Vous avez donc un segment de données qui stocke les pointeurs sur les fragments des données de l'annuaire. Les données du répertoire stockent des informations sur les sous-répertoires et sous-fichiers que le répertoire est supposé stocker. En fait, un répertoire ne "stocke" rien. Il s’agit simplement d’une fonction de suivi et de présentation qui présente l’illusion de hiérarchie à l’utilisateur puisque le support de stockage lui-même est linéaire.

264
MrB

Il existe également des problèmes de performances avec la création de noms de fichiers courts ralentissant les choses. Microsoft recommande de désactiver la création de nom de fichier court si vous avez plus de 300 000 fichiers dans un dossier [1]. Moins les 6 premiers caractères sont uniques, plus le problème est grave.

[1] Comment NTFS fonctionne à partir de http://technet.Microsoft.com , recherchez "300 000"

46
Tony Lee

Je construis une structure de fichier pour héberger jusqu'à 2 milliards (2 ^ 32) de fichiers et ai effectué les tests suivants qui montrent une nette baisse des performances de Navigate + Read à environ 250 fichiers ou 120 répertoires par répertoire NTFS sur un disque SSD ( SSD):

  • La performance du fichier chute de 50% entre 250 et 1000 fichiers.
  • Les performances du répertoire chutent de 60% entre 120 et 1000 répertoires.
  • Les valeurs pour les nombres> 1000 restent relativement stables

Fait intéressant, le nombre de répertoires et de fichiers n'interfère pas de manière significative.

Donc les leçons sont:

  • Les numéros de fichier supérieurs à 250 coûtent un facteur de 2
  • Les répertoires supérieurs à 120 coûtent un facteur de 2,5
  • L'Explorateur de fichiers de Windows 7 peut gérer des fichiers #Files ou #Dirs volumineux, mais la convivialité est toujours mauvaise.
  • L'introduction de sous-répertoires n'est pas chère

Voici les données (2 mesures pour chaque fichier et répertoire):

(FOPS = File Operations per Second)
(DOPS = Directory Operations per Second)

#Files  lg(#)   FOPS    FOPS2   DOPS    DOPS2
   10   1.00    16692   16692   16421   16312
  100   2.00    16425   15943   15738   16031
  120   2.08    15716   16024   15878   16122
  130   2.11    15883   16124   14328   14347
  160   2.20    15978   16184   11325   11128
  200   2.30    16364   16052   9866    9678
  210   2.32    16143   15977   9348    9547
  220   2.34    16290   15909   9094    9038
  230   2.36    16048   15930   9010    9094
  240   2.38    15096   15725   8654    9143
  250   2.40    15453   15548   8872    8472
  260   2.41    14454   15053   8577    8720
  300   2.48    12565   13245   8368    8361
  400   2.60    11159   11462   7671    7574
  500   2.70    10536   10560   7149    7331
 1000   3.00    9092    9509    6569    6693
 2000   3.30    8797    8810    6375    6292
10000   4.00    8084    8228    6210    6194
20000   4.30    8049    8343    5536    6100
50000   4.70    7468    7607    5364    5365

Et voici le code de test:

[TestCase(50000, false, Result = 50000)]
[TestCase(50000, true, Result = 50000)]
public static int TestDirPerformance(int numFilesInDir, bool testDirs) {
    var files = new List<string>();
    var dir = Path.GetTempPath() + "\\Sub\\" + Guid.NewGuid() + "\\";
    Directory.CreateDirectory(dir);
    Console.WriteLine("prepare...");
    const string FILE_NAME = "\\file.txt";
    for (int i = 0; i < numFilesInDir; i++) {
        string filename = dir + Guid.NewGuid();
        if (testDirs) {
            var dirName = filename + "D";
            Directory.CreateDirectory(dirName);
            using (File.Create(dirName + FILE_NAME)) { }
        } else {
            using (File.Create(filename)) { }
        }
        files.Add(filename);
    }
    //Adding 1000 Directories didn't change File Performance
    /*for (int i = 0; i < 1000; i++) {
        string filename = dir + Guid.NewGuid();
        Directory.CreateDirectory(filename + "D");
    }*/
    Console.WriteLine("measure...");
    var r = new Random();
    var sw = new Stopwatch();
    sw.Start();
    int len = 0;
    int count = 0;
    while (sw.ElapsedMilliseconds < 5000) {
        string filename = files[r.Next(files.Count)];
        string text = File.ReadAllText(testDirs ? filename + "D" + FILE_NAME : filename);
        len += text.Length;
        count++;
    }
    Console.WriteLine("{0} File Ops/sec ", count / 5);
    return numFilesInDir; 
}
29
Spoc

100 000 devraient aller bien.

De manière anecdotique, j'ai vu des personnes rencontrer des problèmes avec plusieurs millions de fichiers et moi-même, avec Explorer, ne sachant pas comment compter les quelque 60 000 fichiers, mais NTFS devrait être bon pour les volumes dont vous parlez.

Si vous le souhaitez, le nombre maximal de fichiers technique (et j'espère théorique) est de: 4 294 967 295.

15
Oli

Pour un accès local, un grand nombre de répertoires/fichiers ne semble pas être un problème. Toutefois, si vous y accédez via un réseau, les performances sont remarquables après quelques centaines (en particulier lors de l'accès depuis des machines Vista (XP vers Windows Server avec NTFS semblait s'exécuter beaucoup plus rapidement à cet égard)).

8
Brian Knoblauch

Lorsque vous créez un dossier avec N entrées, vous créez une liste de N éléments au niveau du système de fichiers. Cette liste est une structure de données partagée à l'échelle du système. Si vous commencez ensuite à modifier continuellement cette liste en ajoutant/supprimant des entrées, vous devez au moins éviter les conflits de verrous sur les données partagées. Cette affirmation - en théorie - peut affecter négativement les performances.

Pour les scénarios en lecture seule, je ne peux imaginer aucune raison pour la dégradation des performances des répertoires contenant un grand nombre d'entrées.

2
Constantin

J'ai eu une expérience réelle avec environ 100 000 fichiers (plusieurs Mo) sur NTFS dans un répertoire lors de la copie d'une bibliothèque en ligne.

Il faut environ 15 minutes pour ouvrir le répertoire avec Explorer ou 7-Zip.

Écrire une copie de site avec winhttrack restera toujours bloqué après un certain temps. Il s’agissait également de répertoires contenant environ 1 000 000 fichiers. Je pense que le pire est que la MFT ne peut être parcourue que de manière séquentielle.

Ouvrir le même sous ext2fsd sur ext3 donnait presque le même timing. Passer probablement à reiserfs (pas reiser4fs) peut aider.

Essayer d'éviter cette situation est probablement le meilleur.

Pour vos propres programmes, utiliser des blobs sans aucun fs pourrait être bénéfique. C'est comme ça que Facebook fait pour stocker des photos.

1
ximik