【问题标题】:SQL Server Express (localdb) The wait operation timed out - query timing out at random?SQL Server Express (localdb) 等待操作超时 - 查询随机超时?
【发布时间】:2021-02-10 16:49:08
【问题描述】:

我有普通的SELECT 查询,它返回相对较大的数据集(11k 行),并且在我的应用程序运行时随机超时。这发生在我自己的使用 localdb 的开发笔记本电脑上。当它工作时,它几乎立即返回数据,其他时候 - Microsoft.Data.SqlClient.SqlException: The wait operation timed out.。当它使用 SSMS 失败时也会感觉迟钝,但它总是会完成查询。

SQL如下

(@CurrentUserId int)
-- First, select Draft issues created by current user
SELECT [I].[IssueId]
      ,[I].[IssueGuid]
      ,[I].[IssueNumber]
      ,[I].[DateCreated]
      ,[I].[DateOpened]
      ,[I].[DateLastModified]
      ,[I].[DateClosed]
      ,[I].[Title]
      ,[I].[Type]
      ,[I].[Status]
      ,[I].[CreatedByUserId]
      ,1 AS [OrderKey]
FROM [cm].[IssuesTbl] [I]
WHERE [I].[Status] = 0 AND [I].[CreatedByUserId] = @CurrentUserId

UNION ALL

-- Last, select Open issues
SELECT [I].[IssueId]
      ,[I].[IssueGuid]
      ,[I].[IssueNumber]
      ,[I].[DateCreated]
      ,[I].[DateOpened]
      ,[I].[DateLastModified]
      ,[I].[DateClosed]
      ,[I].[Title]
      ,[I].[Type]
      ,[I].[Status]
      ,[I].[CreatedByUserId]
      ,2 AS [OrderKey]
FROM [cm].[IssuesTbl] [I]
WHERE [I].[Status] = 1

ORDER BY [OrderKey] ASC, [I].[DateOpened] DESC, [I].[DateCreated] DESC

执行计划是here.

我安装了 Blitz 并运行 sp_BlitzFirst 给我一些想法,但我不确定要查找什么以及如何解决问题。请帮忙。

@@version:

Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64)   Oct 28 2016 18:17:30   Copyright (c) Microsoft Corporation  Express Edition (64-bit) on Windows 10 Enterprise 6.3 <X64> (Build 17134: )

sp_BlitzFirst:

10  Server Performance  Poison Wait Detected: RESOURCE_SEMAPHORE
For 4 seconds over the last 5 seconds, SQL Server was waiting on this particular bottleneck.

200 Wait Stats  RESOURCE_SEMAPHORE
For 4 seconds over the last 5 seconds, SQL Server was waiting on this particular bottleneck.

【问题讨论】:

标签: sql sql-server timeout query-performance


【解决方案1】:

你可以尝试一些事情

  • 查询计划对表进行了两次完整的聚集索引扫描。鉴于您可能需要至少阅读一次(以获取 Open 问题),您不妨使用单个 SELECT 而不是 UNION。
    • 如果您可以使用索引进行查找并避免全表/聚集索引扫描,那么 UNION 方法会非常有效。如果你没有它可以使用的索引,那么你也可以限制你需要读取数据的次数。
  • order-by 吃掉内存(ordering 会占用大量 CPU 和内存)。是否可以通过 ID 而非 DateOpened 进行排序?
  • 根据可用的状态以及每个状态的行数,您可以在 [cm].[IssuesTbl].[Status] 上放置一个非聚集索引

这是我建议的代码。我将 order by 更改为以 Status 开头,因为它已经按顺序排列,但我没有将第二个字段更改为 ID - 但如果可以的话,请这样做。

SELECT [I].[IssueId]
      ,[I].[IssueGuid]
      ,[I].[IssueNumber]
      ,[I].[DateCreated]
      ,[I].[DateOpened]
      ,[I].[DateLastModified]
      ,[I].[DateClosed]
      ,[I].[Title]
      ,[I].[Type]
      ,[I].[Status]
      ,[I].[CreatedByUserId]
      ,CASE WHEN [I].[Status]=1 THEN 2 ELSE 1 END AS [OrderKey]
FROM [cm].[IssuesTbl] [I]
WHERE ([I].[Status] = 1)
      OR ([I].[Status] = 0 AND [I].[CreatedByUserId] = @CurrentUserId)
ORDER BY [I].[Status] ASC, [I].[DateOpened] DESC, [I].[DateCreated] DESC

【讨论】:

  • 完美!我想我什至可以删除[OrderKey] 并在客户端进行整个排序。非常感谢您的帮助。
  • 客户端完整性排序(C#):issues = issues.OrderBy(i =&gt; i.Status).ThenByDescending(i =&gt; i.DateCreated).ThenByDescending(i =&gt; i.DateOpened);
【解决方案2】:

您似乎有内存问题。您应该检查您的状态:

SELECT 
  ((t1.requested_memory_kb)/1024.00) MemoryRequestedMB
  , CASE WHEN t1.grant_time IS NULL THEN 'Waiting' ELSE 'Granted' END AS RequestStatus
  , t1.timeout_sec SecondsToTerminate
FROM sys.dm_exec_query_memory_grants t1
  CROSS APPLY sys.dm_exec_sql_text(t1.sql_handle) t2

您不想等待。同样,您应该运行

SELECT total_physical_memory_kb, available_physical_memory_kb, 
       total_page_file_kb, available_page_file_kb, 
       system_memory_state_desc
FROM sys.dm_os_sys_memory WITH (NOLOCK) OPTION (RECOMPILE);

你想要的是Available physical memory is high。如果你不这样做,这意味着你的记忆有问题。那么问题是您是否有相互竞争的流程。

【讨论】:

  • 第一个查询没有返回任何记录;第二个:total_physical_memory_kb available_physical_memory_kb total_page_file_kb available_page_file_kb system_memory_state_desc 8232016 1270616 17795476 2419552 Available physical memory is high
  • 当然,8GB 并不多,尤其是在运行 Visual Studio、SSMS、Firefox 和其他一些工具时。问题是 - 我应该以任何方式优化我的查询还是在生产服务器上会很好?
  • 不是很多。你能分配更多吗?
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2015-02-02
  • 1970-01-01
  • 2019-03-13
  • 2017-01-03
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多