SQL Server查詢性能隨着時間的推移而降低

Question

我已經在整個Internet上以許多方式看到了這個問題，但是盡管實施了很多建議（和一些伏都教），但我仍在努力。 我有一個100GB以上的數據庫，該數據庫不斷地在非常大的事務中插入和更新記錄（每個事務200個以上的語句）。 系統重新啟動后，性能會非常出色（數據已寫入通過USB 3.0連接的大型SATA III SSD）。 SQL Server實例在VMWare Workstation下運行的VM上運行。 主機設置為將整個VM保留在內存中。 VM本身具有5000 MB的分頁緩存。 SQL Server用戶設置為“將頁面保留在內存中”。 我有5 GB的RAM分配給VM，並且SQL Server實例的最大內存設置為一半Gig。

我已經嘗試使用這些參數中的每個參數來嘗試保持一致的性能，但可以肯定並穩定地將性能降低到開始超時的程度。 不過，這是一個問題，如果我停止正在加載數據庫的應用程序，然后在Management Studio中執行存儲的proc，它的運行就像閃電一樣，清楚地表明這與查詢無關，可能與內存管理或分頁。 如果然后重新啟動加載器應用程序，它仍然會爬網。 但是，如果我重新啟動VM，該應用程序將再次像閃電般運行...一段時間...

根據出現的症狀，有人有其他建議嗎？

Answer 1

• 根據您的熱設置的大小，對於100 + GB數據庫，5GB內存可能只會增加它的負擔。

• 檢查索引和查詢計划。 沒有他們，我們將無濟於事。 我敢打賭，您會錯過一些指數-這是人們的標准績效問題。

• 否則，一旦完成作業，請轉到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

然后在此命令可幫助您查明的查詢上檢查估計的和實際的執行計划。

來源如何找出影響SQL Server的原因？ 並在http://technet.microsoft.com/zh-cn/magazine/2007.11.sqlquery.aspx頁面底部

Answer 4

除了已經給出的出色索引建議之外，請務必閱讀有關參數嗅探的內容。 這可能是問題的原因。

SQL Server-參數嗅探

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

結果，您可能會重復使用錯誤的查詢計划，或者SQL的緩沖區可能已滿，並且將內存中的頁面寫到磁盤上（可能是您所分配的其他內存）。

您可以運行DBCC FreeProcCache和DBCC FreeSystemCache將其清空，看看是否可以提高性能。

您還應該為SQL提供更多的內存-在為其他關鍵程序和操作系統留出空間的同時，還應盡可能多地給SQL提供內存。 您在VM上可能有5gb的Ram，但是SQL只能以1/2 gb的速度運行，這對於您所描述的內容似乎很小。

如果這些事情沒有朝着正確的方向發展，請安裝SQL Management Data Warehouse，以便您可以准確地看到減速開始時發生的情況。 運行它會占用額外的內存，但是您會給DBA留下更多的空間。

Answer 5

最后，我要做的是將兩件事結合在一起：放入邏輯以在發生超時時進行恢復，並將主機核心數設置為僅反映物理核心，而不是邏輯核心，例如，主機有兩個核心超線程的。 當我將VM設置為使用4個內核時，它有時會陷入無限循環，但是當我將其設置為2個內核時，它會毫無故障地運行。 盡管如此，這樣的異常行為仍然難以可靠地緩解。