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?
Voici quelques conseils de quelqu'un avec un environnement dans lequel nous avons des dossiers contenant des dizaines de millions de fichiers.
- 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.
- 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.
- 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.
- 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.
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"
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;
}
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.
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)).
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.
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.