多线程Windows服务中的多个同时SQL连接超时 [英] Multiple Simultaneous SQL Connection Timeouts In Multithreaded Windows Service

查看:131
本文介绍了多线程Windows服务中的多个同时SQL连接超时的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个用VS 2010(.NET 4.0)开发的多线程Windows服务,该服务可以具有数个线程到几十个线程,每个线程都通过Internet从速度较慢的服务器中检索数据,然后使用本地数据库记录此数据(因此该过程受Internet约束,而不受LAN或CPU约束).

I have a multithreaded Windows Service I've developed with VS 2010 (.NET 4.0) which can have anywhere from a few to a few dozen threads, each retrieving data from a slow server over the Internet and then using a local database to record this data (so the process is Internet-bound, not LAN or CPU bound).

以一定的规律性,我同时从多个线程中收到以下错误的泛洪/突发/突发事件:

With some regularity, I am getting a flood/flurry/burst of the following error from several threads simultaneously:

System.Data.SqlClient.SqlException(0x80131904):超时已过期.在操作完成之前已经过了超时时间,或者服务器没有响应.

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

此错误的调​​用堆栈通常为:

The call stack for this error is typically:

在System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)

at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)

在System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)

at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)

在System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection externalConnection,DbConnectionFactory connectionFactory)

at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)

在System.Data.SqlClient.SqlConnection.Open()

at System.Data.SqlClient.SqlConnection.Open()

我没有在连接字符串中指定连接超时,并且该数据库中还有其他应用程序和进程正在运行.有没有人遇到过这种行为,如果可以,可以采取什么措施来防止这种情况发生?

I'm not specifying a Connection Timeout in the connection string, and there are other applications and processes working in this database. Has anyone come across this kind of behavior and if so what was done to prevent it?

我的数据访问层中最常用的方法是这样的,而我所有其他DAL方法都遵循相同的方法:

The most commonly-called method in my data access layer looks like this, and all my other DAL methods follow the same approach:

using (SqlConnection con = new SqlConnection(GetConnectionString()))
using (SqlCommand cmd = new SqlCommand("AddGdsMonitorLogEntry", con))
{
    cmd.CommandType = CommandType.StoredProcedure;

    /* setting cmd.Parameters [snipped] */

    // We have been getting some timeouts writing to the log; wait a little longer than the default.
    cmd.CommandTimeout *= 4;

    con.Open();

    cmd.ExecuteNonQuery();
}

非常感谢!

编辑

考虑到在镜像环境中发生的这种情况,我确实应该提到所讨论的数据库是镜像的.在SSMS中以无自动故障转移(同步)的高安全性"模式将其标记为主体,同步".

Given comments about this occurring in mirrored environments, I should indeed mention that the database in question is mirrored. It's marked in SSMS as "Principal, Synchronized", in "High safety without automatic failover (synchronous)" mode.

编辑5/26/11

我在SQL Server日志中看不到任何指示任何问题的信息. (我无权访问该服务器上的Windows事件查看器,但我已要求某人来找我.)

I am seeing nothing in the SQL Server logs to indicate any problems. (I don't have access to the Windows Event Viewer on that server, but I've asked for someone to look for me.)

推荐答案

根据

According to the MSDN Blog post just created today (hooray for Google!):

Microsoft已经确认这是当前版本的ADO.NET中的问题.此问题将在Visual Studio 2011附带的ADO.NET版本中得到解决.

Microsoft has confirmed that this is a problem in the current release of ADO.NET. This issue will be fixed in ADO.NET version, ships with Visual Studio 2011.

在此期间,我们要求使用以下解决方法:

In the meantime, we request to use the following workarounds:

  1. 将连接字符串超时增加到150秒.这将使第一次尝试有足够的时间进行连接(150 * .08 = 12秒)

  1. Increase the connection string timeout to 150 sec. This will give the first attempt enough time to connect( 150* .08=12 sec)

在连接字符串中添加MinPool Size = 20.这将始终在池中至少维护20个连接,并且创建新连接的机会会减少,从而减少发生此错误的机会.

Add MinPool Size=20 in the connection string. This will always maintain a minimum of 20 connections in the pool and there will be less chances of creating new connection, thus reducing the chance of this error.

提高网络性能.将您的NIC驱动程序更新为最新的固件版本.当您的NIC卡与某些可伸缩网络包设置不兼容时,我们已经看到了网络延迟.如果您使用的是Windows Vista SP1或更高版本,则还可以考虑禁用接收窗口自动调整".如果启用了NIC组,则禁用它是一个不错的选择.

Improve the network performance. Update your NIC drivers to the latest firmware version. We have seen network latency when your NIC card is not compatible with certain Scalable Networking Pack settings. If you are on Windows Vista SP1 or above you may also consider disabling Receive Window Auto-Tuning. If you have NIC teaming enabled, disabling it would be a good option.

该文章本身很有趣,谈论TCP/IP连接重试算法.对所有说嘿,这看起来像与镜像有关……"的人们都表示敬意!并请注意有关此评论的原因是由于来自SQL Server的响应速度慢或由于网络延迟".

The post itself is an interesting read, talking about a TCP/IP connection retry algorithm. And kudos to all the folks who said "hey this looks like it's related to mirroring..."! And note the comment about this being "because of slow response from SQL Server or due to network delays".

UGH !!!

感谢所有发布者.现在我们都必须要求对.NET Framework进行修补(或其他一些ADO.NET修补机制),因此我们不必等待(购买)Visual Studio 11 ...

Thanks to everyone who posted. Now we must all ask for a patch to the .NET Framework (or some other ADO.NET patching mechanism), so we don't have to wait for (and buy) Visual Studio 11...

这篇关于多线程Windows服务中的多个同时SQL连接超时的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆