超时过期。操作完成之前的超时时间或服务器没有响应。声明已终止

我的网站有很多用户(每天2万-6万)，这是一个移动文件下载网站。我可以远程访问我的服务器(windows server 2008-R2)。
我以前收到过服务器不可用;错误，但我现在看到一个连接超时错误。
我不熟悉这个-为什么会发生这种情况，我该如何解决它?< / p >

完整的误差如下:

服务器错误在'/'应用程序。超时过期。超时时间 在操作完成之前已经过，或者服务器没有 响应。声明已终止。描述:一个 在执行当前web时发生未处理的异常 请求。的详细信息，请查看堆栈跟踪

.

.

Exception Details: System.Data.SqlClient.SqlException: Timeout 过期了。操作完成之前的超时时间 操作或服务器没有响应。声明是 终止。< / p >

源错误:

命令执行过程中产生了一个未处理的异常 当前的web请求。关于起源和位置的信息 可以使用下面的异常堆栈跟踪来识别异常

堆栈跟踪:

[SqlException (0x80131904): Timeout expired.]超时时间 在操作完成之前已经过，或者服务器没有 响应。声明已终止。] < br / > System.Data.SqlClient.SqlConnection。OnError (SqlException异常, Boolean breakConnection) +404
System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning() +412
.使用实例 System.Data.SqlClient.TdsParser。运行(RunBehavior RunBehavior, SqlCommand cmdHandler, SqlDataReader BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject statobj) +1363
System.Data.SqlClient.SqlCommand。FinishExecuteReader (SqlDataReader ds, RunBehavior RunBehavior, String resetOptionsString) +6387741
System.Data.SqlClient.SqlCommand.RunExecuteReaderTds (CommandBehavior cmdBehavior, RunBehavior, RunBehavior, Boolean, returnStream, Boolean Async) +6389442
System.Data.SqlClient.SqlCommand.RunExecuteReader (CommandBehavior cmdBehavior, RunBehavior RunBehavior, Boolean returnStream, String method, DbAsyncResult result) +538
System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery (DbAsyncResult result, String methodName, Boolean sendToPipe) +689
System.Data.SqlClient.SqlCommand.ExecuteNonQuery() +327
. exe NovinMedia.Data.DbObject。storedProcName RunProcedure(字符串, idatparameter [] parameters, Int32&rowsAffected) +209
DataLayer.OnlineUsers。Session_End Update_SessionEnd_And_Online(对象, Boolean Online) +440
NiceFileExplorer.Global。Application_Start(对象发送器，EventArgs e) + 163 < / p >

[HttpException (0x80004005): Timeout expired.]超时时间 在操作完成之前已经过，或者服务器没有 响应。声明已终止。] < br / > System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode (HttpContext context, HttpApplication app) +4052053
System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS (IntPtr appContext, HttpContext context, MethodInfo[] handlers) +191
.使用实例 System.Web.HttpApplication。InitSpecial (HttpApplicationState状态, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +352
.使用实例 System.Web.HttpApplicationFactory.GetSpecialApplicationInstance (IntPtr appContext, HttpContext context) +407
System.Web.Hosting.PipelineRuntime.InitializeApplication (IntPtr appContext) + 375 < / p >

[HttpException (0x80004005): Timeout expired.]超时时间 在操作完成之前已经过，或者服务器没有 响应。声明已终止。] < br / > System.Web.HttpRuntime。FirstRequestInit(HttpContext context) +11686928 System.Web.HttpRuntime。EnsureFirstRequestInit (HttpContext上下文) + 141 System.Web.HttpRuntime.ProcessRequestNotificationPrivate (IIS7WorkerRequest wr, HttpContext context) +4863749

< p > 回答后编辑: < br / > 我在Global.asax中的Application_Start如下所示:

protected void Application_Start(object sender, EventArgs e)
{
Application["OnlineUsers"] = 0;


OnlineUsers.Update_SessionEnd_And_Online(
DateTime.Now,
false);


AddTask("DoStuff", 10);
}

被调用的存储过程是:

ALTER Procedure [dbo].[sp_OnlineUsers_Update_SessionEnd_And_Online]
@Session_End datetime,
@Online bit
As
Begin
Update OnlineUsers
SET
[Session_End] = @Session_End,
[Online] = @Online


End

我有两种获取在线用户的方法:

  1. 使用Application["OnlineUsers"] = 0;
  2. 另一个使用数据库

因此，对于方法#2，我将所有OnlineUsers重置为Application_Start。该表中有超过482,751条记录。

1110745 次浏览
小开

你可以设置SQL命令的CommandTimeout属性来允许长时间运行SQL事务。

您可能还需要查看导致超时的SQL查询。

小开

@SilverLight . .这显然是数据库对象的一个问题。它可能是一个写得很糟糕的查询，或者缺少索引。但到目前为止，我不会建议您在不调查数据库对象的问题之前增加超时时间

NovinMedia.Data.DbObject.RunProcedure(String storedProcName, IDataParameter[] parameters, Int32& rowsAffected) +209

在这行代码上放置一个断点，以找出过程名称，然后通过查看过程的执行计划来优化过程。

在您发布有关存储过程的详细信息之前，我无法提供更多帮助。

小开

在你运行存储过程的代码中，你应该有这样的东西:

SqlCommand c = new SqlCommand(...)
//...

添加这样一行代码:

c.CommandTimeout = 0;

这将等待操作完成所需的时间。

小开
最佳答案

看起来您有一个比它应该花费的时间更长的查询。 从堆栈跟踪和代码中，您应该能够准确地确定该查询是什么

这种类型的超时有三个原因;

  1. 在某个地方出现了僵局
  2. 数据库的统计信息和/或查询计划缓存不正确
  3. 查询太复杂，需要调优
死锁可能很难修复，但很容易确定情况是否如此。使用Sql Server Management Studio连接到数据库。在左窗格中，右键单击服务器节点并选择活动监视器。看一下正在运行的进程。 正常情况下，大多数将处于空闲或运行状态。当问题发生时，您可以通过进程状态来识别任何被阻塞的进程。如果你右键单击该进程并选择细节，它将显示该进程执行的最后一个查询

第二个问题将导致数据库使用次优的查询计划。可以通过清除统计数据来解决:

exec sp_updatestats

如果这行不通，你也可以试试

dbcc freeproccache
当你的服务器负载过重时，你不应该这样做，因为它会暂时导致很大的性能损失，因为所有存储的procs和查询在第一次执行时都会重新编译。 然而，由于您声明问题发生有时，并且堆栈跟踪表明您的应用程序正在启动，我认为您正在运行一个只偶尔运行的查询。强制SQL Server不重用以前的查询计划可能会更好。有关如何做到这一点的详细信息，请参见这个答案

我已经谈到了第三个问题，但是您可以通过手动执行查询(例如使用Sql Server Management Studio)轻松确定查询是否需要调优。如果查询需要很长时间才能完成，即使在重置统计数据之后，您也可能需要对其进行调优。为了得到帮助，您应该在一个新问题中发布准确的查询。

小开

试一试

EXEC SP_CONFIGURE 'remote query timeout', 1800
reconfigure
EXEC sp_configure


EXEC SP_CONFIGURE 'show advanced options', 1
reconfigure
EXEC sp_configure


EXEC SP_CONFIGURE 'remote query timeout', 1800
reconfigure
EXEC sp_configure
< p >然后 重新构建索引

小开

我最近遇到了这个错误，经过简单的调查后，发现原因是存储数据库的磁盘空间不足(小于1GB)。

当我移出数据库文件(。MDF和.ldf)到同一服务器上的另一个磁盘(有更多的空间)，同一页面(运行查询)在3秒内超时加载。

在尝试解决此错误时，要调查的另一件事是数据库日志文件的大小。您的日志文件可能需要收缩。

小开
也许它会对某人有用。 我也遇到了同样的问题，在我的情况下，原因是SqlConnection被打开了，没有在我在循环中调用的方法中处理，大约有2500次迭代。连接池已耗尽。正确的处理解决了问题。

小开

虽然所有早期的答复都涉及这一问题，但并没有涵盖所有情况。

微软已经承认了这个问题，并在2011年为受支持的操作系统修复了这个问题，所以如果你得到这样的堆栈跟踪:

Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()
at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)

你可能需要更新你的. net程序集。

连接重试错误导致此问题

.镜像数据库的算法

当使用retry-algorithm时，数据提供程序等待 first read (SniReadSync)调用完成。调用被发送到 运行SQL Server的后端计算机，等待时间为 连接超时值乘以0.08。 但是，数据提供者错误地将连接设置为命中注定的连接 如果响应慢，如果第一个SniReadSync调用不是

.

.

.

详情见KB 2605597

https://support.microsoft.com/kb/2605597 < a href = " https://support.microsoft.com/kb/2605597 " > < / >

小开

我遇到了同样的问题，花了大约3天时间。我注意到，由于我们的记录数量不多，我们的高级开发人员在数据库中保留了2张图像和指纹。当我试图获取这个十六进制值，它需要很长时间，我计算平均时间来执行我的程序大约38秒。默认的命令超时是30秒，因此它小于运行存储过程所需的平均时间。我像下面这样设置我的命令超时

cmd.CommandTimeout = 50

它的工作很好，但有时如果你的查询超过50秒，它会提示同样的错误。

小开

我在sp_foo中有大计算问题，需要大时间，所以我固定了
用这个小代码

public partial class FooEntities : DbContext
{
public FooEntities()
: base("name=FooEntities")
{
this.Configuration.LazyLoadingEnabled = false;


// Get the ObjectContext related to this DbContext
var objectContext = (this as IObjectContextAdapter).ObjectContext;


// Sets the command timeout for all the commands
objectContext.CommandTimeout = 380;
}
小开

您必须设置CommandTimeout属性。你可以在DbContext子类中设置CommandTimeout属性。

public partial class StudentDatabaseEntities : DbContext
{
public StudentDatabaseEntities()
: base("name=StudentDatabaseEntities")
{
this.Database.CommandTimeout = 180;
}


protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
throw new UnintentionalCodeFirstException();
}


public virtual DbSet<StudentDbTable> StudentDbTables { get; set; }
}
小开

默认超时时间是15秒，要改变它，0是无限的，任何其他数字是秒数。

在代码中

using (SqlCommand sqlCmd = new SqlCommand(sqlQueryString, sqlConnection))
{
sqlCmd.CommandTimeout = 0; // 0 = give it as much time as it needs to complete
...
}

在你的网里。配置，“命令超时=0;”不超时，或低于1小时(3600秒)

  <add name="ConnectionString" connectionString="Data Source=ServerName;User ID=UserName;Password=Password;Command Timeout=3600;" providerName="System.Data.SqlClient" />
小开

超时，因为sql查询花费的时间超过了您设置的时间 在sqlCommand。CommandTimeout财产。< / p > 显然你可以增加CommandTimeout来解决这个问题，但是 在此之前，您必须通过添加索引来优化查询。如果你 在Sql server管理工作室中运行你的查询，包括actual 执行计划则Sql server管理工作室将建议 你适当的索引。大多数情况下，您将摆脱超时问题 如果你能优化你的查询。

小开

TLDR:

  1. 在数据量、网络设置和代码没有改变的情况下，重新启动应用程序和DB服务器是最快的修复方法。我们一向是这样做的
  2. 可能是指示失败的硬盘驱动器，需要更换检查系统通知

我经常因为各种原因遇到这个错误，并有各种解决方案，包括:

  1. 重构我的代码使用SqlBulkCopy
  2. incremental超时值，如在各种回答或检查中所述 底层原因(可能与数据无关)
  3. 连接超时(默认15秒)-在终止之前等待与SQL服务器建立连接所需的时间-与TCP/PORT相关-可以通过故障排除清单(非常方便的MSDN文章)
  4. 命令超时(默认30s) -等待查询执行所需的时间-查询执行/网络流量相关- 还具有故障排除过程(另一篇非常方便的MSDN文章)
  5. 重启服务器-两个应用程序&DB服务器(如果是独立的)-代码和数据没有改变的地方，环境必须改变-你必须做的第一件事。通常由补丁(操作系统，. net Framework或SQL Server补丁或更新)引起。特别是当超时异常出现如下(即使我们不使用Azure):
    • entityexception:可能是由于瞬时故障引发的异常。如果您正在连接到SQL Azure数据库，请考虑使用SqlAzureExecutionStrategy。——> System.Data.Entity.Core.EntityCommandExecutionException:执行命令定义时发生错误。详情请参阅内部异常。——> System.Data.SqlClient.SqlException:从服务器接收结果时发生传输级别错误。(提供程序:TCP提供程序，错误:0 -信号量超时时间已过期)——> System.ComponentModel。Win32Exception:信号量超时时间已经过期
      • 李< / ul > < / >
小开

还要确保没有待处理的事务。：）

我做了一些测试，开始了一个交易以确保安全，但从未关闭它。我希望错误会更明确，但哦，好吧!

小开

我们在Timeout expired/max pool reached Sqlexception上遇到了困难。为了避免重新启动服务器或服务，我们在SQL server中修改MAX SERVER MEMORY变量(通过SQL management Studio或T-SQL):

DECLARE @maxMem INT = 3000 --Max. memory for SQL Server instance in MB
EXEC sp_configure 'show advanced options', 1
RECONFIGURE

这将暂时修复问题，直到再次发生。在我们的例子中，我们怀疑这与应用程序级别的连接泄漏有关。

小开

我们最近升级到包含bug的__ABC0 (Microsoft.Data.SqlClient)的NuGet版本。此错误是在1的生命周期中引入的。X周期，已经固定。该修复将在2.0.0版本中可用，但在撰写本文时还不可用。可以预览一下。

你可以在这里查看细节: https://github.com/dotnet/SqlClient/issues/262 < / p >

小开

如果您正在使用ASP。NET Core使用Startup.cs约定，你可以像这样访问和设置查询命令超时选项:

public void ConfigureServices(IServiceCollection services)
{
services.AddDbContextPool<MyDbContext>(_ =>
{
_.UseSqlServer(Configuration.GetConnectionString("MyConnectionString"), options =>
{
options.CommandTimeout(180); // 3 minutes
});
});
}
小开

我也遇到了同样的问题，并通过添加“连接时间”来解决。网络的价值。配置文件。找到connectionStrings并添加连接超时= 3600,

这是样本

  <connectionStrings>
<add name="MyConn" providerName="System.Data.SqlClient" connectionString="Data Source=MySQLServer;Initial Catalog=MyDB;User ID=sa;Password=123;Connection Timeout=3600" />
</connectionStrings>
小开

此外，您还需要检查单个记录是否没有在逻辑中得到更新，因为在该位置使用更新触发器也会导致超时错误。

因此，解决方案是确保在循环/游标之后执行批量更新，而不是在循环中一次执行一条记录。

小开

我有这个问题，当我从ADO。网移动到衣冠楚楚的进行查询时，它就消失了。

小开

我曾经遇到过这个问题，在我的情况下是一个未提交的SQL事务。在我投入之后，问题就消失了。

小开
正如其他人所说，这个问题可能与一个悬而未决的事务有关。 在我的例子中，我必须将DbTransaction变量作为ExecuteScalar方法中的参数发送，以便正确执行过程

之前:

ExecuteScalar(command)

后:

ExecuteScalar(command, transaction)
小开

在我的例子中，我使用EntityFrameworkCore。< br > 由于我想处理的输入超过了查询限制，这个错误来找我。< br > 我的解决方案是分裂数据处理到块，通过这种方法，我能够适应限制。< br > 是的，这需要时间，但至少它处理了所有的输入记录

小开

我在我的多线程程序上得到了同样的错误，有超过2000个用户同时连接。当我运行一个超过5000行的SELECT命令时，问题发生了。该命令被插入命令阻止。通过将SELECT *更改为SELECT Top(n) *， n<5000它修复


提交答案