Question

我已经在互联网上以多种方式看到了这个问题但是尽管实施了大量的建议（以及一些伏都教），我仍然在苦苦挣扎。我有一个100GB +的数据库，它不断地在非常大的事务中插入和更新记录（每个trans超过200个语句）。系统重启后，性能惊人（数据写入通过USB 3.0连接的大型SATA III SSD）。 SQL Server实例正在VMWare Workstation下运行的VM上运行。主机设置为将整个VM保存在内存中。 VM本身具有5000 MB的分页缓存。 SQL Server用户设置为“将页面保留在内存中”。我有5 GB的RAM分配给VM，SQL Server实例的最大内存设置为半个千兆。

我已经使用这些参数中的每一个来尝试保持一致的性能，但是确定且稳定，性能最终会降低到开始超时的程度。不过，如果我停止正在加载数据库的应用程序，然后在Management Studio中执行存储过程，它会像闪电一样运行，清楚地表明它不是查询的问题，可能与内存管理或分页。如果我然后重新启动加载程序应用程序，它仍然会爬行。但是，如果我重新启动虚拟机，那么应用程序将再次像闪电那样运行......暂时......

是否有人根据出现的症状提出任何其他建议？

Answer 1

根据热套的大小，5GB内存可能只对100 + gb数据库征税。
检查索引和查询计划。没有它们我们无法帮助你。我打赌你会错过一些指数 - 这是人们的标准性能问题。
否则，一旦你完成了作业 - 请前往dba.stackexchange.com并在那里问问。
通常 - 考虑每个事务200个语句可能只是表明严重次优的编程。例如，您可以将数据批量加载到临时表中，然后合并到最终的表中。

Answer 2

实际上，我可能有一个工作理论。我做的是为应用程序添加一些逻辑，当它超时时，坐两分钟，然后再试一次，瞧！回到全速。我和我的同事一起搞笑，并想出了我认为的SSD写入速度实际上是VMWare主机的虚拟USB 3缓冲区的写入速度，以及实际的SSD写入速度是慢点。我可能会遇到主机的缓冲区大小，并且强迫应用程序等待2分钟，主机有机会将其缓冲后的数据转储到SSD。小学，沃森：）

如果这种方法也不可持续，我会报告。

Answer 3

尝试执行此操作以确定您的问题查询：

SELECT TOP 20
  qs.sql_handle,
  qs.execution_count,
  qs.total_worker_time AS Total_CPU,
  total_CPU_inSeconds = --Converted from microseconds
      qs.total_worker_time/1000000,
  average_CPU_inSeconds = --Converted from microseconds
      (qs.total_worker_time/1000000) / qs.execution_count,
  qs.total_elapsed_time,
  total_elapsed_time_inSeconds = --Converted from microseconds
      qs.total_elapsed_time/1000000,
 st.text,
 qp.query_plan
FROM
 sys.dm_exec_query_stats as qs
 CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) as st
 cross apply sys.dm_exec_query_plan (qs.plan_handle) as qp
 ORDER BY qs.total_worker_time desc

然后检查您的估计和实际执行计划，查看此命令可帮助您查明。

来源How do I find out what is hammering my SQL Server?位于http://technet.microsoft.com/en-us/magazine/2007.11.sqlquery.aspx

页面底部

Answer 4

除了已经给出的优秀索引建议，一定要阅读参数嗅探。这可能是问题的原因。

SQL Server - parameter sniffing

http://www.sommarskog.se/query-plan-mysteries.html#compileps

因此，您可能会重新使用错误的查询计划，或者SQL的缓冲区可能已满并将页面内存写入磁盘（在您的情况下可能是其他已分配的内存））。

你可以运行DBCC FreeProcCache和DBCC FreeSystemCache来清空它，看看你是否获得了性能提升。

你应该给SQL更多的内存 - 尽可能多地为其他关键程序和操作系统留出空间。你可能在VM上有5GB的Ram，但是SQL只能用1/2 gb，这对于你所描述的内容来说似乎很小。

如果这些事情没有让您朝着正确的方向前进，请安装SQL管理数据仓库，这样您就可以准确了解减速开始时的情况。运行它需要额外的内存，但你会给DBA更多的事情。

Answer 5

最后，我所做的是两件事的结合，在发生超时时设置逻辑以恢复，并将主机核心数设置为仅反映物理内核，而不是逻辑内核，例如，主机有2超线程的核心。当我将我的VM设置为使用4个内核时，它偶尔会挂起一些无限循环，但是当我将它设置为2个内核时，它会毫无问题地运行。但是，像这样的异常行为很难可靠地缓解。

SQL Server查询性能随着时间的推移而变慢

5 个答案: