【问题标题】:SQL Server DbCommand Timeout with .Net Core container under loadSQL Server DbCommand Timeout with .Net Core container under load
【发布时间】:2019-12-07 18:17:37
【问题描述】:

我在 Open Shift Enterprise V3 上运行一个指向 SQL Server 数据库的 .Net Core 容器。

我有一个带有 put 方法的 .Net Core REST API,它可以添加或更新数据库中的记录。

我正在添加/更新的表有 3000 条记录并且有索引。

这在本地使用相同的数据库和容器可以正常工作。但是,当我开始通过容器加载负载(大约 50 个与 JMeter 的并发 http 连接)时,我得到随机超时,并显示以下错误消息。我在本地运行时没有遇到问题。

本地机器比容器强大得多,我增加了容器上的 CPU 功率,但这似乎没有任何区别。

任何关于尝试的建议都将不胜感激。

[10:45:36 ERR] Failed executing DbCommand (35,001ms) [Parameters=[@__get_Item_0='?' (Size = 255) (DbType = AnsiString)], CommandType='Text', CommandTimeout='30']
SELECT [e].[host_name], [e].[data_centre], [e].[Environment], [e].[is_physical_machine], [e].[mac_address], [e].[number_of_cores], [e].[number_of_sockets], [e].[number_of_v_cores], [e].[number_ofcpus], [e].[operating_system], [e].[operating_system_version], [e].[processor], [e].[uuid]
FROM [EntitlementServer].[host] AS [e]
WHERE [e].[host_name] = @__get_Item_0
System.Data.SqlClient.SqlException (0x80131904): Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.ComponentModel.Win32Exception (258): Unknown error 258
   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
   at System.Data.SqlClient.TdsParserStateObject.ReadSniSyncOverAsync()
   at System.Data.SqlClient.TdsParserStateObject.TryReadNetworkPacket()
   at System.Data.SqlClient.TdsParserStateObject.TryPrepareBuffer()
   at System.Data.SqlClient.TdsParserStateObject.TryReadByte(Byte& value)
   at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
   at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
   at System.Data.SqlClient.SqlDataReader.get_MetaData()
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, SqlDataReader ds)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean asyncWrite, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)
   at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
   at System.Data.Common.DbCommand.ExecuteReader()
   at Microsoft.EntityFrameworkCore.Storage.Internal.RelationalCommand.Execute(IRelationalConnection connection, DbCommandMethod executeMethod, IReadOnlyDictionary`2 parameterValues)
ClientConnectionId:6ca037fc-9671-4d43-bebe-35879203c682
Error Number:-2,State:0,Class:11

更新 1

虽然我发现扩展容器上的 CPU 和内存对性能没有帮助。当我增加运行容器的数量时,确实增加了吞吐量并且超时问题消失了。我不知道为什么会这样。

【问题讨论】:

  • SO 题外话 - 更适合的是 dba。您需要确定阻止数据库引擎在您在应用中使用的执行超时内响应请求的瓶颈。
  • 公平点,但我不认为这是一个数据库问题,因为它在本地工作,负载在同一个数据库上。我将安排对数据库的访问,以便我可以运行 SQL Server Profiler 以获得更好的想法。
  • 有人说如果你切换到windows容器就可以了。你能确认你使用的是 Linux 吗?
  • 确实是一个Linux容器。我不明白拥有一个 Windows 容器会有什么不同。

标签: sql-server asp.net-core entity-framework-core containers


【解决方案1】:

问题实际上是线程问题。数据库超时是一个症状。这就是为什么增加容器数量可以解决问题的原因,因为 http 线程的数量也增加了。

通过使代码异步以便释放线程,我能够解决问题而无需增加容器的数量。

【讨论】:

  • 你好,你是什么意思让代码异步?能具体一点吗?
  • 因此,确切的代码将特定于您的用例,但通常 yiu 会在您的方法调用中使用 async 和 await 关键字修饰符来实现这一点。
  • 我认为这不是正确的解决方案,也许可行,但如果负载增加更多,您将处于相同的情况
  • 会有一个点,你通过它施加足够的负载,瓶颈会移动到其他地方,所以这取决于你的具体情况。
猜你喜欢
  • 1970-01-01
  • 2022-01-14
  • 1970-01-01
  • 1970-01-01
  • 2021-07-15
  • 2018-12-01
  • 1970-01-01
  • 2019-09-27
  • 2016-08-16
相关资源
最近更新 更多