共用方式為

改善全文檢索索引的效能

  • 發行項

全文檢索索引和全文檢索查詢的效能會受到硬體資源的影響，例如記憶體、磁碟速度、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 處理序的傾印。

    您可以適當地設定 max server memory SQL Server 緩衝池的值來解決此問題。 如需詳細資訊，請參閱本主題稍後的<估計篩選背景程式主機進程（fdhost.exe）的記憶體需求。 減少全文檢索索引所使用的批次大小可能也會有所幫助。

  • 分頁問題

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

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

估計篩選背景程式主機進程的記憶體需求 （fdhost.exe）

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

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

number_of_crawl_ranges 'ism_size'max_outstanding_isms* 2

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

變數 預設值
number_of_crawl_ranges CPU 數目
ism_size 1 MB (適用於 x86 電腦)

4 MB、8 MB 或 16MB (適用於 x64 電腦，端視實體記憶體總數而定)
max_outstanding_isms 25 (適用於 x86 電腦)

5 (適用於 x64 電腦)

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

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

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

  • M，這是最佳 max server memory 設定。

重要

如需公式的基本資訊，請參閱 下方的 1、 2 和 3。

平台 估計 MB-F 1 中的fdhost.exe記憶體需求 計算最大伺服器記憶體-M2 的公式
x86 F = 編目範圍*數目 50 M =minimum（ T ， 2000**）-F** 500
x64 F = 編目範圍 * 10 * 8 M = T - F - 500

1 如果有多個完整母體擴展正在進行中，請分別計算每個母體fdhost.exe記憶體需求，例如 F1、 F2 等等。 然後將 M 計算為 T- sigma**(_F_i)**。

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

3 . ism_size假設 x64 平臺為 8 MB。

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

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

F = 8*10*8=640

下一個計算會取得 M 的最佳值max server memory-。 The total physical memory available on this system in MB-T-is 8192.

M = 8192-640-500=7052

範例：設定最大伺服器記憶體

此範例會使用 sp_configure 和 RECONFIGURETransact-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 的詳細資訊，請參閱 Understanding and Using COM Threading Models(了解與使用 COM 執行緒模型) 技術白皮書。

另請參閱

伺服器記憶體伺服器組態選項
全文檢索搜耙最大範圍伺服器組態選項
擴展全文檢索索引
建立及管理全文檢索索引
sys.dm_fts_memory_buffers (Transact-SQL)
sys.dm_fts_memory_pools (Transact-SQL)
疑難排解全文檢索索引