从SAN安装的LUN
数十万个目录中的数百万个小文件(总共100GB)
具有4k簇大小的NTFS
在进行备份或归档的初始文件爬网时,对此驱动器上的文件的常规用户访问速度会非常慢.
SAN和网络人员在初步调查中没有显示异常活动,但更深入的调查仍在继续.怀疑存在NTFS或Windows的某种服务器级别问题.
鉴于几乎所有文件都<10k,因此适合1-3个集群,我不怀疑常规碎片是一个问题,但也许MFT碎片可能是.鉴于备份和清理甚至会导致用户中断,我甚至不愿意使用Windows碎片整理来分析我的碎片,我真的只关心MFT碎片.有人想比完整的磁盘分析更快地解决这个问题吗？ 如果有人有建议,表现良好的第三方碎片整理程序也不是不可能的.通过我们的分析不会进一步扰乱用户是一个重中之重. 我们还在考虑为NtfsdisableLastAccessUpdate添加reg密钥.有没有人发现这真的是一个很大的改进而不只是一个小小的调整？ 有没有很好的工具来衡量繁忙的驱动器的文件锁定/访问争用？ sysinternals中的GUI工具(如procmon)不再在该级别进行扩展.
要查看的是该卷上的队列深度.如果它的峰值明显高于备份卷的磁盘数量,那么您将达到IOPS限制. Perfmon会给你一个想法,但如果有可能获得那些,那么最好的数据将来自存储阵列自己的分析.我严重怀疑你的问题与文件锁定有关.存储人员需要查看RAID卷中磁盘上IOPS的IOPS,我怀疑这些磁盘每个都超过150个IOP(如果它们是15k则更高,如果它们是7.2k则更低) .如果你有一个托管该卷的6个磁盘RAID 10组,那么如果它真正备份了数百万个10k文件并且非常小,那么它将以不超过10Meg /秒的速度最大化.
NtfsdisableLastAccessUpdate将在您的情况下提供帮助 – 它从每个文件活动中删除一组IOPS,特别是它避免了与每个文件相关的几个额外读取和写入.鉴于你有数百万,你的文件或那么小,应该有一个重大的胜利,它可能会有50％的胜利.也就是说,您将看到的最可能的效果是您的备份将加速,但仍然会遇到IOP限制.
如果还没有完成,你还应该考虑aligning the disk partition.在这样的情况下(许多小读取),它并不像其他IO模式那样大赢,假设您的RAID条带大小为128k且平均读取大约为10k,可能大约为10％,但它可能值得努力.它需要备份整个卷,重新分区并重新格式化,然后恢复数据,这不是一个微不足道的练习.
