Kinerja NTFS dan volume besar file dan direktori

Bagaimana kinerja Windows dengan NTFS dengan volume besar file dan direktori?

Apakah ada panduan seputar batasan file atau direktori yang dapat Anda tempatkan dalam satu direktori sebelum Anda mengalami masalah kinerja atau masalah lain?

Misalnya apakah memiliki folder dengan 100.000 folder di dalamnya adalah hal yang OK untuk dilakukan?

Berikut ini beberapa saran dari seseorang dengan lingkungan tempat kami memiliki folder yang berisi puluhan juta file.

1. Folder menyimpan informasi indeks (tautan ke file anak & folder anak) dalam file indeks. File ini akan menjadi sangat besar ketika Anda memiliki banyak anak. Perhatikan bahwa itu tidak membedakan antara anak yang folder dan anak yang file. Satu-satunya perbedaan adalah konten anak itu adalah indeks folder anak atau data file anak. Catatan: Saya agak menyederhanakan ini tetapi ini intinya.
2. File indeks akan terfragmentasi. Ketika terlalu terfragmentasi, Anda tidak akan dapat menambahkan file ke folder itu. Ini karena ada batasan pada # fragmen yang diizinkan. Ini dengan desain. Saya sudah mengkonfirmasi dengan Microsoft dalam panggilan insiden dukungan. Jadi walaupun batas teoretis untuk jumlah file yang dapat Anda miliki di folder adalah beberapa miliar, semoga berhasil ketika Anda mulai menekan puluhan juta file karena Anda akan mencapai batasan fragmentasi terlebih dahulu.
3. Namun tidak semuanya buruk. Anda dapat menggunakan alat: contig.exe untuk mendefrag indeks ini. Itu tidak akan mengurangi ukuran indeks (yang dapat mencapai hingga beberapa Gigs selama puluhan juta file) tetapi Anda dapat mengurangi # fragmen. Catatan: Alat Disk Defragment TIDAK akan defrag indeks folder. Ini akan mendefrag data file. Hanya alat contig.exe yang akan mendefrag indeks. FYI: Anda juga dapat menggunakannya untuk mendefrag data file individual.
4. Jika Anda DO defrag, jangan menunggu sampai Anda mencapai batas maksimum # fragmen. Saya memiliki folder di mana saya tidak dapat men-defrag karena saya telah menunggu sampai semuanya terlambat. Tes saya berikutnya adalah mencoba memindahkan beberapa file dari folder itu ke folder lain untuk melihat apakah saya bisa mendefrag lagi. Jika ini gagal, maka yang harus saya lakukan adalah 1) membuat folder baru. 2) memindahkan kumpulan file ke folder baru. 3) defrag folder baru. ulangi # 2 & # 3 sampai ini selesai dan kemudian 4) hapus folder lama dan ganti nama folder baru agar sesuai dengan yang lama.

Untuk menjawab pertanyaan Anda secara lebih langsung: Jika Anda melihat 100 ribu entri, jangan khawatir. Pergi jatuhkan dirimu. Jika Anda melihat puluhan juta entri, maka:

a) Buat rencana untuk membaginya ke dalam sub-folder (misalnya, katakanlah Anda memiliki 100 juta file. Lebih baik menyimpannya dalam 1000 folder sehingga Anda hanya memiliki 100.000 file per folder daripada menyimpannya ke dalam 1 folder besar. Ini akan membuat 1000 indeks folder alih-alih satu indeks besar yang lebih mungkin untuk mencapai batas maksimum # fragmen atau

b) Buat rencana untuk menjalankan contig.exe secara teratur untuk menjaga defragmented indeks folder besar Anda.

Baca di bawah hanya jika Anda bosan.

Batas aktual bukan pada # fragmen, tetapi pada jumlah rekaman segmen data yang menyimpan pointer ke fragmen.

Jadi yang Anda miliki adalah segmen data yang menyimpan pointer ke fragmen data direktori. Data direktori menyimpan informasi tentang sub-direktori & sub-file yang seharusnya disimpan oleh direktori. Sebenarnya, direktori tidak "menyimpan" apa pun. Ini hanya fitur pelacakan dan presentasi yang menyajikan ilusi hierarki kepada pengguna karena media penyimpanan itu sendiri linier.

Ada juga masalah kinerja dengan pembuatan nama file pendek memperlambat segalanya. Microsoft merekomendasikan untuk mematikan pembuatan nama file pendek jika Anda memiliki lebih dari 300 ribu file dalam satu folder [1]. Semakin unik 6 karakter pertama, semakin besar masalah ini.

[1] Bagaimana NTFS Bekerja dari http://technet.microsoft.com , cari "300.000"

Saya sedang membangun Struktur File untuk menampung hingga 2 miliar (2 ^ 32) file dan melakukan tes berikut yang menunjukkan penurunan tajam dalam Navigasi + Baca Kinerja di sekitar 250 File atau 120 Direktori per Direktori NTFS pada Solid State Drive ( SSD):

• Kinerja File turun 50% antara 250 dan 1000 File.
• Kinerja Direktori turun 60% antara 120 dan 1000 Direktori.
• Nilai untuk Angka> 1000 tetap relatif stabil

Menariknya Jumlah Direktori dan File TIDAK secara signifikan mengganggu.

Jadi Pelajarannya adalah:

• Jumlah File di atas 250 memerlukan Faktor 2
• Direktori di atas 120 biaya Faktor 2,5
• File-Explorer di Windows 7 dapat menangani #File atau #Dirs besar, tetapi Kegunaannya masih buruk.
• Memperkenalkan Sub-Direktori tidak mahal

Ini adalah Data (2 Pengukuran untuk setiap File dan Direktori):

(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

Dan ini adalah Kode Tes:

[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 harus baik-baik saja.

Saya telah (secara anekdot) melihat orang mengalami masalah dengan jutaan file dan saya sendiri memiliki masalah dengan Explorer hanya tidak memiliki petunjuk bagaimana cara menghitung melewati 60-an ribu file, tetapi NTFS harus baik untuk volume yang Anda bicarakan.

Jika Anda bertanya-tanya, jumlah maksimum file teknis (dan saya harap secara teoritis ) adalah: 4.294.967.295

Untuk akses lokal, sejumlah besar direktori / file tampaknya tidak menjadi masalah. Namun, jika Anda mengaksesnya di jaringan, ada kinerja yang nyata setelah beberapa ratus (terutama ketika diakses dari mesin Vista (XP ke Windows Server dengan NTFS tampaknya berjalan jauh lebih cepat dalam hal itu)).

Ketika Anda membuat folder dengan entri N, Anda membuat daftar item N pada level sistem file. Daftar ini adalah struktur data bersama di seluruh sistem. Jika Anda kemudian mulai memodifikasi daftar ini secara terus menerus dengan menambahkan / menghapus entri, saya berharap setidaknya beberapa pertengkaran kunci atas data bersama. Pendapat ini - secara teoritis - dapat memengaruhi kinerja secara negatif.

Untuk skenario baca-saja, saya tidak dapat membayangkan alasan untuk penurunan kinerja direktori dengan banyak entri.

Saya memiliki pengalaman nyata dengan sekitar 100.000 file (masing-masing beberapa MB) di NTFS dalam direktori saat menyalin satu perpustakaan online.

Dibutuhkan sekitar 15 menit untuk membuka direktori dengan Explorer atau 7-zip.

Copy situs menulis dengan winhttrackakan selalu macet setelah beberapa waktu. Itu juga berurusan dengan direktori, yang berisi sekitar 1.000 file. Saya pikir hal terburuk adalah bahwa MFT hanya dapat dilalui secara berurutan.

Membuka yang sama di bawah ext2fsd pada ext3 memberi waktu yang hampir sama. Mungkin pindah ke reiserfs (bukan reiser4fs) dapat membantu.

Mencoba menghindari situasi ini mungkin yang terbaik.

Untuk program Anda sendiri menggunakan blob tanpa fs bisa bermanfaat. Itulah cara yang dilakukan Facebook untuk menyimpan foto.