Windows Server 2003 SP2 LUN 从 SAN 安装，数百万个小文件分布在数十万个目录中（总共 100GB），NTFS 具有 4k 簇大小
在执行备份或存档的初始文件抓取时，常规用户对此驱动器上的文件的访问速度会严重减慢。
SAN 和网络人员在初步调查中未发现任何异常活动，但进一步的调查仍在继续。怀疑存在 NTFS 或 Windows 的某种服务器级问题。
鉴于几乎所有文件都小于 10k，因此适合 1-3 个簇，我不认为常规碎片是一个问题，但 MFT 碎片可能是个问题。鉴于备份和清理甚至在非工作时间也会导致用户中断，我犹豫是否使用 Windows 碎片整理来分析我的碎片，我真正关心的是 MFT 碎片。有没有比全磁盘分析更快地找出答案的方法？
如果有人有建议，使用性能良好的第三方碎片整理程序也是可行的。我们的分析不会进一步打扰用户，这是我们的首要任务。
我们还考虑将 NtfsDisableLastAccessUpdate 添加到注册表项中。有没有人发现这真的是一个很大的改进，而不仅仅是一个小小的调整？
是否有任何好工具可以测量繁忙驱动器的文件锁定/访问争用？ sysinternals 的 GUI 工具（如 procmon）不再能扩展到该级别。
答案1
当您备份这样的卷时，您将严重消耗底层存储。当您开始读取分散在文件系统中的数百万个小文件时，限制因素将是 SAN 上底层磁盘可以提供的随机读取 IOPS。SAN 本身可能根本没有压力，但您正在读取的卷将受到冲击，并且任何试图同时执行其他操作的其他进程都将受到影响，除非您限制备份活动。
需要查看的是该卷上的队列深度。如果其峰值明显高于备份卷的磁盘数量，则表明您已达到 IOPS 限制。Perfmon 会为您提供一个想法，但如果可以获取，最佳数据将来自存储阵列自己的分析。我非常怀疑您的问题与文件锁定有关。存储人员需要查看您的卷所分割的 RAID 包中磁盘的 IOPS，我怀疑这些磁盘每个都达到约 150 IOP（如果是 15k，则更高，如果是 7.2k，则更低）。如果您有一个 6 磁盘 RAID 10 组托管该卷，那么如果它确实备份了数百万个 10k 文件，并且备份的文件很少，则其最大速率不会比 10Meg/秒好多少。
NtfsDisableLastAccessUpdate 会对您有所帮助 - 它会从每个文件活动中丢弃一组 IOPS，特别是它会避免与每个文件相关的一些额外读取和写入。考虑到您有数百万个文件，并且您的文件很小，因此应该会有显著的收益，收益可能高达 50%。也就是说，您最有可能看到的效果是您的备份速度会加快，但仍然会遇到 IOP 限制。
您还应该考虑对齐磁盘分区如果尚未完成。在这种情况下（大量小读取），它不会像其他 IO 模式那样带来很大的好处，假设您的 RAID 条带大小为 128k，平均读取量约为 10k，则可能约为 10%，但这可能值得付出努力。它将需要备份整个卷，重新分区和重新格式化，然后恢复数据，因此这不是一项简单的工作。
答案2
以分析模式运行磁盘碎片整理程序是我所知道的查看有多少 MFT 碎片的唯一方法。
如果该卷每周 7 天、每天 24 小时都在使用，那么您可能不得不“打扰”用户。如果不是，请安排“defrag -a -v C:”命令在非工作时间运行，并将其输出重定向到文件。这样您就可以获得命令输出，而无需您在周日凌晨 4 点醒来运行它。>微笑<
我无法为您提供有关“NtfsDisableLastAccessUpdate”的统计数据，但我肯定会设置它，除非您需要保存上次访问时间。（我会使用“fsutil behavior set disablelastaccess 1”命令，而不是在注册表中设置它。您也必须重新启动才能使更改生效。）
如果不需要，您也可以考虑禁用 8dot3 文件名创建。特别是如果您在单个目录中有大量文件时。（尽管关闭此功能不会删除已经存在的 8dot3 名称...）
比较此缓慢的“初始爬行”之前/之后相关卷上的“fsutil fsinfo statistics”的输出可能会告诉您一些有关正在发生的事情，尽管我认为它只是向您显示正在发生大量元数据读取。
SAN 上是否有足够的空间将整个卷的内容还原到与生产 LUN 配置类似的新 LUN（就其 SAN 属性而言 - RAID 级别等）？与生产 LUN 相比，看看新建立的 NTFS 文件系统（从一开始就禁用 8dot3 名称创建，并且 MFT 区域大小可能不同）的表现会很有趣。（如果暂存 LUN 被证明运行得更好，那么通过将更改的文件从生产 LUN 复制到此暂存 LUN 来安排迁移也不太困难。）
答案3
我发现，当有数万个文件以相同的 5 个字母作为前缀时，速度就会变慢。我目前的理论是，在这种情况下，NTFS MFT B+ 树创建得太深，不平衡。将文件还原到新磁盘后，问题没有再次出现，因此我怀疑，在新创建的文件全部排成一行时，这种情况会以某种方式得到适当平衡，而不是在已经碎片化的磁盘上随机创建文件（有时是这些前缀文件之一，有时不是）。
我们计划将名称随机化，并研究将来禁用 8dot3 名称。