[20140504] ADO.NET客户端超时

背景:

最近总是出现客户端超时,那么根据超时进行排查

System.Data.SqlClient.SqlException (0x80131904):
Timeout expired.  The timeout period elapsed prior to completion of
the operation or the server is not responding.

原理:

客户端组件超时,一般分为Connection TimeOut 和Command
Timeout

超时主要有以下几方面:

1.从连接池获取一个连接超时

2.创建一个新的连接超时

3.发送一个命令(Command)到数据库超时

4.使用带有context
connection=true的属性连接发送命令(Command)到数据库超时。

5.当不是显示的发送命令(implicitly)到数据库超时。

6.执行异步命令时超时

7.从服务端获取记录时超时

8.使用bulk copy时超时。

上面8个,最有前面2个是属于 Connection Timeout,其他都是Command Timeout。

分析:

从错误来看就是Command Timeout报出的错误,客户端的Command
Timeout生成环境下的设置时默认的也就是30秒。

在数据库监控层,我们设置了XEVENT对超过10s的查询监控,还有手写的堵塞超过10s的监控,中间并没有发现有堵塞情况。

那么可以排除掉6,在执行命令时超时。

并且不使用context
connection=true那么可以排除掉4,带有context
connection=true属性发送Command命令。

也不会使用bulk copy,所以第8点也可以排除。

通过sys.dm_os_ring_buffers也没有发现sql
server主动断开连接。

结论:

那么可以认为是客户端在获取结果或者发送命令的时候,发生的超时。

参考:

《SQL Server
2012实施与管理实战指南》 第4章,第6章

[20140504] ADO.NET客户端超时,布布扣,bubuko.com

时间: 2024-08-04 12:12:19

[20140504] ADO.NET客户端超时的相关文章

Outlook Web App 客户端超时设置

这篇文章我们讨论一下,OWA 2013在公共和私人的电脑是如何启用和配置. Exchange 2013 Outlook Web App (OWA) 登录页不再允许用户选择无论他们正在使用公共的或私人的计算机.默认情况下,OWA 2013 是假定用户使用的是私人计算机,如使用超时的 8 小时.出于安全考虑,用户处于非活动状态之前要求用户重新登录. 在 Set-OWAVirtualDirectory cmdlet 中 LogonPagePublicPrivateSelectionEnabled 参数

[20140702]奇怪的应用程序超时

背景: 应用程序,在某个时刻或出现超时,一开始以为是dbcc checktable造成,使用了各种手段抓取sql,xevent,profile都没有找到. 之前还写了一篇,[20140117]疑似checkpoint堵塞数据库连接,其实问题不是这个. 问题: 出现超时一般是在索引整理的job运行的时候出现,所以怀疑是整理占用大量资源到时,在传输sql语句到sql server的时候出现超时. 不过具体,到底出在执行超时的哪一个环节,目前还不清楚,因为根本抓不到事件. 具体超时可以看:[20140

HBase客户端访问超时的多个因素及参数

在一个需要低延时响应的hbase集群中,使用hbase默认的客户端超时配置简直就是灾难. 但是我们可以考虑在客户端上加上如下几个参数,去改变这种状况: 1. hbase.rpc.timeout: RPC timeout, The default 60s, 可以修改为5000(5s) 2. ipc.socket.timeout: Socket link timeout, should be less than or equal to RPC timeout, the default is 20s

Java网络编程从入门到精通(16):客户端套接字(Socket)的超时

客户端套接字的超时(timeout)就是指在客户端通过Socket和服务器进行通讯的过程中,由于网络延迟,网络阻塞等原因,造成服务器并未及时响应客户端的一种现象.在一段时间后,客户端由于未收到服务端的响应而抛出一个超时错误; 其中客户端所等待的时间就是超时时间. 由于生产超时错误的一端都是被动端:也就是说,这一端是在接收数据,而不是发送数据.对于客户端Socket来说,只有两个地方是在接收数据:一个是在连接服务器时;另一个是在连接服务器成功后,接收服务器发过来的数据时.因此,客户端超时也分为两种

单点登录CAS使用记(二):部署CAS服务器以及客户端

CAS-Server下载地址:https://www.apereo.org/projects/cas/download-cas CAS-Client下载地址:http://developer.jasig.org/cas-clients/ CAS官方教程: https://wiki.jasig.org/display/CASUM/CAS+on+Windows+Quick+Setup+Guide 版本: CAS Server版本:cas-server-3.4.11 CAS Client版本:cas-

服务器和客户端同步状态,客户端不能依赖服务器的响应

有一类系统,基本上所有操作都要求在线.在客户端产生的数据,直接提交到服务器,本地不存数据,或者仅保存少量缓存数据.这类应用有一个优势,就是客户端和服务器的数据始终是同步的,罕有两端不一致的情况.但是也有缺点,即对网络条件要求高,在网络条件不好的时候,用户操作需要等待,甚至无法正常使用 我们的一个APP,与上述系统不同,是支持离线操作的.数据在本地和服务器各有一份,然后通过同步机制来保持一致.这样做的缺点是提升了系统的复杂性,因为如果设计有缺陷,就很容易发生两端数据不一致的情况:另外就是如果客户端

DSAPI多功能组件编程应用-HTTP监听服务端与客户端_指令版

前面介绍了DSAPI多功能组件编程应用-HTTP监听服务端与客户端的内容,这里介绍一个适用于更高效更快速的基于HTTP监听的服务端.客户端. 在本篇,你将见到前所未有的超简化超傻瓜式的HTTP监听服务,与前篇中的不同,在DSAPI中,指令版同时包含了服务端与客户端. 先来看一下使用方法,几乎不需要太多的说明,当然,它是支持事件的.所谓指令版,即服务端和客户端收发都是基于短字串的,比如客户端发一个"hello",服务端收到这个指令后返回一个"Hi".为确保传输的数据有

wifidog源码分析 - 客户端检测线程

引言 当wifidog启动时,会启动一个线程(thread_client_timeout_check)维护客户端列表,具体就是wifidog必须定时检测客户端列表中的每个客户端是否在线,而wifidog是通过两种方式进行检测客户端在线情况,一种是定时通过iptables获取客户端出入总流量更新客户端时间,通过最近更新时间进行判断(有新的出入流量则更新客户端时间,之后使用最新客户端时间与当前时间判断),一种是查询认证服务器,通过认证服务器的返回信息进行判断(将客户端IP和状态请求发送给认证服务器,

[转帖]Nginx的超时keeplive_timeout配置详解

Nginx的超时keeplive_timeout配置详解 https://blog.csdn.net/weixin_42350212/article/details/81123932 Nginx 处理的每个请求均有相应的超时设置.如果做好这些超时时间的限定,判定超时后资源被释放,用来处理其他的请求,以此提升 Nginx 的性能. keepalive_timeout HTTP 是一种无状态协议,客户端向服务器发送一个 TCP 请求,服务端响应完毕后断开连接. 如果客户端向服务器发送多个请求,每个请