スレッド プールのプロパティ

Analysis Services では、多くの操作にマルチスレッドが使用され、複数のジョブを並列で実行することでサーバーの全体的なパフォーマンスが向上します。 スレッドをより効率的に管理するために、Analysis Services はスレッド プールを使用してスレッドを事前に割り当て、次のジョブのスレッドの可用性を容易にします。

Analysis Services の各インスタンスは、独自のスレッド プールのセットを保持します。 表形式インスタンスと多次元インスタンスでスレッド プールを使用する方法には大きな違いがあります。 最も重要な違いは、多次元ソリューションのみが IOProcess スレッド プールを使用することです。 そのため、このトピックで説明する PerNumaNode プロパティは、表形式インスタンスでは意味がありません。

このトピックには、次のセクションが含まれています。

• Analysis Services でのスレッド管理

• スレッド プール プロパティ 参照

• プロセッサ グループ内のプロセッサにスレッドをアフィニティするように GroupAffinity を設定する

• NUMA ノード内のプロセッサに IO スレッドをアフィニティするように PerNumaNode を設定する

• 現在のスレッド プールの設定を決定する

• 依存プロパティまたは関連プロパティ

• MSMDSRV.INI について

Analysis Services でのスレッド管理

Analysis Services では、マルチスレッドを使用して、並列で実行されるタスクの数を増やすことで、使用可能な CPU リソースを利用します。 ストレージ エンジンはマルチスレッドです。 ストレージ エンジン内で実行されるマルチスレッド ジョブの例としては、オブジェクトの並列処理や、ストレージ エンジンにプッシュされた個別のクエリの処理、クエリによって要求されたデータ値の返しなどがあります。 数式エンジンは、評価される計算のシリアル特性により、シングル スレッドです。 各クエリは、主に 1 つのスレッドで実行され、多くの場合、ストレージ エンジンによって返されるデータを要求し、待機します。 クエリ スレッドの実行時間が長くなり、クエリ全体が完了した後にのみ解放されます。

既定では、SQL Server 2012 以降のバージョンでは、Analysis Services は、Windows および SQL Server の上位エディションを実行しているシステムで最大 640 個まで、使用可能なすべての論理プロセッサを使用します。 起動時に、msmdsrv.exe プロセスは特定のプロセッサ グループに割り当てられますが、時間の経過と同時に、任意のプロセッサ グループ内の任意の論理プロセッサでスレッドをスケジュールできます。

多数のプロセッサを使用する場合の副作用の 1 つは、クエリと処理の負荷が多数のプロセッサに分散し、共有データ構造の競合が増加するにつれてパフォーマンスが低下する場合があるということです。 これは、特に NUMA アーキテクチャを使用するハイエンド システムだけでなく、同じハードウェア上で複数のデータ集約型アプリケーションを実行している非 NUMA システムでも発生する可能性があります。

この問題を軽減するために、Analysis Services 操作の種類と特定の論理プロセッサ セットの間にアフィニティを設定できます。 GroupAffinity プロパティを使用すると、Analysis Services によって管理されるスレッド プールの種類ごとに使用するシステム リソースを指定するカスタム アフィニティ マスクを作成できます。

カスタム アフィニティは、さまざまな Analysis Services ワークロードに使用される 5 つのスレッド プールのいずれかで設定できます。

• Parsing Shortは、短い要求の解析プールです。 1 つのネットワーク メッセージ内に収まる要求は短いと見なされます。

• \Long の解析 は、1 つのネットワーク メッセージ内に収まらない他のすべての要求の解析プールです。

  注

  いずれかの解析プールのスレッドを使用してクエリを実行できます。 高速な Discover 要求や Cancel 要求など、迅速に実行されるクエリは、クエリ スレッド プールにキューに入れるのではなく、すぐに実行される場合があります。

• Query は、解析スレッド プールによって処理されないすべての要求を実行するスレッド プールです。 このスレッド プール内のスレッドは、検出、MDX、DAX、DMX、DDL コマンドなど、すべての種類の操作を実行します。

• IOProcess は、多次元エンジンのストレージ エンジン クエリに関連付けられている IO ジョブに使用されます。 これらのスレッドによって実行される作業は、他のスレッドに依存しないことが予想されます。 通常、これらのスレッドはパーティションの 1 つのセグメントをスキャンし、セグメント データに対してフィルター処理と集計を実行します。 IOProcess スレッドは、NUMA ハードウェア構成に特に敏感です。 そのため、このスレッド プールには、必要に応じてパフォーマンスを調整するために使用できる PerNumaNode 構成プロパティがあります。

• Process は、集計、インデックス作成、コミット操作を含む、長期間のストレージ エンジン ジョブです。 ROLAP ストレージ モードでは、処理スレッド プールのスレッドも使用されます。

要求を処理するために、Analysis Services はスレッド プールの上限を超える可能性があり、処理を実行するために必要な場合は追加のスレッドを要求します。 ただし、スレッドがタスクの実行を終了すると、スレッドの現在の数が上限を超える場合、スレッドはスレッド プールに返されるのではなく、単に終了されます。

既定では、スレッド プールのサイズは Analysis Services によって決定され、コアの数に基づきます。 サーバーの起動後にmsmdsrv.log ファイルを調べることで、選択した既定値を確認できます。 パフォーマンス チューニングの演習では、クエリまたは処理のパフォーマンスを向上させるために、スレッド プールのサイズと他のプロパティを増やすことを選択できます。

スレッドプール プロパティリファレンス

このセクションでは、各 Analysis Services インスタンスの msmdsrv.ini ファイルにあるスレッド プールのプロパティについて説明します。 これらのプロパティのサブセットは、SQL Server Management Studio にも表示されます。

プロパティはアルファベット順に一覧表示されます。

プロセッサ グループ内のプロセッサにスレッドをアフィニティするように GroupAffinity を設定する

GroupAffinity は、高度なチューニング目的で提供されます。 GroupAffinity プロパティを使用すると、Analysis Services スレッド プールと特定のプロセッサ間のアフィニティを設定できます。ただし、ほとんどのインストールでは、Analysis Services は使用可能なすべての論理プロセッサを使用できる場合に最適に実行されます。 したがって、グループ アフィニティは既定では指定されていません。

パフォーマンス テストで CPU 最適化の必要性が示されている場合は、Windows Server Resource Manager を使用して論理プロセッサとサーバー プロセス間のアフィニティを設定するなど、より高いレベルのアプローチを検討できます。 このような方法は、個々のスレッド プールのカスタム アフィニティを定義するよりも、実装と管理が簡単な場合があります。

この方法が不十分な場合は、スレッド プールのカスタム アフィニティを定義することで、より高い精度を実現できます。 アフィニティ設定のカスタマイズは、大規模なマルチコア システム (NUMA または NUMA 以外) で推奨される可能性が高く、スレッド プールが広範囲にわたるプロセッサに分散しているためにパフォーマンスが低下します。 論理プロセッサ数が 64 未満のシステムでは GroupAffinity を設定できますが、この利点はごくわずかであり、パフォーマンスが低下する可能性もあります。

構文

値はプロセッサ グループごとに 16 進数で、16 進数は、指定されたスレッド プールにスレッドを割り当てるときに Analysis Services が最初に使用しようとする論理プロセッサを表します。

論理プロセッサのビットマスク

1 つのプロセッサ グループ内に最大 64 個の論理プロセッサを含めることができます。 ビットマスクは、スレッド プールによって使用される (または使用されていない) グループ内の論理プロセッサごとに 1 (または 0) です。 ビットマスクを計算したら、 GroupAffinityの値として 16 進数の値を計算します。

複数のプロセッサ グループ

プロセッサ グループは、システムの起動時に決定されます。 GroupAffinity は、コンマ区切りリスト内の各プロセッサ グループの 16 進数の値を受け取ります。 複数のプロセッサ グループ (ハイエンド システムでは最大 10 個) を指定すると、0x0を指定することで個々のグループをバイパスできます。 たとえば、4 つのプロセッサ グループ (0、1、2、3) を持つシステムでは、1 番目と 3 番目の値に0x0を入力して、グループ 0 と 2 を除外できます。

<GroupAffinity>0x0, 0xFF, 0x0, 0xFF</GroupAffinity>

プロセッサ アフィニティ マスクを計算する手順

GroupAffinityは、msmdsrv.ini または SQL Server Management Studio のサーバー プロパティ ページで設定できます。

1. プロセッサとプロセッサ グループの数を決定する

   Coreinfo ユーティリティは winsysinternals からダウンロードできます。

   coreinfo を実行して、論理プロセッサからグループ マップセクションにこの情報を取得します。 論理プロセッサごとに個別の行が生成されます。

2. プロセッサを右から左にシーケンスします。 7654 3210

   この例では 8 個のプロセッサ (0 ~ 7) のみを示していますが、プロセッサ グループには最大 64 個の論理プロセッサを使用でき、エンタープライズ クラスの Windows サーバーには最大 10 個のプロセッサ グループを含めることができます。

3. 使用するプロセッサ グループのビットマスクを計算する

   7654 3210

   論理プロセッサを除外するか含めるかに応じて、数値を 0 または 1 に置き換えます。 8 つのプロセッサを持つシステムでは、Analysis Services にプロセッサ 7、6、5、4、1 を使用する場合、計算は次のようになります。

   1111 0010

4. バイナリ番号を 16 進値に変換する

   電卓または変換ツールを使用して、バイナリ番号を等価の 16 進数に変換します。 この例では、 1111 0010 は 0xF2 に変換します。

5. GroupAffinity プロパティに 16進の値を入力してください

   msmdsrv.ini または Management Studio のサーバー プロパティ ページで、 GroupAffinity を手順 4 で計算した値に設定します。

NUMA ノード内のプロセッサに IO スレッドをアフィニティするように PerNumaNode を設定する

多次元 Analysis Services インスタンスの場合は、IOProcess スレッド プールにPerNumaNodeを設定して、スレッドのスケジュール設定と実行をさらに最適化できます。 GroupAffinityは、特定のスレッド プールに使用する論理プロセッサのセットを識別しますが、PerNumaNodeは、複数のスレッド プールを作成するかどうかを指定することでさらに 1 歩進み、許可されている論理プロセッサの一部のサブセットにさらにアフィニティを設定します。

PerNumaNodeの有効な値は、このトピックの「スレッド プールのプロパティリファレンス」セクションで説明されているように、-1、0、1、2 です。

既定値 (推奨)

NUMA ノードを持つシステムでは、PerNumaNode=-1 の既定の設定を使用することをお勧めします。これにより、Analysis Services では、ノード数に基づいてスレッド プールの数とそのスレッド アフィニティを調整できます。 システムのノード数が 4 未満の場合、Analysis Services は PerNumaNode=0 で記述された動作を実装しますが、 PerNumaNode=1 は 4 つ以上のノードを持つシステムで使用されます。

値の選択

別の有効な値を使用するように既定値をオーバーライドすることもできます。

PerNumaNode=0 の設定

NUMA ノードは無視されます。 IOProcess スレッド プールは 1 つだけあり、そのスレッド プール内のすべてのスレッドはすべての論理プロセッサとアフィニティされます。 既定では (PerNumaNode=-1)、コンピューターに 4 つ未満の NUMA ノードがある場合に動作する設定です。

PerNumaNode=1 の設定

IOProcess スレッド プールは、NUMA ノードごとに作成されます。 スレッド プールを分離すると、NUMA ノード上のローカル キャッシュなどのローカル リソースへの調整されたアクセスが向上します。

PerNumaNode=2 の設定

この設定は、集中型の Analysis Services ワークロードを実行する非常にハイエンドのシステムを対象としています。 このプロパティは、IOProcess スレッド プールのアフィニティを最も細かいレベルで設定し、論理プロセッサ レベルで個別のスレッド プールを作成およびアフィニティ化します。

次の例では、4 つの NUMA ノードと 32 個の論理プロセッサを持つシステムで、 PerNumaNode を 2 に設定すると、32 IOProcess スレッド プールになります。 最初の 8 つのスレッド プール内のスレッドは、NUMA ノード 0 内のすべての論理プロセッサに関連付けられますが、理想的なプロセッサは 0、1、2、最大 7 に設定されます。 次の 8 つのスレッド プールは、NUMA ノード 1 のすべての論理プロセッサとアフィニティが設定され、理想的なプロセッサは 8、9、10、最大 15 に設定されます。

このレベルのアフィニティでは、スケジューラは常に、優先する NUMA ノード内で、理想的な論理プロセッサを最初に使用しようとします。 論理プロセッサが使用できない場合、スケジューラは同じノード内の別のプロセッサを選択するか、他のスレッドが使用できない場合は同じプロセッサ グループ内で別のプロセッサを選択します。 詳細と例については、 Analysis Services 2012 の構成設定 (Wordpress ブログ) を参照してください。

IOProcess スレッド間の作業の分散

PerNumaNode プロパティを設定するかどうかを検討するときに、スレッドの使用方法IOProcess把握することで、情報に基づいた意思決定を行うことができます。

IOProcessは、多次元エンジンのストレージ エンジン クエリに関連付けられている IO ジョブに使用されることを思い出してください。

セグメントがスキャンされると、エンジンはセグメントが属するパーティションを識別し、セグメント・ジョブをその区画が使用するスレッド・プールにキューに入れようとします。 一般に、パーティションに属するすべてのセグメントは、タスクを同じスレッド プールにキューに入れます。 NUMA システムでは、パーティションのすべてのスキャンで、その NUMA ノードにローカルに割り当てられているファイル システム キャッシュ内のメモリが使用されるため、この動作が特に便利です。

次のシナリオでは、NUMA システムのクエリ パフォーマンスを向上させる可能性がある調整が提案されています。

• パーティションが不足しているメジャー グループ (1 つのパーティションを持つなど) の場合は、パーティションの数を増やします。 パーティションを 1 つだけ使用すると、エンジンは常にタスクを 1 つのスレッド プール (スレッド プール 0) にキューに入れます。 パーティションを追加すると、エンジンは追加のスレッド プールを使用できます。

  または、追加のパーティションを作成できない場合は、スレッド プール 0 で使用できるスレッドの数を増やす方法として、 PerNumaNode =0 を設定してみてください。

• セグメント スキャンが複数のパーティションに均等に分散されているデータベースの場合、 PerNumaNode を 1 または 2 に設定すると、システムで使用されるスレッド プールの合計数が増えるため、クエリのパフォーマンスが向上 IOProcess 。

• 複数のパーティションがあるが、1 つだけが頻繁にスキャンされるソリューションの場合は、 PerNumaNode=0 を設定して、パフォーマンスが向上するかどうかを確認してください。

パーティション スキャンとディメンション スキャンの両方で IOProcess スレッド プールが使用されますが、ディメンション スキャンではスレッド プール 0 のみが使用されます。 これにより、そのスレッド プールに若干不均等な負荷が発生する可能性がありますが、ディメンション スキャンは非常に高速で頻度が低い傾向にあるので、不均衡は一時的である必要があります。

ジョブ アーキテクチャの詳細については、 SQL Server 2008 Analysis Services パフォーマンス ガイドのセクション 2.2 を参照してください。

依存プロパティまたは関連プロパティ

Analysis Services 操作ガイドのセクション 2.4 で説明したように、処理スレッド プールを増やす場合は、CoordinatorExecutionModeの設定とCoordinatorQueryMaxThreadsの設定に、スレッド プールのサイズを最大限に活用できる値があることを確認する必要があります。

Analysis Services は、処理またはクエリ要求を完了するために必要なデータを収集するためにコーディネーター スレッドを使用します。 コーディネーターは、最初に、タッチする必要があるパーティションごとに 1 つのジョブをキューに入れます。 これらの各ジョブは、パーティション内でスキャンする必要があるセグメントの合計数に応じて、さらに多くのジョブをキューに入れ続けます。

CoordinatorExecutionModeの既定値は -4 です。つまり、コアごとに並列に 4 つのジョブが制限されます。これは、ストレージ エンジンのサブキューブ要求によって並列に実行できるコーディネーター ジョブの合計数を制限します。

CoordinatorQueryMaxThreadsの既定値は 16 で、パーティションごとに並列に実行できるセグメント ジョブの数が制限されます。

現在のスレッド プールの設定を決定する

Analysis Services は、各サービスの起動時に、現在のスレッド プール設定を、最小スレッドと最大スレッド数、プロセッサ アフィニティ マスク、コンカレンシーなど、msmdsrv.log ファイルに出力します。

次の例は、ログ ファイルからの抜粋で、ハイパースレッディングが有効になっている 4 コア システムのクエリ スレッド プール (MinThread=0、MaxThread=0、Concurrency=2) の既定の設定を示しています。 アフィニティ マスクが0xFFされ、8 つの論理プロセッサが示されます。 マスクには先頭に 0 が追加されていることに注意してください。 先頭のゼロは無視できます。

"10/28/2013 9:20:52 AM) Message: The Query thread pool now has 1 minimum threads, 16 maximum threads, and a concurrency of 16. Its thread pool affinity mask is 0x00000000000000ff. (Source: \\?\C:\Program Files\Microsoft SQL Server\MSAS11.MSSQLSERVER\OLAP\Log\msmdsrv.log, Type: 1, Category: 289, Event ID: 0x4121000A)"

MinThread と MaxThread を設定するためのアルゴリズムには、システム構成 、特にプロセッサの数が組み込まれています。 次のブログ投稿では、値の計算方法に関する分析情報を提供しています: Analysis Services 2012 構成設定 (Wordpress ブログ)。 これらの設定と動作は、以降のリリースで調整される可能性があることに注意してください。

次の一覧は、プロセッサのさまざまな組み合わせに対する他のアフィニティ マスク設定の例を示しています。

• 8 コア システムのプロセッサ 3-2-1-0 に対するアフィニティにより、次のビットマスクが発生します: 00001111、16 進数の値: 0xF

• 8 コア システムのプロセッサ 7-6-5-4 のアフィニティは、ビットマスク 11110000、16進数値: 0xF0

• 8コアシステムのプロセッサ 5-4-3-2 に対するアフィニティによって、ビットマスク: 00111100 と16進数値: 0x3C が得られます。

• 8 コア システムのプロセッサ 7-6-1-0 に対するアフィニティにより、次のビットマスクが発生します: 11000011、16 進数の値: 0xC3

複数のプロセッサー・グループを持つシステムでは、コンマ区切りリストでグループごとに個別のアフィニティ・マスクが生成されることを思い出してください。

MSMDSRV.INI について

msmdsrv.ini ファイルには Analysis Services インスタンスの構成設定が含まれています。この設定は、そのインスタンスで実行されているすべてのデータベースに影響します。 サーバー構成プロパティを使用して、1 つのデータベースのパフォーマンスを最適化して、他のすべてのデータベースを除外することはできません。 ただし、Analysis Services の複数のインスタンスをインストールし、同様の特性やワークロードを共有するデータベースに役立つプロパティを使用するように各インスタンスを構成できます。

すべてのサーバー構成プロパティは、msmdsrv.ini ファイルに含まれます。 変更される可能性が高いプロパティのサブセットは、SSMS などの管理ツールにも表示されます。

msmdsrv.ini の内容は、Analysis Services の表形式インスタンスと多次元インスタンスの両方で同じです。 ただし、一部の設定は 1 つのモードにのみ適用されます。 サーバー モードに基づく動作の違いについては、プロパティ リファレンス ドキュメントで説明します。

こちらもご覧ください

プロセスとスレッドについて複数のプロセッサプロセッサグループSQL Server 2012 における Analysis Services スレッド プールの変更Analysis Services 2012 設定 (Wordpress ブログ)64 個以上のプロセッサを持つシステムのサポートSQL Server 2008 R2 Analysis Services 操作ガイド