大家好!
最近阿里云ECS出现了一些奇怪的问题,在并发量大的时候,ASP.NET会抛出下面的异常:
System.Data.SqlClient.SqlException: 已成功与服务器建立连接,但是在登录前的握手期间发生错误。 (provider: SSL Provider, error: 0 - 等待的操作过时。) ---> System.ComponentModel.Win32Exception: 等待的操作过时。 --- 内部异常堆栈跟踪的结尾 --- 在 System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection) 在 System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection) 在 System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection) 在 System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions) 在 System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource`1 retry) 在 System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry) 在 System.Data.SqlClient.SqlConnection.Open() 在 Microsoft.Practices.EnterpriseLibrary.Data.Database.OpenConnection() 在 Microsoft.Practices.EnterpriseLibrary.Data.Database.ExecuteNonQuery(DbCommand command)
这类异常一般会在1分钟以内自动恢复。
一开始怀疑是阿里云RDS的问题,但是监控到RDS的连接数,IOPS以及CPU都是正常的,而且其他负载量低的ECS连接RDS也是没有问题的。
参考网上的一些回复检查了 netsh WinSock Show Catalog,没有发现异常。
现在怀疑是不是ECS的原因或者ASP.NET方面的问题。
我觉得有一点很重要,这个都是在并发量大的时候才会出现这个异常(而且这种并发都是因为同一个活动同一时间访问量太大的原因)。 之前会在访问页面的时候抛出异常,因为当时我们有记录访问日志,现在我们没有直接将访问日志写入数据库而是写入到消息队列,这样在访问时不会再出现异常, 现在是在点击提交按钮的时候抛出异常。因为是同一个活动的提交,会不会因此产生死锁之类的问题呢?另外在出问题的时间段内,还是有不少提交成功的,说明当时没有完全DOWN掉。
建议首先排除一下是不是阿里云RDS的问题,我们曾经遇到RDS问题时,也报这样的错误,详见:
云计算之路-阿里云上-寒流来袭:2014年12月23日21:45-23:15网站故障
云计算之路-阿里云上:13:43-13:44之间RDS故障影响了全站的正常访问
建议先对RDS进行主备库切换操作:RDS管理控制台 -> 服务可用性:点击右侧的“主备库切换”按钮
谢谢,主备库切换会导致少量数据丢失吗?如正在执行的SQL。
@Ray Wu: 这是热备切换,但我也不能确认不会造成少量数据丢失,建议在访问低峰时操作。