在我的繁忙的文件服务器上,MFT碎片可能是个问题吗?

从SAN挂载的Windows Server 2003 SP2 LUN成百上千个目录中的数百万个小文件(总共100GB)具有4k簇大小的NTFS

在执行初始文件抓取备份或归档常规用户访问此驱动器上的文件时会严重减慢速度。

SAN和networking人员在最初的调查中没有显示任何exception活动,但是深入的调查仍在继续。 怀疑某些与NTFS或Windows有关的服务器级别问题。

鉴于几乎所有文件都小于10K,因此可以适应1-3个群集,我不怀疑定期的碎片化是一个问题,但也许是MFT碎片化。 鉴于备份和清理导致用户中断甚至几个小时,我不愿意使用Windows碎片整理碎片分析,我真的只关心MFT碎片。 任何人都可以比完整的磁盘分析更快地得出结论吗?

行为良好的第三方碎片整理程序是不是没有问题,如果任何人有build议。 不要让用户进一步分析是我们的重中之重。

我们也正在考虑把NtfsDisableLastAccessUpdate的注册码放进去。 有没有人发现这是真正的大改进,而不是一个小调整?

有没有什么好的工具来测量繁忙驱动器的文件locking/访问争用? 像procmon这样的sysinternals的GUI工具不能在这个级别进行扩展。

当你像这样备份一个卷时,你将会认真行使底层存储。 当您开始阅读分布在文件系统周围的数百万个小文件时,限制因素将是SAN上的底层磁盘可以提供的随机读取IOPS。 SAN本身可能根本就没有被强调,但是您正在阅读的数据量将会受到影响,并且任何其他尝试在同一时间执行其他任何操作的进程都将受到影响,除非您减less备份活动。

要看的是该卷上的队列深度。 如果峰值显着高于备份容量的磁盘数量,则会达到IOPS限制。 Perfmon会给你一个想法,但最好的数据将来自存储arrays自己的分析,如果有可能得到这些。 我严重怀疑你的问题是与文件locking有关。 存储人员需要查看RAID包中的磁盘上的IOPS,从中可以看出,我怀疑这些磁盘的吞吐量是每个约150 IOP(如果是15k,则更高,如果是7.2k,则会降低) 。 如果你有一个容量为6个的磁盘RAID10组,那么如果真的备份了数百万个10K文件,那么它的最大速度就不会比10Mg / sec更好,而只有很小的数量会大得多。

NtfsDisableLastAccessUpdate将有助于您的情况 – 从每个文件活动中删除一组IOPS,特别是避免了与每个文件相关的多个额外的读写操作。 考虑到你有数百万,而且你的文件还是那么小,应该有一个重大的胜利,它可能是多达50%的胜利。 这就是说你看到的最可能的影响是你的备份速度会加快,但是仍然会遇到IOP限制。

如果还没有完成,您还应该考虑alignment磁盘分区 。 在这样的情况下(大量小读取),它不会像其他IO模式那样大,如果您的RAID条带大小为128k,平均读取大约为10k,则可能大约为10%值得努力。 这将需要对整卷进行备份,对其进行重新分区和重新格式化,然后恢复数据,这不是一件小事。

在分析模式下运行磁盘碎片整理是我知道你有多lessMFT碎片的唯一方法。

如果音量正在使用24 x 7,那么你可能会卡住“干扰”用户。 如果不是,则安排“defrag -a -v C:”命令在非工作时间运行,并将其输出redirect到文件。 这将得到命令输出w / o要求你在星期天凌晨4点醒来运行它。 >微笑<

我不能给你统计:“NtfsDisableLastAccessUpdate”,但我一定会设置它,除非你需要保存上次访问时间。 (我会使用“fsutil behavior set disablelastaccess 1”命令,而不是将其设置在registry中,而且必须重新启动以使更改生效。

如果您不需要,也可以考虑禁用8dot3文件名创build。 做到这一点,特别是如果你在一个目录中有大量的文件。 (虽然把它关掉不会消除已经存在的8dot3名字…)

在缓慢的“初始抓取”之前/之后比较有关卷上的“fsutil fsinfo统计信息”的输出可能会告诉您有关正在发生的事情,尽pipe我认为它只是表明发生了大量的元数据读取。

在SAN上是否有足够的空间将卷的全部内容恢复到与configuration类似(与SAN属性相关的RAID级别等)configuration为生产LUN的全新LUN? 如果从一开始就禁用新创build的NTFS文件系统(8dot3名称创build),并且可能还有一个不同大小的MFT区域,则与生产LUN相比,这将会很有趣。 (如果分段LUNcertificatefunction更好,则通过将更改后的文件从生产LUN复制到此分段LUN来编排迁移也不会太困难。)

我发现减速发生在成千上万个具有相同的5个字母作为前缀的文件中。 我的理论是在这种情况下NTFS MFT B +树被创build得太深而且不平衡。 将文件恢复到全新的磁盘没有重复的问题,所以我怀疑这是不是一个新鲜的创build文件所有在一个连续的文件,而不是随机创build的文件(有时是这些前缀文件之一,有时不是)一个已经碎片化的磁盘。

我们计划随机化名称,并调查未来的禁用8dot3名称。