我有一个开发工具，我将用它来生成五千万个文件。 目录结构深入四级。 顶级包含16个目录（2000 – 2000年），下一个级别 – 个月（1-12），下一个级别 – 天（1-31），最后是 – xml文件（每个高达85k）。 最终的目录可能有3000多个文件（我没有计算出如何在目录结构中容纳五千万个文件）。
我目前正在运行该实用程序，我约三分之一的方式（执行的天数）。 正如我担心的，遍历目录树的任何部分是一个痛苦的经历。 在探险家内需要几秒钟。 这与服务器级硬件。 SAS 7200RPM（我知道现在不是这么快）12 TB的Raid 5或者10，配了4个3.4ghz的xeon cpus。
如何增加Windows Server 2012 R2在内存中caching文件句柄的能力？ 我没有运行NFS服务。
M:\>defrag /a /v /hm: 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>
RAMMAP
图元文件细节：总计= 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/file
NtfsInfo 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的内存。 如果你想caching更多的“文件句柄”又称文件系统元数据，更多的内存将允许你在内存中有更多的内存。
无论使用什么文件系统，都会有元数据，而根据文件系统的使用模式，您可能更愿意投资更多的内存和/或更快的存储 。 如果元文件信息的数量是不现实的，将其全部存储在RAM中，并且您的文件使用模式通常处理新文件，而不是反复使用较小的文件子集，则更快的存储，如具有许多镜像对的RAID 10arrays可能需要更快的SSD和/或15K RPM SAS磁盘来限制查找时间并增加存储可处理的可用IOP数量。
请记住，Windows内存pipe理器的默认设置可能不适用于你的情况，你可能需要调整一些设置，特别是如果你不打算有足够的内存来适应RAM中的整个MFT，除了剩下的系统要求。 我注意到，几乎所有的图元文件数据都被标记为活动内存，这意味着Windowscaching系统在不使用时不允许将其从RAM中丢弃。 我可以使用Windows Server 2008 R2图元文件RAM使用情况下的 powershell脚本（即使在Server 2008到2012R2上，我预计到2016年）可以设置标记为活动状态的元文件内存量的最小值和最大值，并强制其余的值支持。 这允许caching系统更好地优先处理RAM中的内容。
编辑：虽然我不熟悉Jmeter，这听起来像文件系统的使用模式将是
有了这个使用模式，为了看到添加更多内存的合理好处，您将需要添加足够的内存以适应RAM中的整个MFT。 这通常是浪费金钱。 如果增加更多的RAM，并且升级存储以显着改善IOP，将会更具成本效益。 这应该比保留一个速度较慢的7.2K rpm磁盘raid5arrays，甚至是一个只有4个磁盘大量ram的raid10要快，因为元数据不是从存储器读取/写入的唯一数据。 将此计算器视为预期IOP性能的估算工具，以及不同数量的磁盘和RAID级别如何影响性能。
在上述情况下，添加更多内存的唯一方法可能比使用更快存储的系统更快，如果添加足够的内存，所有数据（包括文件内容）都将以ram的forms出现。 这就是为什么一些数据库系统宣布他们在内存中运行“100％”，因此没有存储系统延迟。