windows-server-2003 – 我的繁忙文件服务器上的MFT碎片可能会出现问题吗?

前端之家收集整理的这篇文章主要介绍了windows-server-2003 – 我的繁忙文件服务器上的MFT碎片可能会出现问题吗?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
Windows Server 2003 SP2
从SAN安装的LUN
数十万个目录中的数百万个小文件(总共100GB)
具有4k簇大小的NTFS

在进行备份或归档的初始文件爬网时,对此驱动器上的文件的常规用户访问速度会非常慢.

SAN和网络人员在初步调查中没有显示异常活动,但更深入的调查仍在继续.怀疑存在NTFS或Windows的某种服务器级别问题.

鉴于几乎所有文件都<10k,因此适合1-3个集群,我不怀疑常规碎片是一个问题,但也许MFT碎片可能是.鉴于备份和清理甚至会导致用户中断,我甚至不愿意使用Windows碎片整理来分析我的碎片,我真的只关心MFT碎片.有人想比完整的磁盘分析更快地解决这个问题吗? 如果有人有建议,表现良好的第三方碎片整理程序也不是不可能的.通过我们的分析不会进一步扰乱用户是一个重中之重. 我们还在考虑为NtfsDisableLastAccessUpdate添加reg密钥.有没有人发现这真的是一个很大的改进而不只是一个小小的调整? 有没有很好的工具来衡量繁忙的驱动器的文件锁定/访问争用? sysinternals中的GUI工具(如procmon)不再在该级别进行扩展.

当您备份这样的卷时,您将认真地运行底层存储.当您开始阅读散布在文件系统周围的数百万个小文件时,限制因素将是SAN上的基础磁盘可以提供的随机读取IOPS. SAN本身可能根本不会受到压力,但是您正在读取的卷将受到打击,并且除非您减少备份活动,否则任何其他尝试同时执行任何其他操作的进程都将受到影响.

要查看的是该卷上的队列深度.如果它的峰值明显高于备份卷的磁盘数量,那么您将达到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%,但它可能值得努力.它需要备份整个卷,重新分区并重新格式化,然后恢复数据,这不是一个微不足道的练习.

原文链接:https://www.f2er.com/windows/366057.html

猜你在找的Windows相关文章