SQL Server停止處理20秒

我無法弄清楚這一點。在SQL Server上，我有一個每秒運行幾十次的進程（將數據發送到服務器）。該過程運行良好，處理請求需要50ms和200ms之間。然後，大概（但零星地）每1.5分鐘一次所有請求突然需要15000ms到22000ms（15到22秒）。與此同時，服務器上的CPU使用率急劇下降。有時（大約70％的時間）平均磁盤隊列長度會在CPU下降並且請求減慢之前激增。SQL Server停止處理20秒

我正在監視perfmon上的CPU，它通常在20％到70％之間跳躍，平均CPU爲50％左右。當事情停止時，它會下降到0％，有20％的峯值，持續約20秒。

同時我正在看SQL活動監視器。通常列出1到4個EXECUTE事務，但是當發生這種情況時，EXECUTE事務開始上升到20或30個事務。交易進入，但不是進程。

我檢查塊，再也看不到任何：

Select A.* 
     From master.dbo.sysprocesses as A with (nolock) 
     Where A.blocked <> 0

請注意，我在「快照隔離」

運行我的系統記錄死鎖錯誤日誌，沒有報道。

我檢查了SQL代理中正在運行的其他進程，沒有計劃在發生這些事件時。

我看着SQL事件探查器進來的其他事件，什麼也沒有。我還觀看了文件增長事件，它什麼也沒有報告。

即使請求需要20000ms，SQL事件探查器報告2000下的讀取和50下的cpu。進程本身看起來並不消耗資源。然而，註銷事件報告高讀取和CPU（我不知道，如果這是相關的）。

在這些事件發生時，我的事件日誌中也沒有任何內容。

任何想法？任何其他地方看？

在Window 2003 32bit上運行SQL Server 2005 Standard。

來源

2009-12-15 Mike Brad

Mike，請參閱我的博文[不明原因的SQL Server超時和間歇性阻塞]（http://blog.digitaltools.com/post/2009/02/24/Unexplained-SQL-Server-Timeouts-and-Intermittent-Blocking的.aspx）。特別是如果你的存儲過程有一個「SELECT INTO」或從臨時表中刪除。 Jim – JBrooks 2009-12-15 22:39:30

作爲一項規則，我們使用表格變量（不是臨時表格），這些表格是在任何數據插入到表格中之前定義的。我會篩選整個過程並再次檢查確定。 – 2009-12-15 22:44:51

問題是自動檢查點。當SQL服務器運行自動檢查點時，其他事務會延遲，這可能與檢查點中涉及的磁盤I/O有關。

dm_exec_requests表示的waittype WRITELOG（WAITTIME 0）指的請求已提交的事務，並正在等待的日誌被硬化（寫入磁盤） --Remus Rusanu

爲了驗證這一點，我打開檢查點日誌記錄，並在幾次事件中記錄了perfmon會話。然後，我將日誌與perfmon進行比較，以查看事件總是與我的某個數據庫中的檢查點相關。

DBCC TRACEON（3502，-1）上的檢查點記錄

DBCC TRACEOFF - 轉向（3502，-1） - 轉向關閉檢查點記錄

EXEC xp_readerrorlog --read日誌

SELECT DB_Name（[dbid]）as [Database Name] - 驗證日誌中提到的數據庫ID

該特定數據庫有一個進程會產生大量的插入和刪除操作。解決方案是重寫該過程以減少正在記錄的數據量。另一個選擇是添加硬件。

感謝所有人的貢獻。

來源

2009-12-18 19:21:18

您使用的是全文搜索？

我在想，可能會有一些索引重建不時發生。

也許嘗試自動完成索引重建或更改爲非聚簇索引？

來源

2009-12-15 22:00:17 rizzle

謝謝Rizzle。但是，我沒有使用全文搜索。 – 2009-12-15 22:22:00

我會在你的perfmon中添加更多的計數器，比如每秒可能讀取和寫入。從這裏你可以看到它是否是I/O問題。還請看看這個MSDN entry on SQL performance。它至少給了我一些好的想法來檢查我。

來源

2009-12-15 22:00:25

我想我身體不好。％磁盤平均633（不能解釋）。平均磁盤秒數/讀取。042 平均磁盤秒數/寫入.052 磁盤讀取數/秒2.041 磁盤寫入數/秒71 這是奇偶校驗RAID，但我認爲這些數字超出了預期。你會同意嗎？ – 2009-12-15 22:20:56

不知道你的RAID級別和磁盤的數量很難說如果磁盤IO是問題。我有4個磁盤的RAID 5陣列，所以我會用它來計算IOPS：讀取+（4 *寫入））/磁盤數量=總IO /秒。在典型的數字加載下，它看起來像這樣：（724.364 +（4 * 5.707））/ 4 = 186.798。我有更多的讀取比寫入，但你似乎有很多的寫道，但沒有可怕的，像克里斯說，可能是陣列的問題。在花費任何時間在代碼之前，我會檢查它。 – 2009-12-16 13:49:22

但是再次，我通常首先看硬件，因爲我比編碼更擅長於服務器端。 – 2009-12-16 13:55:21

您是否檢查了驅動器的錯誤？聽起來好像有些事情正在發生。如果它是RAID陣列，請檢查陣列的健康狀況。

來源

2009-12-15 22:05:18 NotMe

會做（我會把ISM放在上面）。謝謝。 – 2009-12-15 22:37:22

對於長時間運行的請求（週期性採樣），什麼是wait_type，wait_resource和wait_time sys.dm_exec_requests？這些請求是否產生了子任務（sys.dm_os_tasks）？這些任務在做什麼？

來源

2009-12-15 22:05:28

通常對於看起來不像系統進程的進程，waittype爲空，且等待時間爲0.在其中一個事件中，我查詢了dm_exec_requests並確實看到了一個使用OLEDB（waittime 15）的事務和一個使用waittype WRITELOG（waittime 0）的事務。我將不得不研究這意味着什麼。不確定在dm_os_tasks中查找什麼 – 2009-12-15 22:36:45

WRITELOG表示請求已提交事務並正在等待日誌被硬化（寫入磁盤）。 OLEDB是一個分佈式查詢等待。在sys.dm_os_tasks中，您應該查找task_state。 PENDING會顯示調度程序瓶頸（所有工人都被佔用） – 2009-12-15 22:59:47

感謝您的信息。在事件結束時，當CPU再次提取時寫入（儘管這是目測，而不是統計分析），dm_os_tasks報告三個PENDING任務。我會研究一下。同時，我如何判斷日誌是否被「加固」 – 2009-12-16 15:12:42

您是否檢查過內存消耗？ Windows Server 2003 R2有時基本上在劇烈負載下重新啓動所有內存分配。發生這種情況時，SQL Server被強制降低到最小內存量（4MB左右），然後慢慢地將內存重新分配給服務器，直到它恢復到相對正常的水平。當我們的SAN中複製非常大的文件時，我們已經看到了這種情況。我聽說如果事務日誌非常大並且服務器的使用率非常高，這可能由事務日誌備份過程觸發。

來源

2009-12-15 22:26:36

查看任務管理器（不確定這是最好的方法）我看到Sqlservr.exe進程報告大約2,544,000個內存使用情況。它有一點波動，但從不大幅度下降（即使是在事件中）。 – 2009-12-15 22:41:14

這不是慢代碼，因爲延遲不會增加CPU時間。這聽起來像是服務器正在進行阻塞呼叫，但沒有成功，然後它最終超時。你排除了僵局。如果這是一個硬盤驅動器問題，您希望在事件日誌中看到一些東西。

嘗試安裝網絡嗅探器（如Wireshark）以查看暫停開始時是否有任何有趣的事情發生。

來源

2009-12-15 23:35:36 jdigital

一個選項：統計更新。如果你經常寫作，你可能會達到重新計算的門檻。

看看這篇文章"Index Statistics on MSDN"和選項「AUTO_UPDATE_STATISTICS_ASYNC」

雖然每90秒是有點多......

來源

2009-12-16 05:54:34 gbn

SQL Server停止處理20秒

回答

相關問題