SQL Server 在 EC2 上的備份期間掛起
有時，我們的 SQL Server 將在其每週完整備份期間“掛起”。發生這種情況時，外部連接開始超時。症狀是：
- 連接超時
- sqlservr.exe 程序位於通常的記憶體級別（47gb，12gb 留給作業系統），但 CPU 約為 0-5%（正常 = ~30%），偶爾會出現 ~25% 的峰值持續幾秒鐘，然後又下降0-5%。
- 我可以使用 SSMS 連接到數據庫，但沒有查詢響應，無法獲取數據庫列表，無法訪問 DMV - 雖然沒有超時，但我在任何時候都沒有得到任何結果。與 DAC 連接相同。
- 伺服器上沒有執行其他任何東西，它是一個專用的 SQL 框。
該伺服器是具有 SQL 2012 標準版的 i2.2xlarge EC2 伺服器，在 Windows Server 2012 R2 上執行。
我們的備份計劃包括每日差異和每週完整，並且這個問題在完整備份期間總是發生。通過簡單地瀏覽磁碟上的備份文件，我可以看到它完成了幾個較小的數據庫（<200MB），然後從未完成過一個更大的數據庫（~100GB，典型的壓縮大小 = 10GB）。
在這種情況下，我可以遠端進入機器就好了，網路很好，所有磁碟似乎都在正常執行。
發生的事情的時間表如下所示：
- 0300AM：DBCC CHECKDB 在所有數據庫上執行，一切正常。
- 0345AM：在 ~100GB 數據庫上啟動 BACKUP。
- 0347AM：SQL Server 遇到 1 次 I/O 請求，在文件上完成的時間超過 15 秒$$ XXX $$在數據庫 id 7 中。作業系統文件句柄是 0x00000000000010D4。最近的long I/O的偏移量為：0x000002dbbd0000
- 重複~20次
- 0351AM：等待緩衝區閂鎖時發生超時——類型 2，bp 0000000BE55A9CC0，頁面 1:1864895，stat 0x40d，數據庫 id：102，分配單元 id：7493989815628529664，任務 0x0000000B91125088：0，等待時間，300 秒，擁有標誌 a，任務 0x0000000B91125088。繼續等待。
- 重複約 5 小時和 50 萬次
超時不僅來自正在備份的數據庫，還來自所有數據庫。通常此備份過程會在 1-2 小時內完成。
大約 5 個小時後，我們放棄了它，因為所有外部連接都失敗了。試圖從服務控制面板停止 SQL Server 只是掛起，試圖停止。嘗試終止程序會導致“拒絕訪問”消息 - 我們通常具有終止程序的完全訪問權限，並且之後已經過測試 - 拒絕訪問消息僅在這些事件期間出現。一段時間後，我們必須重新啟動機器，因為我們無法擺脫卡住的 sqlservr.exe 程序。機器啟動後，一切執行正常，所有 CHECKDB 都恢復正常。我們將啟動一個新的完整備份，並按預期完成。
查看 Windows 事件日誌，在上午 0347 左右，我們看到“xenvbd”日誌條目，但沒有描述。我們還看到“磁碟”日誌條目 - 磁碟 2（PDO 名稱：\Device\00000033）的邏輯塊地址 0x14a4e070 處的 IO 操作被重試。這些事件持續時間 - ~5 小時。
磁碟 2 是我們的數據驅動器。磁碟 3 是我們的備份驅動器，但我們在日誌中沒有看到它的提及。兩個驅動器都是 SSD EBS 驅動器。
到目前為止，我的理論是 EBS 驅動器堵塞導致 IO 嚴重聚集。但是，即便如此，我還是不明白為什麼這會導致 SQL Server 以某種方式卡在自身上，而不響應任何內容。當我遠端進入伺服器時，在這種情況下，我可以訪問磁碟就好了。大量的 IO 請求會導致這種情況嗎？我是否缺少一些關鍵的 EC2 調整設置？除了離開 EC2 之外，還有什麼關於做什麼的提示嗎？我很確定根本原因是 EBS，但是看到這在 99.99% 的時間裡都完美無缺，我真的很想找到一種方法來避免這個問題。
我們在進行備份時遇到了類似的問題。看起來好像磁碟讀取正在最大化 EBS 連接。
我認為問題在於實例類型的吞吐量限制。在此處檢查最大頻寬列：
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html
唯一的解決方案似乎是切換到具有更高吞吐量的不同實例類型。你有沒有找到其他解決方案？
我們在所有執行 r3.xlarge、1000gb 捲和 ebs 優化的 sql server 實例中都看到了同樣的問題。
基本上支持（或恢復）一個大型數據庫會影響所有其他數據庫。我們為所有數據庫執行鏡像，任何備份或恢復操作都會導致大多數鏡像從執行備份的伺服器故障轉移。
似乎 sql server 或磁碟子系統沒有公平/正確地分配執行緒/磁碟訪問，因此盒子上的所有 io 都被一個備份過程飽和了。我從未見過這種執行物理硬體的行為，即使磁碟隊列非常大。也許與我們類似的 ebs 的驅動程序有關。我實際上在同時跨磁碟執行多個大文件複製時看到了類似的行為，整個效率似乎變得更糟。