ประสิทธิภาพของระบบไฟล์จะลดลงหรือไม่หากมีไฟล์จำนวนมากในไดเรกทอรีเดียว (NTFS)


5

ฉันเคยได้ยินว่าประสิทธิภาพของระบบไฟล์ (ในพาร์ติชัน NTFS) สามารถเริ่มลดลงหากจำนวนไฟล์ในไดเรกทอรีเดียวมีขนาดใหญ่มาก (เช่น:> = 10.000.000 รายการ) จริงหรือเปล่า ?

หากเป็นจริงจำนวนไฟล์สูงสุดที่แนะนำในไดเรกทอรีเดียวคือเท่าใด

แก้ไข:

เกี่ยวกับประสิทธิภาพ: ฉันกำลังคิดถึงการทำงานของไฟล์ในโฟลเดอร์นั้น (อ่าน, เขียน, สร้าง, ลบ) ที่อาจช้า



ใช่. MSDN ไม่แนะนำให้เก็บไฟล์มากกว่า 20k ในไดเรกทอรีเดียว (Windows Vista 2gb Ram) - ฉันสังเกตว่าเมื่อมันเริ่มเกิน 40k (Windows 7 4gb Ram) มันจะหยุดทำงาน ทุกอย่างเพียงหยุดและหยุดทำงาน แต่การมีไดเรกทอรีย่อย 100k จะไม่ส่งผลกระทบต่อความเร็วเลย :)
Piotr Kula

คำตอบ:


6

ฉันตอบคำถามของฉันเอง: ใช่มันช้าลงอย่างแน่นอน

ฉันเขียนไฟล์C# Console Applicationที่สร้างไฟล์เปล่าจำนวนมากในโฟลเดอร์และเข้าถึงไฟล์แบบสุ่ม นี่คือผลลัพธ์:

10 files in a folder        : ~26000 operation/sec
1.000.000 files a in folder : ~6000 operation/sec

นี่คือซอร์สโค้ด:

List<string> files = new List<string>();

Console.WriteLine("creating files...");
for (int i = 0; i < 1000 * 1000; i++)
{
    string filename = @"C:\test\" + Guid.NewGuid().ToString();
    using (File.Create(filename));
    files.Add(filename);
}

Console.WriteLine("benchmark...");            
Random r = new Random();
Stopwatch sw = new Stopwatch();
sw.Start();

int count = 0;
while (sw.ElapsedMilliseconds < 5000)
{
    string filename = files[r.Next(files.Count)];
    string text = System.IO.File.ReadAllText(filename);
    count++;
}
Console.WriteLine("{0} operation/sec ", count / 5);

+1 สำหรับรหัส ฉันพบว่าตราบใดที่มีไฟล์มากกว่า 1,000 ไฟล์เวลาก็คล้ายกันมากไม่แตกต่างกัน 1k หรือ 300k ภายใต้ 1,000 ไฟล์มันขึ้นอยู่กับจำนวนไฟล์
wezten

1
เพื่อให้มีประโยชน์คุณจะต้องเปรียบเทียบกับวิธีอื่นในการจัดเก็บและเข้าถึงไฟล์ 1M แบบสุ่ม เช่นสร้างโฟลเดอร์ย่อย 1,000 โฟลเดอร์แต่ละไฟล์มี 1,000 ไฟล์จากนั้นสุ่มเข้าถึงไฟล์ 1M เหล่านั้น
ToolmakerSteve

2

หากคุณอ่านสิ่งนี้คุณควรเข้าใจอย่างถ่องแท้ว่า NTFS ทำงานอย่างไรในการจัดทำดัชนีไฟล์และโฟลเดอร์

ในประเทศนั้นไม่ควรมีไฟล์และโฟลเดอร์ทำดัชนีฮาเซลมากนักหากคุณทำตามคำแนะนำในลิงค์ด้านบน แต่จะต้องบำรุงรักษาเป็นจำนวนมากด้วยไฟล์จำนวนมาก
บนเครือข่ายมันจะเป็นอีกเรื่องหนึ่ง มันจะช้านี่เป็นผลมาจากการหมดอายุของฉันเองที่ทำงานที่เรามีโฟลเดอร์ที่มีโฟลเดอร์นับพันโฟลเดอร์และต้องใช้เวลาในการจัดทำดัชนีผ่านเครือข่าย

อีกสิ่งหนึ่งที่น่าจะเพิ่มขึ้นเมื่อมีไฟล์จำนวนมากคือการปิดใช้งานการตั้งชื่อแบบสั้น: ซึ่งจะหยุดหน้าต่างจากการสร้างรายการไดเรกทอรีไฟล์ที่สองซึ่งจะเป็นไปตามข้อตกลง 8.3 (ข้อตกลงการตั้งชื่อไฟล์ MS-DOS)และลดเวลาสำหรับโฟลเดอร์ ระบุเนื่องจากไม่จำเป็นต้องค้นหาชื่อย่อที่เกี่ยวข้องกับชื่อยาวเมื่อระบุ

  • ไปที่Runในเมนูเริ่ม
  • พิมพ์cmdและเมื่อคุณเห็นพรอมต์คำสั่งจากนั้นคลิกขวาที่มันแล้วเลือกRun as administrator
  • เมื่ออยู่ในพรอมต์คำสั่งให้พิมพ์fsutil พฤติกรรมที่ตั้งตั้ง disable8dot3 1เพื่อปิดการตั้งชื่อสั้น
  • Reboot

หากคุณต้องการเปิดใช้งานอีกครั้งให้พิมพ์fsutil behavior set disable8dot3 0


1
ไม่จริงทั้งหมด คุณเคยลองเข้าถึงโฟลเดอร์ที่มีไฟล์ 80k (เช่นโฟลเดอร์อีเมลที่ไม่ดีบนเซิร์ฟเวอร์) หรือไม่โดยไม่มีการปรับแต่งใด ๆ คุณสามารถรอหนึ่งวันก่อนที่จะระบุ
Piotr Kula

แน่นอนว่ามันไม่เป็นความจริงในทุกกรณี แต่ฉันก็ยังเชื่อว่าถ้าคุณทำถูกต้องและคงไว้ซึ่งกฎเกณฑ์คุณก็สามารถมีระบบการทำงานได้ คุณหมายถึงอะไรกับโฟลเดอร์อีเมลที่ไม่ดี
Jesper Jensen

1
คุณไม่เคยต้องจัดการกับเซิร์ฟเวอร์อีเมลมาก่อนอย่างชัดเจน :) คุณต้องเขียนคำตอบของคุณว่าถ้าได้รับการดูแลอย่างดี (ประมาณ 80% ของผู้ดูแลระบบไม่ทำเช่นนั้น) ก็จะไม่มีปัญหา นอกจากคำตอบของคุณไม่ได้พูดถึงประสิทธิภาพการอ่าน / เขียนและสิ่งที่การปิดใช้งาน 8dot3 จะทำเพื่อส่งผลกระทบต่อประสิทธิภาพการทำงาน ไม่มีข้อเท็จจริงที่จะช่วยได้ ขออภัยที่เจ็บปวดเช่น .. แต่คำตอบของคุณต้องการการปรับปรุง -1 จนกว่าคุณจะทำเช่นนั้น แจ้งให้เราทราบ
Piotr Kula

ฉันไม่เคยบอกว่าฉันได้จัดการกับเซิร์ฟเวอร์อีเมลหรือสิ่งที่กล่าวมานั้นมาจากการหมดอายุของฉันเอง (ยกเว้นส่วนเครือข่าย) :) มันอยู่ในคำตอบของฉันในการรักษาbut it will need alot of maintenance with that many files.. แต่ขอบคุณสำหรับคำวิจารณ์และฉันจะพยายามปรับปรุงคำตอบของฉันเล็กน้อย
Jesper Jensen

ดูความเห็นของ StephenR เกี่ยวกับคำตอบนี้ - ถ้ามีไฟล์จำนวนมากแล้วหลังจากปิดใช้งาน 8.3 ต้องตัดชื่อที่มีอยู่แล้ว 8.3 ชื่อออกเพื่อปรับปรุงความเร็ว
ToolmakerSteve
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.