ASYNC_NETWORK_IO和PREEMPTIVE_OS_WAITFORSINGLEOBJECT等待事件

一.概述 

  与网络I/O相关的等待的主要是ASYNC_NETWORK_IO,是指当sql server返回数据结果集给客户端的时候,会先将结果集填充到输出缓存里(ouput cache),同时网络层会开始将输出缓存里的数据打包,由客户端接收。如果客户端接收数据包慢,sql server没有地方存放新数据结果时,这时任务进入ASYNC_NETWORK_IO等待状态。

  1. 从实例级别查看ASYNC_NETWORK_IO

   图片 1

   平均耗时: 46366950.0/43014737.0=1.077ms, 最大等待时间:~40秒。

  2. 重现ASYNC_NETWORK_IO等待

     为了演示ASYNC_NETWORK_IO 现象,我们需要输出一个大结果集。当sql server内存完全被使用后,大量的数据填充到缓存里,此时sql server没有地方存放新数据结果,进入等待状态。

-- 一次查询100000条数据输出到客户端
SELECT TOP 100000 * FROM PUB_Stock WITH(nolock)

  监听到的会话如下:

  图片 2

  使用dbcc inputbuffer 查询64结果如下:

    图片 3

  3.分析与解决

    这个等待出现的问题强调以下几点:

    (1) 客户端没有把数据及时取走,调整sqlserver 的配置一般情况下是不是有什么大的帮助。

    (2) 网络层可能是问题的原因。  解决:1是减少对客户端大量数据输出。 2是加大sqlserver 的network packe size,从一定程度上优化网络转输的性能,但会增加内存的开销(建议小于设置小于8kb)。

    network packe size是客户端与sqlserver通信的每个数据包大小有关系。network packe size设置的数据包存放于内存功能组件的connection类别里。默认是4kb设置,输入输出缓存会放在buffer pool里,如果改成了8kb 或更大,输入输出缓存会放在multi-page里 关于内存可查看sql server 内存初探。 设置network packe size 可以由sp_configure控制。客户端应用程序可以覆盖此值如在.net 里配置如下。

Data Source=(local);Initial Catalog=AdventureWorks;"Integrated Security=SSPI;Packet Size=512

    演示将 net work packe size设置成6050字节

USE AdventureWorks2012 ;  
GO  
EXEC sp_configure 'show advanced options', 1;  
GO  
RECONFIGURE ;  
GO  
EXEC sp_configure 'network packet size', 6500 ;  
GO  
RECONFIGURE;  
GO 

   也可以能过界面来配置

  图片 4

    (3) 应用程序端性能问题,也会导致sql server里的ASYNC_NETWORK_IO等待。

      sqlserver 的网络层将结果集打包好发向客户端以后,要等到客户端确认收到,才会接着发下一个包。

    (4) 分布式锁

      如果长时间看到ASYNC_NETWORK_IO,同时在sqlserver内部又造成了阻塞,并且该等待持续了很久,就该怀疑是否是分布式的死锁。

  总结:当遇到ASYNC_NETWORK_IO等待,需要检查应用程序自己的健康状况,也要检查应用是否有必要向sql server 申请这么大的结果集返回,一般来讲sqlserver 本身没有什么问题。

背景环境:

二. 其它网络I/O等待

  这里还有其它几个NET_WAITFOR_PACKET,PROXY_NETWORK_IO,EXTERNAL_SCRIPT_NETWORK_IOF。
  2.1 NET_WAITFOR_PACKET: 在msdn中解释是 网络读取过程中,连接正在等待网络数据包时出现。

    实际级等待如下图所示:
    图片 5   
2.2 后面二个proxy_network_io,external_script_network_iof。在生产环境下没有数据。在msdn中也没有找到相应解释。只能通过字面含义去解释。

SQL Server 2005或以上

Select * from 某个表,表的数据量约为30万行,在执行语句时通过观察sys.dm_exec_requests中的wait_type列发现是ASYNC_NETWORK_IO等待,在本地MSSQL2012上测试时发现了PREEMPTIVE_OS_WAITFORSINGLEOBJECT等待,在本地2008R2测试时发现只有ASYNC_NETWORK_IO等待。

可以使用如下语句查询相关等待的等待时间:

select 
 session_id,
 db_name(database_id) as "db_name",
 status,
 wait_type,
 wait_time,
 text
from sys.dm_exec_requests cross apply sys.dm_exec_sql_text(sql_handle) 
where session_id>50

关于网络协议:

了解到:shared memory协议开启时,使用本机名登录会优先使用shared memory协议,因此此协议只适用于本地连接。

可以通过如下SQL获取所有非系统会话的网络协议使用情况:

select 
 session_id,
 most_recent_session_id,
 net_transport,
 auth_scheme,
 client_net_address,
 client_tcp_port,
 local_net_address,
 local_tcp_port 
from sys.dm_exec_connections

图片 6

从查询结果可以大致推断出本地SSMS作为一个客户端如果使用TCP/IP协议也是要走网卡的,而且执行结果显示了登录使用的协议以及登录验证方式还有使用的端口号。使用shared memory协议的连接不通过socket通信的方式获取数据,而是直接通过系统总线从共享内存读取。

关于等待事件:

ASYNC_NETWORK_IO

This wait type is where SQL Server has sent some data to a client through TDS.aspx) and is waiting for the client to acknowledge that is has consumed the data, and can also show up with transaction replication if the Log Reader Agent job is running slowly for some reason.

这个等待类型表示SQL Server正在通过TDS向客户端传送请求的数据,也可能表示事务复制的日志读取代理由于某些原因运作缓慢。

(Books Online description: “Occurs on network writes when the task is blocked behind the network. Verify that the client is processing data from the server.”)

(联机丛书的解释:当任务由于被阻塞于网络时出现,证明客户端正在接收服务端的数据)

Other information:

This wait type is never indicative of a problem with SQL Server, and the vast majority of the time it is nothing to do with the network either (it’s very common to see advice stating that this is a network issue). A simple test for network issues is to test the ping time between the SQL Server and the client/application/web server, and if the ping time is close to the average wait time, then the wait is because of the network (which may just be the normal network latency, not necessarily a problem).

这个等待类型表示并非SQL Server的问题,绝大多数情况下也与网络问题无关(很多时候大家都认为是网络问题),一个简单的测试方式是从客户端ping一下服务端,如果延迟接近sys.dm_exec_requests中wait_time的平均值则证明确实与网络相关(很多时候都只是正常的网络延迟,并不是网络故障)。

There is usually nothing that you can do with your SQL Server code that will affect this wait type. There are a few causes of this on the client side, including:

  • The client code is doing what is known as RBAR (Row-By-Agonizing-Row), where only one row at a time is pulled from the results and processed, instead of caching all the results and then immediately replying to SQL Server and proceeding to process the cached rows.
  • The client code is running on a server that has performance issues, and so the client code is running slowly.
  • The client code is running on a VM on a host that is configured incorrectly or overloaded such that the VM doesn’t get to run properly (i.e. slowly or coscheduling issues).

针对此等待事件一般无需对SQL代码做什么改动,引发此问题的原因基本都是由于来源于客户端,例如:

  。客户端代码使用RBAR方式处理数据集,每次只从结果集拉取一条数据,而不是全部获取完毕后再处理。

本文由美高梅官方网站发布于数据统计,转载请注明出处:ASYNC_NETWORK_IO和PREEMPTIVE_OS_WAITFORSINGLEOBJECT等待事件

TAG标签:
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。