SQL Server 2005 中的高 MSSEARCH 等待類型
本週我遇到了 MSSEARCH 等待類型的問題，我無法完全診斷問題。
伺服器已經執行了幾個星期沒有問題，直到有一天，它突然開始花費太長時間來回復使用者的請求。
我和我的團隊很快發現問題出在全文搜尋組件上，但我們不知道是什麼原因造成的。（FTS 是我們工作負載中大量使用的功能，到目前為止我們還沒有遇到任何問題。）
我們嘗試重新啟動 MSFTE 服務，但它沒有響應。
如上面的螢幕截圖所示，伺服器的等待任務數略低於 400（正常工作負載低於 10）並且還在上升。
在重新啟動伺服器之前，我沒有太多時間嘗試診斷它，因為我們正在生產中執行，所以在伺服器完全重新啟動後，我只剩下 SQL Server 的日誌和幾個 MSFTE 記憶體轉儲。
我希望能夠更好地理解這些問題，但我無法從中獲得很多資訊，所以如果有人能提供指點或對此有所了解，我將非常高興。
我們所能推斷的是全文搜尋服務已經停止工作，但我在網路上沒有發現這樣的錯誤的證據，雖然現在似乎執行正常，但我想真正了解發生了什麼並防止它再次發生。
謝謝你。
我們無法完全診斷問題，但我們確實採取了措施避免這種情況再次發生，我想在這裡記錄一下。
首先，我們在系統活動低的時期、數據庫維護視窗期間設置了全文索引和全文目錄填充，我們不再讓系統自動處理它。
其次，我們現在密切關注全文搜尋服務、它們的表現以及 FTS 佔用了多少資源。我們已經記錄了它的使用情況，並且我們監控它的文件大小和 I/O 等。
第三，我設置了幾個警報，以便操作員 (DBA) 在出現問題時得到通知（這裡的錯誤是相對的。在我們的例子中，當 FTS 開始使用比預期更多的資源時，加上一個合理的門檻值.)
到目前為止，它還沒有再次發生（距離第一次發生已經快一個月了），但如果它確實發生了，我們已經準備好採取行動，最好是在我們的使用者受到影響之前。
首先，這是 SSMS 2008 的截圖；）
FTE 對資源的要求與普通數據庫儲存有很大不同；您應該設置至少以下計數器的遠端 Windows perfcounter 擷取：
- CPU 使用率
- 每個單獨磁碟的物理磁碟 I/O（每秒讀取/寫入）
- 伺服器工作隊列
- 每個磁碟的平均磁碟隊列長度
還有一些相關的 MSSQL 計數器，儘管您需要一個正在執行的 MSSQL 實例才能遠端設置這些計數器的擷取。如果沒有，則需要在 SQL 伺服器上創建集合併導出/導入計數器。
每分鐘左右擷取這些數據，任何趨勢都將很容易發現。