フルテキスト インデックスのパフォーマンスのチューニングと最適化

フルテキスト作成時は、fdhost.exe または sqlservr.exe がメモリ不足またはメモリ枯渇の状態で実行される可能性があります。フルテキスト クロールのログを確認した結果、fdhost.exe が頻繁に再起動されているか、エラー コード 8007008 が返されていることが判明した場合は、これらのプロセスのいずれかでメモリ不足が生じています。特に大型のマルチ CPU コンピュータ上で fdhost.exe がダンプを生成している場合、メモリが不足してきている可能性があります。

注意
フルテキスト クロールで使用されるメモリ バッファに関する情報を取得する方法については、「sys.dm_fts_memory_buffers (Transact-SQL)」を参照してください。

次のような原因が考えられます。

• 完全作成時に使用可能な物理メモリの量がゼロの場合、システム上の物理メモリのほとんどを SQL Server バッファ プールが消費している可能性があります。

  sqlservr.exe プロセスは、構成されている最大サーバー メモリ量に達するまで、バッファ プールで使用できるすべてのメモリを獲得しようとします。max server memory の割り当てが大きすぎる場合は、fdhost.exe プロセスのメモリ不足や共有メモリの割り当ての失敗が発生することがあります。

  注意
  64 ウェイ IA64 コンピュータなどのマルチ 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

この式の変数の既定値は次のとおりです。

変数	既定値
number_of_crawl_ranges	CPU の数
ism_size	1 MB (x86 コンピュータの場合) 合計物理メモリにより、4 MB、8 MB、または 16 MB (x64 コンピュータの場合)
max_outstanding_isms	25 (x86 コンピュータの場合) 5 (x64 コンピュータの場合)

fdhost.exe のメモリ要件の推定方法に関するガイドラインを、以下の表に示します。この表の数式では次の値を使用します。

• F: fdhost.exe に必要なメモリの推定値 (MB 単位)

• T: システムで使用できる合計物理メモリ (MB 単位)

• M: max server memory の最適な設定

重要
数式に関する基本情報については、下記の 1、2、および 3 を参照してください。

プラットフォーム	fdhost.exe のメモリ要件の推定 (MB 単位)—F1	max server memory の計算式—M2
AWE が無効になっている x86	F=Number of crawl ranges* 50	M=minimum(T, 2000)–F– 500
AWE が有効になっている x86	F=Number of crawl ranges* 50	M=T–F– 500
x64 または IA643	F=Number of crawl ranges* 10 * 8	M=T–F– 500

1 複数の完全作成を実行中の場合は、それぞれの fdhost.exe のメモリ要件を、F1、F2 などのように個別に計算してください。その後、M を T**–** sigma**(Fi)** で計算してください。

2 500 MB は、システムの他のプロセスに必要なメモリの推定値です。システムで追加の作業を実行している場合、適宜この値を大きくします。

3ism_size は 8 MB と見なされます (x64 プラットフォームの場合)。

例 : fdhost.exe のメモリ要件の推定

この例は、8 GM の RAM と 4 つのデュアル コア プロセッサを搭載した AMD64 コンピュータを対象としています。最初の計算では、fdhost.exe に必要なメモリ (F) を推定します。クロール範囲の数は 8 です。

F = 8*10*8=640

次の計算では、最適な max server memory 値 (M) を算出します。このシステムで使用可能な合計物理メモリ (T) は 8192 MB です。

M = 8192-640-500=7052

例 : max server memory の設定

この例では、sp_configure ステートメントおよび RECONFIGURETransact-SQL ステートメントを使用して、前の例で計算した M の値 7052 を max server memory として設定します。

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

max server memory 構成オプションを設定するには

• サーバー メモリ オプション

• サーバーのプロパティを表示または変更する方法 (SQL Server Configuration Manager)

• 固定量のメモリを設定する方法 (SQL Server Management Studio)

平均 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)」を参照してください。

    断片化を解消するには、クラスタ化インデックスを再構成または再構築します。詳細については、「インデックスの再編成と再構築」を参照してください。