如何深入了解 ASYNC_NETWORK_IO 等待

Question

我收到了一张来自 SolarWinds 的图表，其中显示了按天细分的主要等待事件。过去 2 天，每天有一部分颜色编码条代表 ASYNC_NETWORK_IO 总共 3 小时。仍在尝试查看是否可以访问 Solar Winds 面板，以尝试查看它是否提供深入了解图表的功能。

在过去的 2 个小时里，我一直在通过谷歌、网站和文档进行搜索，但没有发现任何结果来告诉我如何深入研究这 3 个小时。

它是一个大块吗，是一天中到处都是几分钟，它是否与任何特定的高 I/O 活动窗口（数据仓库刷新或其他）相匹配。

我所拥有的只是“昨天和前一天总共有 3 个小时的等待，现在告诉我为什么” - 我必须承认我真的不知道如何进一步深入研究。

我已经阅读了各种关于“嗯，它通常是一个设计不佳的应用程序”或类似内容的文章。

有趣的是，这是过去 7 天的，前 5 天都清楚。没有这种等待的迹象。突然有一大块。我需要知道如何挖掘更多。

据我所知，没有用户抱怨系统性能。

是否有 DMV 或其他可以帮助的东西？

任何人都可以给我一些指点？

谢谢

Answer 1

ASYNC_NETWORK_IO 从来都不是服务器端的问题。

此等待表明 SQL Server 有结果要发送到客户端，但正在等待客户端使用结果以便完成发送。

缓慢的网络有可能（尽管不太可能）是瓶颈。这几乎从来都不是原因，除非有人使用拨号质量的网络连接。此处的修复是更快的网络连接。（但这不是你的问题。）

应用程序也有可能由于设计不当而明确停止其结果的消耗。如果应用程序接受要显示的前 25 行，然后停止接受结果，迫使服务器等待……并且仅在用户点击“下一页”按钮时才显示接下来的 25 行，就会发生这种情况。在这种情况下，您需要将应用程序更改为一次使用整个结果集，然后仅在显示中处理分页，或者将应用程序更改为仅请求一页结果并暂时进行往返6 每次用户点击“下一页”。

最后，它可能是功能不足的客户端机器，或者是性能不佳的应用程序。SSMS 是那些性能不佳的应用程序之一。如果你这样做，SELECT * FROM dbo.HugeTrillionRowTable你会看到ASYNC_NETWORK_IO等待你的会话。此处的正确修复取决于细节。您可能需要向客户端计算机添加更多内存，或者扩展到更多客户端容器，或者更改应用程序中的代码（这是针对 SSMS 的修复，但不是微不足道的更改）。

在您的情况下，如果您可以获得对 SolarWinds DPA 的只读访问权限，您将能够深入等待以确定查询、客户端等以获取这些详细信息。如果您无法访问 DPA，您可以监控sys.dm_exec_session_wait_stats，尽管这只会向您显示当前正在运行的查询的信息，因此您需要在操作中捕获有问题的代码。事后没有“时间机器”DMV 可以返回。