SMB声称“慢”

我们公司的网络（我相信这是服务器2008上运行的Windows域）非常缓慢。一个很好的例子是通过SMB复制文件-列表需要几分钟，甚至复制大小适中的文件也需要更长的时间。当被问及此问题时，IT经理（尽管他可能有其他优点，但他是一个非常顽固而不是一个非常技术性的人）举起手来，变得非常防御并给出借口，而不是倾听和尝试去做。找出问题的根本原因。

现在，意识到这个问题的人为因素需要花费一些时间和精力来解决，所以我不知道如何从技术上反驳他的借口。在这种情况下，他声称SMB是问题所在，并且它是“慢速”协议。此声明是否有任何证据（我只有轶事反证）？在这种争论中取得进展的最佳方法是什么？

SMB可能比其他一些文件共享协议要慢，也可能比其他一些协议要快。但这不是重要的部分。

除了提出问题/争论之外，您还可以找到一种方法继续进行下去，并询问SMB是否像预期的那样快（或慢！）。例如，您是否可以在服务器和工作站之间使用FTP传输文件，该文件会受到速度的影响，并且性能明显下降？

供应商也许可以为您指出有关安装了Windows的硬件的评论，其中涉及文件服务器性能。

以我的经验，SMB不仅在我的网络上“足够快”。我们正在服务器之间运行10Gb网络，我们对使用SMB的文件服务器性能感到非常满意，并且根据使用1Gb还是10Gb NIC的情况，我们在相同硬件上测得了良好的性能飞跃。SMB对我们来说不是问题。

我当然会在网络上查看其他信息-基础设施是否过时，配置是否最佳（例如，服务器网卡都已针对最新驱动程序正确配置，以最佳速度正常运行），DNS等问题？在所有配置正确的网络上，是否有大量的“垃圾”流量导致速度下降，是防病毒配置过于偏执（我已经看到这会导致一些令人震惊的速度下降）。

可能导致文件服务器性能下降的原因很多，而很少是协议选择。

尽管协议的速度比SMB快，但从本质上来讲并不算慢。

但是，它可能比其他协议更容易受到外部影响，这些其他协议是饱和服务器，饱和网段等。

如果我是一个赌博的人，我会怀疑您的网络可以进行重新设计或进行一些投资，因为许多公司的常规办公网络尚未升级，以考虑到近年来互联网和Intranet流量的巨大增长。另外，服务器很有可能需要更换或重新工作以从中获得最佳收益。

无论哪种方式，我都不会过分强调SMB是直接的罪魁祸首，它很可能只是老旧的网络和服务器套件的推手。

它确实比NFS或FTP具有更多的开销（用于传输）。大型目录的文件列表可能需要一段时间-其中某些原因是SMB，某些原因是NTFS，某些原因是各种版本的Explorer和已安装的软件可以从客户端执行的愚蠢操作。诸如基于文件的数据库（访问，PST文件）之类的某些东西不应通过慢速（WAN）链接打开，因为它们不能很好地处理延迟。

话虽如此，您描述的操作应该不会花费很长时间。也许文件服务器电源不足。也许公司将某些软件作为标准安装的一部分来减慢运行速度。可能是配置错误的病毒扫描程序。也许有病毒。也许您和服务器之间没有广域网链接。

1. 如果通过命令行而不是资源管理器来列出文件，是否更快？
2. 复制如何？
3. 从您的桌面Ping有问题的服务器-延迟是多少？
4. 进行路由跟踪-您和服务器之间有多少跳？

不幸的是Nate，我们无法直接处理PHB。您的第一道防线是实际指标，例如，在SMB传输和NFS之间进行比较。

一旦有了实际数字或统计数据来支持您的论据，您就不需要那么多地处理人为因素。统计数据表明“问题出在这里，这就是证明”。那是你的论点。

你能缩小范围吗？在同一子网上的服务器到服务器传输是否有更好的结果？从一个客户端转移到另一个客户端（\\client\c$→ \\client\d$）怎么样？

您可能会发现一些简单的问题，例如双工不匹配。

我知道这很旧，但是要考虑的一个非常重要的因素是磁盘I / O。如果磁盘写入性能由于软件/主板RAID而不是带有专用内存的基于硬件的RAID卡而异常降低。

网络负载是一个因素，但是作为系统管理员最好的做法是查看资源监视器，并检查瓶颈的根源-检查“概述”选项卡以显示总体CPU，网络，磁盘I / O，内存等。从这个有利位置，您可以看到是否有一个罪魁祸首的进程或一组进程吞噬了磁盘I / O，或者发生了内存泄漏（SQLServer.exe-SBSMonitoring实例），等等。带宽，检查该过程，并检查与该过程相关的主机数量和主机。在3389上可能有很多对RDP的黑客尝试。我以前已经看到这种情况，我们的解决方案是删除直接RDP访问并将最终远程用户转移到VPN。

希望这可以帮助！