D-K*_*otz 6 ntfs cache vmware-vsphere windows-server-2012-r2
我有一个开发人员实用程序，我将用它来生成 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/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。如果您想缓存更多“文件句柄”（即文件系统元数据），则更多 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 个磁盘和大量 ram 组成的 raid10 更快，因为元数据不是唯一从/向存储读取/写入的数据。见这个计算器如预期的IOPS性能的评估工具，以及如何不同数量的磁盘和RAID级别的影响性能。
在上述情况下，添加更多内存比使用存储速度更快的系统更快的唯一方法是，如果添加足够的内存，所有数据（包括文件内容）也将在内存中。这就是为什么一些数据库系统宣称它们在“100% 内存”中运行，以便没有存储系统延迟。
| 归档时间： |
|
| 查看次数： |
4594 次 |
| 最近记录： |