巨大的“网络 I/O”类型资源等待
JFL*_*JFL 8 performance sql-server sql-server-2012 wait-types waits performance-tuning
我们有一个在 WinDev 中开发的内部应用程序，它使用在 Windows Server 2008R2 上运行的 Microsoft SQL Server 2012 SP2（内部版本 11.0.5058）数据库。
我们遇到了性能问题。同时，Activity Monitor 显示了大量的“网络 I/O”类型的等待，在这种情况下，“巨大”是指一台运行时间少于 6 天的服务器的累积等待时间为 700 万秒：
网络连接本身很好，服务器连接 10G，而客户端是连接 1Gb 的物理桌面或 10G 的远程桌面服务器。网络监控显示没有链路饱和，也没有任何其他网络问题。CPU、RAM 和磁盘 I/O 也很好。
从我读到的有关网络 I/O 等待的信息来看，它与查询返回的、客户端未使用的记录有关。所以我倾向于认为问题出在应用程序中，但我很难让开发人员对此进行调查（不是他们不愿意这样做，而是他们很忙，似乎他们对根没有任何线索原因及解决方法）
所以问题：
我认为性能问题与那些网络 I/O 等待有关吗？
我可以向开发团队提供什么线索来帮助他们确定原因？
除了修复应用程序之外，我是否可以对 SQL Server 本身进行一些微调以缓解该问题？
Eri*_*ing 13
- 停止使用活动监视器
- 使用sp_WhoIsActive找出实际发生的事情
它可能是备份，在这种情况下，你可以做很多不涉及硬件升级的事情（也许 1 Gb iSCSI 不是一个好主意......）
它可能是客户端代码消耗数据 RBAR（想想每一行的 foreach 循环），或者一次请求很多行（这是分页查询可以提供帮助的地方）。
它可能完全是别的东西！
要了解您的服务器最在等待什么，请访问firstresponderkit.org - 完全公开，我为这个开源项目做出了贡献 - 并抓取sp_BlitzFirst（或者，哎呀，全部抓取）。
自启动以来，您可以运行此命令来查看整个等待统计信息。
EXEC sp_BlitzFirst @SinceStartup = 1
或者这是为了在减速期间获取等待统计数据的样本。
EXEC sp_BlitzFirst @Seconds = 30, @ExpertMode = 1
希望这可以帮助！
监视来自其应用程序的查询，包括等待（您可以使用扩展事件执行此操作），然后从 sqlcmd 或 SSMS 运行相同的查询（但不将结果发送到网格）并进行比较。这应该可以帮助您区分无法足够快地使用结果的应用程序和无法足够快地传输数据的网络。
我不知道活动监视器中的“网络 I/O”是否仅映射到 ASYNC_NETWORK_IO，但在像您这样的网络上，等待几乎肯定只是由客户端消耗的延迟引起的。