改善全文檢索索引的效能

全文檢索索引與全文檢索查詢的效能會受硬體資源的影響，例如記憶體、磁碟速度、CPU 速度與電腦架構。

本主題內容

• 常見的效能問題原因

• 微調全文檢索索引的效能

• 疑難排解：完整母體擴展的效能問題

• 疑難排解：索引效能因篩選而變慢

常見的效能問題原因

全文檢索索引效能降低的主要原因即為硬體資源的限制：

• 如果篩選背景程式主機處理序 (fdhost.exe) 或 SQL Server 處理序 (sqlservr.exe) 所使用的 CPU 使用率接近 100%，表示 CPU 就是瓶頸。

• 如果平均磁碟等候佇列長度超過磁碟讀寫頭數目的兩倍，表示磁碟有瓶頸。 主要的解決方式是建立和 SQL Server 資料庫檔案和記錄分開的全文檢索目錄。 請將記錄、資料庫檔案和全文檢索目錄放在不同的磁碟上。 購買較快速的磁碟以及使用 RAID 也有助於改善索引效能。

• 如果實體記憶體 (3 GB 的限制) 不足，表示記憶體可能是瓶頸。 實體記憶體限制可能會在所有系統上發生，而且在 32 位元系統上，虛擬記憶體不足的壓力可能會降低全文檢索索引的速度。

  [!附註]

  從 SQL Server 2008 開始，全文檢索引擎就可以使用 AWE 記憶體，因為全文檢索引擎屬於 sqlservr.exe 的一部分。

如果系統沒有任何硬體瓶頸，全文檢索搜尋的索引效能大多取決於下列條件：

• SQL Server 建立全文檢索批次所花的時間。

• 篩選背景程式可以取用這些批次的速度。

[!附註]

與完整母體擴展不同，累加、手動和自動變更追蹤母體擴展並非設計來最大化硬體資源以達到更快的速度。 因此，這些微調建議可能無法增強全文檢索索引的效能。

完成母體擴展後會觸發最後的合併程序，將索引片段合併成一個主要的全文檢索索引。 如此可提升查詢的效能，因為只需要查詢一個主索引而不需查詢數個索引片段，而且可使用較佳的計分系統來排定關聯順序。 請注意，主要合併過程可能需要密集的磁碟 I/O，因為合併索引片段時必須讀寫大量的資料，但是不會阻止傳入的查詢。

重要事項
主要合併大量資料可能會建立長時間執行的交易，並在檢查點期間延遲截斷交易記錄。 在此情況下，交易記錄可能會在完整復原模式下明顯成長。 最佳作法是確認您的異動記錄包含足夠的空間，可供長時間執行的異動使用，然後在使用完整復原模式的資料庫中，辨識大型全文檢索索引。 如需詳細資訊，請參閱＜管理交易記錄檔的大小＞。

[回到頁首]

微調全文檢索索引的效能

若要將全文檢索索引的效能發揮至極限，請實作下列最佳作法：

• 若要使用所有處理器或核心來發揮最大效能，請將 sp_configure‘max full-text crawl ranges’ 設定為系統上的 CPU 數目。 如需有關這個組態選項的詳細資訊，請參閱＜全文檢索搜耙最大範圍伺服器組態選項＞。

• 請確定基底資料表具有叢集索引。 對叢集索引的第一個資料行使用整數資料類型。 避免在叢集索引的第一個資料行使用 GUID。 叢集索引的多重範圍母體擴展可能會產生最高的母體擴展速度。 我們建議當做全文檢索索引鍵的資料行應該是整數資料類型。

• 請使用 UPDATE STATISTICS 陳述式來更新基底資料表的統計資料。 更重要的是，請更新叢集索引上的統計資料或完整母體擴展的全文檢索索引鍵。 這有助於多重範圍母體擴展在資料表上產生良好的資料分割。

• 如果您想要改善累加母體擴展的效能，請在 timestamp 資料行上建立次要索引。

• 在大型的多重 CPU 電腦上執行完整母體擴展之前，我們建議您設定 max server memory 值來暫時限制緩衝集區的大小，以便保留足夠的記憶體供 fdhost.exe 處理序和作業系統使用。 如需詳細資訊，請參閱本主題稍後的＜估計篩選背景程式主機處理序 (fdhost.exe) 的記憶體需求＞一節。

[回到頁首]

疑難排解：完整母體擴展的效能問題

若要診斷效能問題，請查看全文檢索搜耙記錄檔。 如需有關搜耙記錄檔的詳細資訊，請參閱＜擴展全文檢索索引＞。

如果您對於完整母體擴展的效能不滿意，建議您遵循下列疑難排解順序進行。

實體記憶體使用量

在全文檢索母體擴展期間，fdhost.exe 或 sqlservr.exe 可能會造成記憶體不足或用完記憶體。 如果全文檢索搜耙記錄檔顯示 fdhost.exe 經常重新啟動或者傳回錯誤碼 8007008，就表示其中一個處理序用完記憶體。 如果 fdhost.exe 正在產生傾印 (尤其是在大型的多重 CPU 電腦上)，它可能會用完記憶體。

[!附註]

若要取得有關全文檢索搜耙所使用之記憶體緩衝區的詳細資訊，請參閱＜sys.dm_fts_memory_buffers (Transact-SQL)＞。

可能的原因如下：

• 如果完整母體擴展期間可用的實體記憶體數量為零，表示 SQL Server 緩衝集區可能耗用了系統上的大部分實體記憶體。 

  sqlservr.exe 處理序嘗試擷取緩衝集區的所有可用記憶體，最多至已設定的最大伺服器記憶體。 如果 max server memory 配置太大，fdhost.exe 處理序可能會發生記憶體不足以及無法配置共用記憶體的狀況。

  [!附註]

  在多重 CPU 電腦上進行全文檢索母體擴展期間，fdhost.exe 或 sqlservr.exe 之間可能會發生競爭緩衝集區記憶體的情況。 所產生的共用記憶體不足會導致批次重試、記憶體壓力以及 fdhost.exe 處理序的傾印。

  您可以透過適當地設定 SQL Server 緩衝集區的 max server memory 值，解決此問題。 如需詳細資訊，請參閱本主題稍後的＜估計篩選背景程式主機處理序 (fdhost.exe) 的記憶體需求＞一節。減少全文檢索索引的批次大小可能也會有所助益。

• 分頁問題

  分頁檔大小不足 (例如，在具有成長受限之小型分頁檔的系統上) 可能也會導致 fdhost.exe 或 sqlservr.exe 用完記憶體。

  如果搜耙記錄檔並未指出任何記憶體相關的失敗，可能是由於過度分頁而導致效能降低。

[回到頁首]

估計篩選背景程式主機處理序 (fdhost.exe) 的記憶體需求

fdhost.exe 處理序進行母體擴展所需的記憶體數量主要取決於它所使用的全文檢索搜耙範圍數目、內部共用記憶體 (ISM) 的大小，以及 ISM 執行個體的數目上限。

您可以使用下列公式來概略估計篩選背景程式主機所耗用的記憶體數量 (以位元組為單位)：

number_of_crawl_ranges * ism_size * max_outstanding_isms * 2

上述公式中變數的預設值如下所示：

下表將列出有關如何估計 fdhost.exe 記憶體需求的指導方針。 此表中的公式會使用下列值：

• F，這是 fdhost.exe 所需記憶體的估計 (以 MB 為單位)。

• T，此為系統上可用的實體記憶體總計 (以 MB 為單位)。

• M，此為最佳 max server memory 設定。

重要事項
如需有關這些公式的基本資訊，請參閱以下的 1、2 與 3。

1如果有多個完整母體擴展正在進行中，請分別計算每個項目的 fdhost.exe 記憶體需求，例如 F1、F2，以此類推。 然後，再計算 M as T – sigma**(Fi)**。

2 500 MB 是系統中其他處理序所需記憶體的估計。 如果系統正在進行其他工作，請據此增加這個值。

3 x64 平台的 ism_size 假設為 8 MB。

範例：估計 fdhost.exe 的記憶體需求

這個範例適用於具有 8GM RAM 和 4 個雙核心處理器的 AMD64 電腦。 第一個計算會估計 fdhost.exe 所需的記憶體—F。 搜耙範圍的數目是 8。

F = 8*10*8=640

下一個計算會取得 max server memory 的最佳值 - M。 T此系統上可用的實體記憶體總計 (以 MB 為單位)，T 是 8192。

M = 8192-640-500=7052

範例：設定 max server memory

此範例使用 sp_configure 及 RECONFIGURE Transact-SQL 陳述式，將 max server memory 設定為上述範例中針對 M 所計算的值，例如 7052：

USE master;
GO
EXEC sp_configure 'max server memory', 7052;
GO
RECONFIGURE;
GO

設定最大伺服器記憶體組態選項

• 伺服器記憶體伺服器組態選項

[回到頁首]

可能會降低 CPU 耗用率的因素

當平均 CPU 耗用率大約低 30% 時，我們會預期完整母體擴展的效能並非最佳化。 本節將討論影響 CPU 耗用率的某些因素。

• 等候分頁的時間很高

  若要了解分頁等候時間是否很高，請執行下列 Transact-SQL 陳述式：

  Execute SELECT TOP 10 * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC;
  

  下表將說明在此重要的等候類型。

  等候類型	說明	可能的解決方案
  PAGEIO_LATCH_SH (_EX 或 _UP)	這可能表示 IO 瓶頸，而在此情況下，您通常也會看見很高的平均磁碟佇列長度。	將全文檢索索引移至不同磁碟上的不同檔案群組可能有助於減少 IO 瓶頸。
  PAGELATCH_EX (或 _UP)	這可能表示嘗試寫入相同資料庫檔案的執行緒之間存在大量競爭的情況。	將檔案加入至全文檢索索引所在的檔案群組可能有助於減少這類競爭的情況。

  如需詳細資訊，請參閱＜sys.dm_os_wait_stats (Transact-SQL)＞。

• 掃描基底資料表的效率不足

  完整母體擴展會掃描基底資料表來產生批次。 在下列狀況中，這種資料表掃描作業可能會沒有效率：

  • 如果基底資料表中正在進行全文檢索索引之資料列外資料行的百分比很高，掃描基底資料表來產生批次的作業可能就是瓶頸。 在此情況下，使用 varchar(max) 或 nvarchar(max) 來移動較少的同資料列資料可能會有用。

  • 如果基底資料表嚴重片段化，掃描可能就沒有效率。 如需有關計算資料列外資料和索引片段的詳細資訊，請參閱＜sys.dm_db_partition_stats (Transact-SQL)＞和＜sys.dm_db_index_physical_stats (Transact-SQL)＞。

    若要減少片段，您可以重新組織或重建叢集索引。 如需詳細資訊，請參閱＜重新組織與重建索引＞。

[回到頁首]

疑難排解：索引效能因篩選而變慢

擴展全文檢索索引時，全文檢索引擎會使用兩種篩選：多執行緒與單一執行緒。 某些文件 (例如 Microsoft Word 文件) 是使用多執行緒篩選進行篩選。 其他文件 (例如 Adobe Acrobat Portable Document Format (PDF) 文件) 則是使用單一執行緒篩選進行篩選。

基於安全性理由，篩選是由篩選背景程式主機處理序載入。 伺服器執行個體會針對所有多執行緒篩選使用多執行緒處理序，而針對所有單一執行緒篩選使用單一執行緒處理序。當使用多執行緒篩選的文件包含使用單一執行緒篩選的內嵌文件時，全文檢索引擎就會針對內嵌文件啟動單一執行緒處理序。 例如，如果遇到包含 PDF 文件的 Word 文件，全文檢索引擎就會針對 Word 內容啟動多執行緒處理序，而針對 PDF 內容啟動單一執行緒處理序。 不過，單一執行緒篩選在此環境下可能無法正常運作，而且可能會使篩選處理序不穩定。 在經常會有這類內嵌的特定情況下，不穩定可能會導致篩選處理序損毀。 發生這個狀況時，全文檢索引擎就會將任何失敗的文件 (例如，包含內嵌 PDF 內容的 Word 文件) 重新路由傳送至單一執行緒篩選處理序。 如果經常發生重新路由傳送的狀況，則會導致全文檢索索引處理序的效能降低。

若要解決這個問題，請將容器文件 (在此範例中是 Word) 的篩選標示成單一執行緒篩選。 您可以變更篩選登錄值，以便將給定的篩選標示成單一執行緒篩選。 若要將篩選標示成單一執行緒篩選，您必須將此篩選的 ThreadingModel 登錄值設定為 Apartment Threaded。 如需有關單一執行緒 Apartment 的詳細資訊，請參閱了解及使用 COM 執行緒模型技術白皮書。

[回到頁首]

請參閱

工作

疑難排解全文檢索索引

參考

sys.dm_fts_memory_buffers (Transact-SQL)

sys.dm_fts_memory_pools (Transact-SQL)

概念

伺服器記憶體伺服器組態選項

全文檢索搜耙最大範圍伺服器組態選項

擴展全文檢索索引

建立及管理全文檢索索引