Kinerja NTFS dan volume besar file dan direktori

183

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?

James Newton-King
sumber
Jawaban pada pertanyaan terkait lebih rendah dari jawaban yang diterima di sini.
Eric J.
Implementasi ini mungkin berguna: github.com/acrobit/AcroFS
Ghominejad

Jawaban:

271

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.

MrB
sumber
5
Di mana saya dapat menemukan informasi lebih lanjut contig.exe, itu bukan di server saya. Pencarian Google menghasilkan halaman technet ini yang tidak menyebutkan subdirektori atau defragmentasi indeks folder.
Evan Carroll
35
Saya mengetahui tentang fragmentasi indeks folder & folder dari panggilan teknologi dengan insinyur Microsoft. Itu adalah rasa sakit yang sangat besar di pantat melewati tingkat 1-3 dukungan teknis mereka yang tidak berguna. (Eh ... sudahkah Anda mencoba menjalankan chkdsk? Bisakah Anda mencoba membuka folder di Windows Explorer? Bisakah Anda memeriksa izin folder?) FOOL! Saya tidak akan duduk di sini selama 7 hari menunggu chkdsk sialan Anda untuk memindai drive dengan puluhan juta file !!
MrB
5
@ ss2k - Hanya menunjuk contig.exeke direktori, saya pikir itu akan melakukan pekerjaan: contig -a .memberikan:C:\temp\viele-Dateien is in 411 fragments Summary: Number of files processed : 1 Average fragmentation : 411 frags/file
Lumi
3
@ GPhilo Saya dapat mengonfirmasi bahwa kinerja masih menurun pada SSD saat menggunakan jutaan file. Saya juga mencoba untuk mendefrag folder, tetapi contig tidak melakukan apa pun untuk itu. Itu bertindak seolah-olah itu selesai tetapi menunjukkan fragmentasi yang sama sebelum dan sesudah menjalankannya.
Bram Vanroy
1
Dalam hal menjalankan Contig untuk mendefrag indeks, haruskah saya menjalankan contig on c:\my\big\directory, atau c:\my\big\directory\*, atau on $mft? (atau yang lainnya?)
Stephen R
47

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"

Tony Lee
sumber
3
Saya akan menambahkan kutipan di sini If you use large numbers of files in an NTFS folder (300,000 or more), disable short-file name generation for better performance, and especially if the first six characters of the long file names are similar.- hemat pencarian untuk "300.000" petunjuk. BTW: mengetikkan "300" sudah cukup (= tidak perlu clipboarding di sini)
Wolf
32

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; 
}
Spoc
sumber
2
Anda melihat kehilangan kinerja setelah 2 ^ 8 file karena Anda perlu menonaktifkan pembuatan nama pendek (generasi nama 8 karakter). Lihat technet.microsoft.com/en-us/library/cc781134(v=ws.10).aspx
Kyle Falconer
1
Hai, saya mencoba menggunakan Command Line ini: set perilaku fsutil.exe disable8dot3 1 Setelah reboot, hasilnya sebagian besar sama dengan kurang dari 10.000 file / dir. Artikel itu mengatakan itu penting hanya untuk angka yang lebih tinggi. Apa yang saya lihat adalah perf umum. degradasi mungkin karena faktor beban yang lebih tinggi pada SSD saya (sekarang sudah 80% penuh, bukan 45%)
Spoc
sangat bermanfaat terima kasih Estimasi jutaan kata oleh pengguna lain jauh dari nilai numerik ini.
Adrian Maire
2
Bahkan setelah menonaktifkan pembuatan nama 8.3, Anda masih perlu menghapus 8.3 nama yang ada, atau akan ada sedikit peningkatan pada enumerasi file yang ada.
Stephen R
15

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

Oli
sumber
5
Untuk yang belum tahu, jumlah besar itu adalah (2 ^ 32 - 1) file.
meatspace
8

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)).

Brian Knoblauch
sumber
4
Apakah Anda yakin ini adalah NTFS (protokol disk di server), dan bukan SMB (tingkat jaringan)?
MSalters
Tidak, saya tidak melakukan penelitian lebih lanjut untuk mempersempit penyebabnya. Satu-satunya informasi yang saya miliki adalah seperti yang dijelaskan di atas.
Brian Knoblauch
2

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.

Konstantin
sumber
1

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.

ximik
sumber
Saya tidak yakin dari mana Anda mendapatkan bahwa "MFT hanya dapat dilalui secara berurutan"? MFT berisi B-tree dan dilintasi seperti B-tree
phuclv