我
支持在
Windows Server 2003 SP2
文件共享上存储
文件的内部应用程序.由于它当前配置为存储
文件的方式,一个
文件夹中有~116,000个
文件(另一个
文件夹有~65,000个,其他
文件夹少,但每个
文件夹仍有几千个).写入
文件的应用程序变得非常慢.
文件布局可以配置为现存,所以我试图想出一个更好的计划.有没有人知道SMB在开始变得无法使用之前每个文件夹可以处理多少项？在这种情况下,它已经很慢了很长一段时间,但是直到文件夹超过100,000个文件才开始变得难以忍受.
它更多地依赖于带宽和延迟(尤其是延迟),而不是用于枚举目录的算法中的
文件数量和缩放比例.我想,没有“神奇的数字”就是我所说的.
SMB协议对于需要大量往返而言是可怕的.例如,具有两倍延迟的文件数量将是速度的两倍多.
您已经为LAN完成了基准测试,网络基础架构的延迟以及服务器计算机的IO子系统延迟.你显然找到了一个“神奇的数字”.我会缩小目录,直到性能变得更好.别无他法！
原文链接：https://www.f2er.com/windows/367520.html
