如何調整 Windows Server 2012 R2 以處理具有 5000 萬個文件的 NTFS 文件結構？
我有一個開發人員實用程序，我將使用它來生成 5000 萬個文件。目錄結構有四層深。頂層包含 16 個目錄（2000-2016 年），下一層 - 月 (1-12)，下一層 - 天 (1 - 31)，最後是 - xml 文件（每個最多 85k）。最終目錄可能有 3000 多個文件（我還沒有計算出 5000 萬個文件如何適合該目錄結構）。
我目前正在執行該實用程序，並且大約完成了 1/3（執行天數）。正如我所擔心的，遍歷目錄樹的任何部分都是一種痛苦的經歷。在資源管理器中需要幾秒鐘。這與伺服器級硬體。SAS 7200RPM（我知道現在這不快）12 TB Raid 5 或 10，分配有 4 個 3.4ghz xeon cpu。
如何增加 Windows Server 2012 R2 在記憶體中記憶體文件句柄的能力？我沒有執行 NFS 服務。
M:\>defrag /a /v /h m: Microsoft Drive Optimizer Copyright (c) 2013 Microsoft Corp. Invoking slab consolidation on DB MDF (M:)... The operation completed successfully. Post Defragmentation Report: Volume Information: Volume size = 12.99 TB Cluster size = 64 KB Used space = 1.55 TB Free space = 11.44 TB Slab Consolidation: Space efficiency = 100% Potential purgable slabs = 1 M:\>C:\Windows\system32>fsutil fsinfo ntfsinfo m: NTFS Volume Serial Number : 0x9c60357c60355de8 NTFS Version : 3.1 LFS Version : 2.0 Number Sectors : 0x000000067ffbefff Total Clusters : 0x000000000cfff7df Free Clusters : 0x000000000b6bcb45 Total Reserved : 0x0000000000000004 Bytes Per Sector : 512 Bytes Per Physical Sector : 4096 Bytes Per Cluster : 65536 Bytes Per FileRecord Segment : 1024 Clusters Per FileRecord Segment : 0 Mft Valid Data Length : 0x0000000320900000 Mft Start Lcn : 0x000000000000c000 Mft2 Start Lcn : 0x0000000000000001 Mft Zone Start : 0x00000000018f8780 Mft Zone End : 0x00000000018f9420 Resource Manager Identifier : A47067E0-6356-11E6-8 C:\Windows\system32>沖壓地圖
元文件詳細資訊：總計=2,882,220 K，活動=2,736,688 K，備用=143,968 K，修改=852 K，修改無寫入=712 K。
這個頁面還有什麼有趣的？
此時伺服器分配了16G的記憶體。我可以要求更多。
C:\Windows\system32>fsutil.exe 8dot3name query m: The volume state is: 1 (8dot3 name creation is disabled). The registry state is: 2 (Per volume setting - the default). Based on the above two settings, 8dot3 name creation is disabled on m: C:\Windows\system32>Contig v1.8 - Contig Copyright (C) 2001-2016 Mark Russinovich Sysinternals m:\$Mft is in 80 fragments m:\$Mft::$BITMAP is in 32 fragments Summary: Number of files processed: 2 Number unsuccessfully procesed: 0 Average fragmentation : 56 frags/fileNtfsInfo v1.2 - NTFS Information Dump Copyright (C) 2005-2016 Mark Russinovich Sysinternals - www.sysinternals.com Volume Size ----------- Volume size : 13631357 MB Total sectors : 27917021183 Total clusters : 218101727 Free clusters : 184577826 Free space : 11536114 MB (84% of drive) Allocation Size ---------------- Bytes per sector : 512 Bytes per cluster : 65536 Bytes per MFT record : 0 Clusters per MFT record: 0 MFT Information --------------- MFT size : 16210 MB (0% of drive) MFT start cluster : 49152 MFT zone clusters : 33255616 - 33258848 MFT zone size : 202 MB (0% of drive) MFT mirror start : 1 Meta-Data files ---------------
您目前的 MFT 為 0x320900000 = 13,431,209,984 字節 = 12 GiB，記憶體中只有 2GiB。如果您想記憶體更多的“文件句柄”（即文件系統元數據），更多的 RAM 將允許您在記憶體中擁有更多的記憶體。
無論您使用什麼文件系統，都會有元數據，並且根據文件系統的使用模式，您最好投資更多的記憶體和/或更快的儲存。如果將元文件資訊的數量全部儲存在 RAM 中是不切實際的，並且您的文件使用模式通常是處理新文件而不是重複使用較小的文件子集，那麼更快的儲存（如帶有許多鏡像對的 raid 10 陣列）可以條帶化可能需要使用更快的 SSD 和/或 15K RPM SAS 磁碟來限制尋軌時間並增加儲存可以處理的可用 IOP 數量。
請記住，Windows 記憶體管理器的預設設置可能不適用於您的情況，您可能需要調整一些設置，特別是如果您不打算擁有足夠的 RAM 來容納 RAM 中的整個 MFT 以及其餘的系統要求。我注意到幾乎所有的元文件數據都被標記為活動記憶體，這意味著 Windows 記憶體系統不允許在不使用時將其從 RAM 中丟棄。可以使用我在Windows Server 2008 R2 Metafile RAM Usage上的 powershell 腳本（甚至在 Server 2008 到 2012R2 上，我預計是 2016 年）設置標記為活動的圖元文件記憶體量的最小值和最大值，並強制其餘部分為支持。這允許記憶體系統更好地優先考慮 RAM 中的內容。
編輯：雖然我不熟悉 jmeter，但聽起來文件系統使用模式將是
- 按順序寫出來。
- 以大多數順序的方式盡可能快地閱讀它們
- 以部分隨機的模式再次讀取它們（因為每個執行緒競爭讀取它想要的文件組）以通過網路發送它們
使用這種使用模式，要看到添加更多記憶體的合理好處，您需要添加足夠多的記憶體以適應記憶體中的整個 MFT。這通常是浪費金錢。何時添加更多 RAM 併升級儲存以顯著提高 IOP 會更具成本效益。這應該比保持一個緩慢的 7.2K rpm 磁碟 raid5 陣列，甚至是一個只有 4 個磁碟和大量記憶體的 raid10 更快，因為元數據不是唯一從儲存讀取/寫入儲存的數據。將此計算器視為預期 IOP 性能的估計工具，以及不同數量的磁碟和 RAID 級別如何影響性能。
在上述情況下，添加更多 ram 比使用具有更快儲存的系統更快的唯一方法是，如果您添加足夠的 ram 以使所有數據（包括文件內容）也將在 ram 中。這就是為什麼一些數據庫系統宣傳它們“100% 在記憶體中”執行以便沒有儲存系統延遲的原因。