Prestazioni NTFS e grandi volumi di file e directory

Come funziona Windows con NTFS con grandi volumi di file e directory?

Esiste una guida in merito ai limiti dei file o delle directory che è ansible inserire in una singola directory prima di riscontrare problemi di prestazioni o altri problemi? ad esempio è una cartella con 100.000 cartelle al suo interno una cosa da fare

Ecco alcuni consigli da qualcuno con un ambiente in cui abbiamo cartelle contenenti decine di milioni di file.

  1. Una cartella memorizza le informazioni sull’indice (collegamenti a file secondari e cartella figlio) in un file di indice. Questo file diventerà molto grande quando si hanno molti bambini. Si noti che non fa distinzione tra un bambino che è una cartella e un bambino che è un file. L’unica differenza è che il contenuto di quel bambino è l’indice della cartella del bambino o i dati del file del bambino. Nota: sto semplificando un po ‘questo, ma questo ha il significato.
  2. Il file di indice verrà frammentato. Quando diventa troppo frammentato, non sarà ansible aggiungere file a quella cartella. Questo perché c’è un limite al numero di frammenti consentito. È di design. L’ho confermato con Microsoft in una chiamata di intervento di supporto. Quindi, anche se il limite teorico al numero di file che puoi avere in una cartella è di svariati miliardi, buona fortuna quando inizi a colpire decine di milioni di file, come prima colpirai la limitazione della frammentazione.
  3. Non è affatto male comunque. È ansible utilizzare lo strumento: contig.exe per deframmentare questo indice. Non ridurrà la dimensione dell’indice (che può raggiungere fino a diversi concerti per decine di milioni di file) ma è ansible ridurre il numero di frammenti. Nota: lo strumento Deframmentazione dischi NON deframmenta l’indice della cartella. Defrag i dati dei file. Solo lo strumento contig.exe eseguirà la deframmentazione dell’indice. Cordiali saluti: puoi anche usarlo per deframmentare i dati di un singolo file.
  4. Se si esegue la deframmentazione, non aspettare fino a quando non si raggiunge il limite massimo # di frammento. Ho una cartella in cui non posso deframmentare perché ho aspettato fino a quando è troppo tardi. Il mio prossimo test è provare a spostare alcuni file da quella cartella in un’altra cartella per vedere se potrei deframmentarlo. Se questo non riesce, allora quello che dovrei fare è 1) creare una nuova cartella. 2) spostare una serie di file nella nuova cartella. 3) deframmentare la nuova cartella. ripeti il ​​# 2 e il # 3 fino a quando non viene fatto e poi 4) rimuovi la vecchia cartella e rinomina la nuova cartella in modo che corrisponda al vecchio.

Per rispondere alla tua domanda più direttamente: se stai guardando le voci da 100 K, non preoccuparti. Vai a buttarti fuori. Se stai guardando decine di milioni di voci, allora:

a) Pianifica di suddividerli in sottocartelle (ad esempio, diciamo che hai 100 milioni di file. È meglio memorizzarli in 1000 cartelle in modo da avere solo 100.000 file per cartella piuttosto che memorizzarli in 1 cartella grande. creerà 1000 indici di cartelle invece di un singolo grande che ha maggiori probabilità di raggiungere il limite massimo di # di frammenti o

b) Pianifica di eseguire contig.exe su base regolare per mantenere deframmentata l’indice della tua cartella grande.

Leggi di seguito solo se sei annoiato.

Il limite effettivo non è sul # di frammento, ma sul numero di record del segmento di dati che memorizza i puntatori al frammento.

Quindi quello che hai è un segmento di dati che memorizza i puntatori ai frammenti dei dati della directory. I dati della directory memorizzano le informazioni sulle sottodirectory e sui sotto-file che la directory presumibilmente memorizza. In realtà, una directory non “memorizza” nulla. È solo una funzionalità di tracciamento e presentazione che presenta l’illusione della gerarchia all’utente poiché il supporto di memorizzazione stesso è lineare.

Ci sono anche problemi di prestazioni con la creazione di nomi di file brevi che rallentano le cose. Microsoft consiglia di distriggersre la creazione di brevi nomi di file se si dispone di più di 300.000 file in una cartella [1]. Meno unici sono i primi 6 caratteri, più questo è un problema.

[1] Come funziona NTFS da http://technet.microsoft.com , cercare “300.000”

Sto costruendo una struttura file per ospitare fino a 2 miliardi di file (2 ^ 32) e ho eseguito i seguenti test che mostrano un netto calo in Navigate + Prestazioni di lettura a circa 250 file o 120 directory per directory NTFS su un’unità a stato solido ( SSD):

  • Le prestazioni del file diminuiscono del 50% tra 250 e 1000 file.
  • Le prestazioni della directory diminuiscono del 60% tra 120 e 1000 directory.
  • I valori per i numeri> 1000 rimangono relativamente stabili

È interessante notare che il numero di directory e file NON interferisce in modo significativo.

Quindi le lezioni sono:

  • I numeri di file sopra 250 costano un fattore di 2
  • Le directory superiori a 120 costano un fattore di 2,5
  • File-Explorer in Windows 7 può gestire file #Files di grandi dimensioni o #Dir, ma l’usabilità è ancora negativa.
  • L’introduzione delle sottodirectory non è costosa

Questo è il dato (2 misure per ogni file e directory):

 (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 

E questo è il codice di prova:

 [TestCase(50000, false, Result = 50000)] [TestCase(50000, true, Result = 50000)] public static int TestDirPerformance(int numFilesInDir, bool testDirs) { var files = new List(); 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 dovrebbero andare bene.

Ho visto (aneddoticamente) persone che hanno problemi con molti milioni di file e ho avuto problemi con Explorer solo non avendo la minima idea di come contare oltre 60-qualche migliaio di file, ma NTFS dovrebbe essere buono per i volumi che stai parlando.

Nel caso ve lo stiate chiedendo, il numero massimo di file tecnici (e spero teorico ) è: 4.294.967.295

Per l’accesso locale, un numero elevato di directory / file non sembra essere un problema. Tuttavia, se si sta accedendo attraverso una rete, si verifica un notevole calo delle prestazioni dopo poche centinaia (specialmente quando si accede da computer Vista (da XP a Windows Server con NTFS sembra essere eseguito molto più rapidamente a tale riguardo)).

Quando si crea una cartella con N voci, si crea un elenco di N elementi a livello di file system. Questa lista è una struttura di dati condivisa a livello di sistema. Se si inizia quindi a modificare questo elenco continuamente aggiungendo / rimuovendo voci, mi aspetto almeno qualche contesa di blocco sui dati condivisi. Questa contesa – teoricamente – può influire negativamente sulle prestazioni.

Per gli scenari di sola lettura non riesco a immaginare alcun motivo per la riduzione delle prestazioni delle directory con un numero elevato di voci.

Ho avuto un’esperienza reale con circa 100 000 file (ciascuno diversi MB) su NTFS in una directory durante la copia di una libreria online.

Occorrono circa 15 minuti per aprire la directory con Explorer o 7-zip.

Scrivere una copia del sito con winhttrack rimarrà sempre bloccato dopo un po ‘di tempo. Ha trattato anche con la directory, contenente circa 1 000 000 di file. Penso che la cosa peggiore sia che la MFT può essere solo attraversata sequenzialmente.

L’apertura dello stesso su ext2fsd su ext3 ha dato quasi lo stesso tempo. Probabilmente si può passare a reiserfs (non reiser4fs).

Cercare di evitare questa situazione è probabilmente il migliore.

Per i propri programmi che utilizzano i BLOB senza alcun risultato potrebbe essere utile. È così che Facebook fa per memorizzare le foto.