xml地图|网站地图|网站标签 [设为首页] [加入收藏]
当前位置: www8029com > 澳门新葡8522最新网站 > 正文

能源等待之网络I

时间:2019-08-02 18:14来源:澳门新葡8522最新网站
一.概述  与网络I/O相关的等待的主要是ASYNC_NETWORK_IO,是指当sqlserver返回数据结果集给客户端的时候,会先将结果集填充到输出缓存里(ouputcache),同时网络层会开始将输出缓存里的数据

一.概述 

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

  1. 从实例级别查看ASYNC_NETWORK_IO

   澳门新葡8522最新网站 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)

  监听到的会话如下:

  澳门新葡8522最新网站 2

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

    澳门新葡8522最新网站 3

澳门新葡8522最新网站,  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 

   也可以能过界面来配置

  澳门新葡8522最新网站 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中解释是 网络读取过程中,连接正在等待网络数据包时出现。

    实际级等待如下图所示:
    澳门新葡8522最新网站 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

澳门新葡8522最新网站 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方式处理数据集,每次只从结果集拉取一条数据,而不是全部获取完毕后再处理。

  。客户端所在的服务器有某些性能问题,导致客户端运作缓慢。

  。客户端运行在配置错误或者过载的虚拟机上,总之也是服务器本身的问题。

On the SQL Server side, the only possibility I know of for causing this is using MARS (Multiple Active Result Sets) with large result sets.

You can demonstrate this wait type easily by running a query with a large result set through SSMS on the SQL Server itself, with no network involved.

在数据库服务端,就我所知唯一可能的原因就是使用了MARS的大结果集引起的。(其实就是因为结果集太大)

你可以很轻易的通过在数据库服务器上使用本机名登录的方式,运行一个获取大结果集的查询,来验证这个等待事件是否会出现。

Some other things you can try:

  • Look for incorrect NIC settings (e.g. TCP Chimney Offload enabled) with the help of your network/system administrator. Whether some settings should be enabled or not depends on the underlying OS version. See this post for some more details.
  • Consider increasing the TDS packet size (carefully) – see this post for more details.

其他的一些尝试:

  。是否有其他的网络设置错误,联系你的网络管理员修改一些注册表中的网络参数,一些参数在某些OS版本中是否应该被启用参考这里(见如上超链接)。

  。考虑增加TDS的包大小(谨慎一些),参考这里(见如上超链接)。

PREEMPTIVE_OS_WAITFORSINGLEOBJECT

Description:

This wait type is when a thread is calling the Windows WaitForSingleObject.aspx) function for synchronization with an external client process that is communicating using that object.

(Books Online description: N/A --表示联机丛书没有说明)

这个等待事件表示一个线程正在向外部客户端进程同步某个对象的数据,因此出现此种等待。一般此种等待出现在SQL Server 2012及以上的版本,以前用ASYNC_NETWORK_IO代替。

Other information:

This wait type is commonly seen in conjunction(同时出现) with ASYNC_NETWORK_IO, depending on the network transport used to communicate with the client, so to troubleshoot, follow the same steps as for ASYNC_NETWORK_IO.

Note that when a thread calls out to Windows, the thread changes from non-preemptive (SQL Server controls the thread) to preemptive (Windows controls the thread) mode. The thread’s state will be listed as RUNNING, as SQL Server doesn’t know what Windows is doing with the thread.

这种等待事件一般与ASYNC_NETWORK_IO等待事件一起出现,取决于连接所使用的网络传输类型,因此解决步骤参考ASYNC_NETWORK_IO的解决方式。

注意,当一个连接线程被从SQL Server控制(非抢占式)到被Windows控制(抢占式)的后,线程的状态就会变为running,此时SQL Server并不知道windows在对此线程做什么。

关于抢占式与非抢占式的区别,参考官网博客中关SQL OS与Windows OS对线程的不同处理方式的介绍。

 

编辑:澳门新葡8522最新网站 本文来源:能源等待之网络I

关键词: www8029com