☰

如何调整 Windows Server 2012 R2 来处理包含 5000 万个文件的 NTFS 文件结构？

tag-icon • tag-icon windows-server-2012-r2 cache vmware-vsphere ntfs
如何调整 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/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
---------------

答案1

您目前有一个大小为 0x320900000 = 13,431,209,984 字节 = 12 GiB 的 MFT，其中只有 2GiB 位于内存中。如果您想缓存更多“文件句柄”（即文件系统元数据），则更多 RAM 将允许您在内存中拥有更多。

不管你使用什么文件系统，都会有元数据，根据文件系统的使用模式，你最好投资更多 RAM 和/或更快的存储如果元文件信息的数量不足以将其全部存储在 RAM 中，并且您的文件使用模式通常是处理新文件而不是重复使用较小的文件子集，那么可能需要更快的存储，例如具有许多镜像对的 raid 10 阵列，这些镜像对由更快的 SSD 和/或 15K RPM SAS 磁盘组成，以限制寻道时间并增加存储可以处理的可用 IOP 数量。

请记住，Windows 内存管理器的默认设置可能不适用于您的情况，您可能需要调整一些设置，特别是如果您不打算拥有足够的 RAM 来容纳整个 MFT，以及系统其余部分所需的 RAM。我注意到几乎所有的图元文件数据都被标记为活动内存，这意味着 Windows 缓存系统不允许在不使用时将其从 RAM 中丢弃。我的 powershell 脚本Windows Server 2008 R2 图元文件 RAM 使用情况可用于（甚至在 Server 2008 到 2012R2 上，我预计 2016 上也如此）设置标记为活动的图元文件内存量的最小值和最大值，并强制其余内存处于待机状态。这允许缓存系统更好地优先处理 RAM 中的内容。

编辑：虽然我不熟悉 jmeter，但听起来文件系统的使用模式将是

  1. 按顺序把它们全部写下来。
  2. 尽可能快地、连续地阅读所有内容
  3. 以部分随机的模式再次读取所有文件（因为每个线程都竞争读取它想要的文件组）并通过网络发送它们

按照这种使用模式，要想看到增加大量 RAM 的合理好处，您需要添加足够的 RAM 来容纳整个 MFT。这通常是浪费金钱。而增加一点 RAM 并升级存储以显着提高 IOP 则更具成本效益。这应该比保留慢速 7.2K rpm 磁盘 raid5 阵列或甚至仅由 4 个磁盘组成的具有大量 RAM 的 raid10 更快，因为元数据不是从存储读取/写入的唯一数据。请参阅这个计算器作为预期 IOP 性能的评估工具，以及不同数量的磁盘和 raid 级别如何影响性能。

在上述情况下，添加更多 RAM 比使用具有更快存储的系统更快的唯一方法是，如果您添加足够的 RAM，则所有数据（包括文件内容）也将位于 RAM 中。这就是为什么一些数据库系统宣称它们“100% 在内存中”运行，以便没有存储系统延迟。

相关内容