为什么会出现 async_network_io 等待类型？

Question

上周我们的数据库发生了一些奇怪的事情。突然之间，应用程序阻止了我们无法保存新实体等的用户。在查看 SQL Server（2008 兼容模式 2005）的活动监视器后，我看到以下三个条目：

一段时间后，用户出现连接超时。当我杀死进程64时，他们可以再次正常保存。

问题是他们在块期间尝试保存的实体被多次插入数据库（最多 3 次），即使有代码可以防止这种情况发生（数字列必须是唯一的但没有约束...检查发生在代码中）。

我们使用实体框架 6.0。

• 你们中有人知道这些 ASYNC_NETWORK_IO 等待类型发生的原因和时间以及如何避免它们吗？
• 它们究竟是什么意思？

Answer 1

ASYNC_NETWORK_IO以某种方式表明客户端应用程序处理结果的速度没有 SQL Server 提供它们的速度快。这可能是由客户端应用程序或服务器与客户端应用程序之间的网络连接问题引起的。

请参阅Thomas LaRock 的帖子

ASYNC_NETWORK_IO 等待表明正在发生两种情况之一。第一种情况是会话（即 SPID）正在等待客户端应用程序处理结果集并将信号发送回 SQL Server，表明它已准备好处理更多数据。二是可能存在网络性能问题。

或乔·萨克的这篇文章

您可能已经知道，ASYNC_NETWORK_IO（见于 SQL 2005）和 NETWORKIO（见于 SQL 2000）等待类型与调用应用程序没有足够快地处理来自 SQL Server 的结果或与网络性能问题相关联.

由于您正在使用entity framework Brent Ozar 的这篇文章可能也很有用

查看这些查询的等待统计信息，我看到有很多 ASYNC_NETWORK_IO — 通常超过 1000 毫秒。那也没有任何意义！CPU 时间如此之少且读取如此之少的查询如何需要如此长的时间才能完成？这不像应用程序要求数百万行并且不能足够快地使用结果。

Answer 2

关于 ASYNC_NETWORK_IO 等待类型存在一些误解，主要是因为名称表示网络问题，但这种等待类型的原因很少见。

在两种情况下可能会发生过度的 ASYNC_NETWORK_IO 等待：

1. 会话必须等待客户端应用程序处理从 SQL Server 接收到的数据，以便向 SQL Server 发送信号，表明它可以接受新数据进行处理。这是可能反映不良应用程序设计的常见情况，也是导致 ASYNC_NETWORK_IO 等待类型值过多的最常见原因。

   这涉及调查导致 ASYNC_NETWORK_IO 等待类型值过多的应用程序，并经常与创建它的应用程序开发人员协调。

2. 网络带宽已满。阻塞的以太网会导致应用程序来回数据传输缓慢。这本身会降低应用程序的效率。

可以在此页面上找到更多详细信息