コンテンツ配布用のコンポーネントとスレッド

この記事は、コンテンツ配布のコンポーネントとスレッドを理解するのに役立ちます。

元の製品バージョン: 現在のブランチConfiguration Manager、Microsoft System Center 2012 Configuration Manager、Microsoft System Center 2012 R2 Configuration Manager

コンテンツ配布に使用されるコンポーネント

コンテンツ配布に使用される主なコンポーネントの簡単な一覧を次に示します。

Distribution Manager (DistMgr) スレッド

Distribution Manager (DistMgr) は、配布ポイント (SP) にコンテンツを配布するためのさまざまな操作を実行します。 これらの操作はさまざまな種類のスレッドによって処理されます。次の図は、既定のスレッド構成の DistMgr スレッド階層について説明しています。

• Main DistMgr スレッド

  識別用のログ エントリ: SMS_EXECUTIVE started SMS_DISTRIBUTION_MANAGER as thread ID 3648 (0xE40)

  このスレッドは、サービスの起動時にによって SMS_Executive 開始されます。 メイン DistMgr スレッドは、レプリケーション処理、DP マネージャー、コンテンツ クリーンアップ、DP 証明書の監視、コンテンツ ライブラリの移動、IIS 構成変更処理、DP 再割り当ておよびアップグレード処理スレッドの起動時に開始します。 また、パッケージの変更が発生したときに、パッケージ処理スレッドをオンデマンドで開始します

  このスレッドは、これらのスレッドの管理に加えて、サイト コントロール ファイルの変更を処理し、DP 設定を更新します (DP/PXE の構成、レジストリ設定の更新、DP での監視/使用タスクの作成など)。

• レプリケーション処理スレッド

  識別用のログ エントリ: Starting thread for processing replication, thread ID = 0x1A14 (6676)

  このスレッドは、メイン DistMgr スレッドによって開始され、ディレクトリ内の次のファイルをDistMgr.box\incoming処理します。

  ファイル	説明
  .駅	データベース更新テーブルのパッケージのPkgStatus状態を示します。
  .Fwd	パッケージを送信するミニ ジョブを作成して、指定したパッケージを指定した宛先サイトに転送します。
  .Dmd	オンデマンド要求を分散します。 指定した DP に指定したパッケージをターゲットにします。
  .PUL	更新 DB 内のテーブルで DP パッケージの応答をPullDPResponseプルします。

  注:

  このスレッドはシングル スレッドであり、これらのファイルを処理するためのスレッドを作成しません。

• DP Manager スレッド

  識別用のログ エントリ: Starting the DP Manager thread, thread ID = 0x5D8 (1496)

  このスレッドは、メイン DistMgr スレッドによって開始され、サイトコントロールファイルの変更を検出するときに、DP の削除を処理します。 適切なサイト制御ファイルの変更が発生すると、SMSDBMON は、このスレッドによって処理される DPN (DP 通知) ファイル DistMgr.box をドロップします。

  DPN ファイルは、DP の削除 (テーブル内の Action = 3 で検出) を伴う DP の変更を DistributionPoints 通知するために使用されます。

  注:

  このスレッドはシングル スレッドであり、作業を実行するためのスレッドを作成しません。

• コンテンツ クリーンアップ スレッド

  識別用のログ エントリ: Starting the content cleanup thread, thread ID = 0x1604 (5636)

  このスレッドは、メイン DistMgr スレッドによって開始され、コンテンツ クリーンアップを実行します。 データベースから孤立したコンテンツを検出することで、コンテンツのクリーンアップが必要かどうかを判断します。 このスレッドは、リモート DP に一度に削除するように指示できるコンテンツの数に既定のバッチ サイズ 50 を使用します。 ただし、この値は、次のレジストリ キーを設定することでオーバーライドできます。

  SMS\Components\SMS_DISTRIBUTION_MANAGER\RemoteContentCleanupBatchSize

  DWORD 値は 1 から 500 の間で指定できます。

  注:

  Microsoft サポート プロフェッショナルに相談せずに、この値を変更しないでください。 このスレッドはシングル スレッドであり、作業を実行するためのスレッドを作成しません。

• DP 証明書監視スレッド

  識別用のログ エントリ: Starting the DP cert monitoring thread, thread ID = 0x7290 (29328)

  このスレッドは、メイン DistMgr スレッドによって開始されます。 このスレッドは を処理します。CER ファイルを作成し、拡張 HTTP モードが有効になっている場合に IIS で証明書バインドを構成します。 このモードでは、生成された証明書Configuration Manager IIS で使用する必要があります。

  注:

  このスレッドはシングル スレッドであり、作業を実行するためのスレッドを作成しません。

• コンテンツ ライブラリの移動スレッド

  識別用のログ エントリ: Starting the content library move thread, thread ID = 0x11D6C (73068)

  このスレッドは、メイン DistMgr スレッドによって開始され、 の後の新しい場所にコンテンツ ライブラリを移動します。CML ファイルは でDistMgr.box削除されます。

  注:

  このスレッドはシングル スレッドであり、作業を実行するためのスレッドを作成しません。

• IIS 構成変更処理スレッド

  識別用のログ エントリ: Starting the IIS config change processing thread, thread ID = 0x408C (16524)

  このスレッドは、メイン DistMgr スレッドによって開始され、 で IIS ファイルが削除された後に、標準配布ポイントとプル配布ポイントの IIS 仮想ディレクトリの構成をDistMgr.box処理します。 このスレッドは、コンポーネントの IISConfigChangeThreadLimit サイト コントロール ファイル (SCF) プロパティ SMS_DISTRIBUTION_MANAGER を読み取り、IIS の変更を同時に実行するために開始できるスレッドの数を決定します。 SCF プロパティの IISConfigChangeThreadLimit 既定値は 50 ですが、必要に応じて変更できます。 ただし、何らかの理由でこの SCF プロパティが存在しない場合は、既定値の 50 が に IISConfigChangeThreadLimit使用されます。

  注:

  このスレッドにより、DP IIS 構成の変更を実行するためのスレッドが増えます。 各ワーカー スレッドは、特定の DP の IIS 仮想ディレクトリの構成を処理します。

• DP 再割り当てスレッド

  識別用のログ エントリ: Starting the shared DP reassignment thread, thread ID = 0x9C0C (39948)

  このスレッドは、メイン DistMgr スレッドによって開始され、 の場合は標準配布ポイントとプル配布ポイントの DP 再割り当てを処理します。DPU ファイルは でDistMgr.box削除されます。 このスレッドは、コンポーネントの SharedDPImportThreadLimit サイト コントロール ファイル (SCF) プロパティ SMS_DISTRIBUTION_MANAGER を読み取り、DP 再割り当てを同時に実行するために開始できるスレッドの数を決定します。 SCF プロパティの SharedDPImportThreadLimit 既定値は 50 ですが、必要に応じて変更できます。 ただし、何らかの理由でこの SCF プロパティが存在しない場合は、既定値の 50 が に SharedDPImportThreadLimit使用されます。

  注:

  このスレッドでは、DP の再割り当てを実行するスレッドが増えます。 各ワーカー スレッドは、特定の DP の再割り当てを処理します。

• 処理スレッドのアップグレード

  識別用のログ エントリ: Starting the DP upgrade processing thread, thread ID = 0x1968 (6504)

  このスレッドは、メイン DistMgr スレッドによって開始され、標準配布ポイントとプル配布ポイントの DP のインストールとアップグレードを処理します。 を呼び出 spGetDPsForUpgrade して、アップグレードする必要がある DP の一覧を取得します。 このスレッドは、コンポーネントの DPUpgradeThreadLimit サイト コントロール ファイル (SCF) プロパティ SMS_DISTRIBUTION_MANAGER を読み取り、DP インストール/アップグレードを同時に実行するために開始できるスレッドの数を決定します。 SCF プロパティの DPUpgradeThreadLimit 既定値は 50 ですが、必要に応じて変更できます。 ただし、何らかの理由でこの SCF プロパティが存在しない場合は、既定値の 5 が に DPUpgradeThreadLimit使用されます。

  注:

  このスレッドにより、DP のインストール/アップグレード作業を実行するためのスレッドが増えます。 各ワーカー スレッドは、特定の DP のインストール/アップグレードを処理します。

• パッケージ処理スレッド

  識別用のログ エントリ: Started package processing thread for package 'PKGID', thread ID = 0x8E8 (2280)

  これらのスレッドは、メイン DistMgr スレッドによって開始されます。 パッケージ処理スレッドの数は、[ソフトウェア配布コンポーネントの構成] プロパティの [パッケージ スレッドの最大数] 設定によって決まります。 各パッケージ処理スレッドは、パッケージ コンテンツのハッシュを実行し、コンテンツの圧縮コピーを作成します。

  注:

  すべてのパッケージ処理スレッドは同時に実行されますが、パッケージ ソースのハッシュと圧縮を担当します。 圧縮の周りには重要なセクションがあります。つまり、コンテンツを一度に圧縮できるスレッドは 1 つだけです。 多数の新しい大きなパッケージが作成および配布された場合、パッケージごとのスレッドは、圧縮ロックを取得する順番を待機しているチェーン内でブロックできます。

  パッケージアクション (追加/更新/削除) に応じて、各パッケージ処理スレッドも次を作成します。

  • DP でコンテンツを追加または更新するためのパッケージ転送マネージャー ジョブを作成するための DP スレッド。
  • DP スレッドは、コンテンツ ライブラリからコンテンツを削除するようにリモート配布ポイントに指示します。

  各パッケージ処理スレッドが作成できる DP スレッドの数は、[ソフトウェア配布コンポーネント構成] プロパティの [パッケージあたりの最大スレッド数] 設定によって決まります。

  注:

  パッケージ処理スレッドはマルチスレッドであり、各パッケージ処理スレッドは、作業を実行するためにより多くのスレッドを作成します。 各ワーカー スレッドは、SP の追加/更新/削除操作を処理します。

Distribution Manager スレッドの構成

すべてのConfiguration Manager サイト (中央管理サイトを含む) では、配布ポイント (DP) へのコンテンツの配布に使用できるスレッドの数を構成できます。 この構成は各サイトに固有であり、[ サイト ] ノードの下にあるサイトを右クリックし、[ サイト コンポーネント>ソフトウェア配布の構成] を選択することでアクセスできます。 既定の構成を次に示します。

ほとんどの場合、[ パッケージの最大数 ] と [パッケージ ごとの最大スレッド 数] 設定にのみ関係します。

• パッケージの最大数: CONFIGMGR同時に DP に送信できるパッケージの最大数を指定します。 指定した値は 1 から 50 の間である必要があります。
• パッケージあたりの最大スレッド数: 配布中に各パッケージに割り当てられるスレッドの最大数を指定します。 指定された値は 1 から 999 の間である必要があります。

パッケージ の最大数 =3 と パッケージあたりの最大スレッド数 = 5 の既定の構成は、 3x5 とも呼ばれます。 これは、多くの場合、スレッド構成がワークフローで示される方法です。

これが本当に意味するもの

ディストリビューション マネージャー (DistMgr) への影響

既定のスレッド構成 が 3x5 の場合、DistMgr は 3 つのパッケージを同時に処理し、パッケージごとに最大 5 つのスレッドを使用できるため、合計 15 個のスレッドを使用して作業を実行できます。 5 つ以上の DP に配布する必要があるパッケージが 3 つ以上あると仮定すると、これがどのように分解されるかを次に示します。

個々のパッケージを処理するために、メイン DistMgr スレッドによってパッケージ処理スレッドが生成されます。 このパッケージ処理スレッドは、[ パッケージの最大数 ] 設定の 3 つのパッケージ処理スロットのうち 1 つを使用します。 パッケージごとに一意のパッケージ処理スレッドがあります。DistMgr は、同じパッケージに対して複数のパッケージ処理スレッドを開始しません。 つまり、3 つの一意のパッケージは、3 つの一意のパッケージ処理スレッドを利用します。 これらの各パッケージ処理スレッドは、最大 5 つの DP スレッドを生成して、パッケージを 5 つの DP に同時に配布できます。

パッケージ転送マネージャー (PkgXferMgr) への影響

DistMgr によって作成された PkgXferMgr ジョブごとに、PkgXferMgr は 1 つのスレッドを使用します。 3x5 のスレッド構成は、PkgXferMgr の送信容量が 15 に設定されていることを意味します。つまり、PkgXferMgr は同時に 15 個を超えるジョブで動作できないため、最大 15 スレッドに制限されます。

スレッドの実行時間

DistMgr スレッド

DP スレッドの目的は、パッケージ転送マネージャーのジョブを作成し、DP への実際のコンテンツ コピーを実行することです。 DP スレッドは PkgXferMgr ジョブの作成後に終了し、その結果、DP スレッドの有効期間は短くなります。 この性質上、ほとんどの場合、コンテンツの配布を高速化するために積極的なスレッド構成を設定する必要はありません。 積極的な値を設定する代わりに、 適切な値の選択に目を 向けます (詳細については、以下を参照してください)。

PkgXferMgr スレッド

標準の DP の場合、PkgXferMgr スレッドはコンテンツを送信する実際の作業を実行するため、これらのスレッドの有効期間はパッケージのサイズによって異なります。 より大きなパッケージの場合、パッケージのサイズとネットワーク速度によっては、これらのスレッドに長い時間がかかる場合があります。 これらのスレッドの完了には長い時間がかかる場合がありますが、DistMgr スレッドの有効期間は大幅に短くなります。つまり、DistMgr は PkgXferMgr の多数のジョブをキューに入れることができ、キューにジョブのバックログが作成されます。

プル DP の場合、PkgXferMgr スレッドはプル DP に通知し、プル DP にコンテンツのダウンロードを求めます。 その結果、プル DP の PkgXferMgr スレッドの有効期間は短くなります。 PkgXferMgr は、(構成されたポーリング間隔に基づいて) プル DP ポーリングを実行して、ジョブの進行状況をチェックする別のスレッドを開始します。 ただし、これは簡単な操作でもあり、これらのスレッドの有効期間も短くなります。

適切な値の選択

これらの設定に適切な値を決定するには、まず、Configuration Manager階層を理解する必要があります。 次の架空のConfiguration Manager環境を考えてみましょう。

• 中央管理サイト: CS1
• プライマリ サイト: PS1
• PS1 に報告する通常の配布ポイントの数: 200
• パッケージの合計数: 1000

この環境では、既定のスレッド構成 (3x5) は、新しいパッケージを 200 個すべての DP に配布する必要がある場合、一度に処理する DP は 5 つだけであることを意味します。 DP スレッドが終了すると、別の DP スレッドが生成され、すべての DP が処理されるまでプロセスが続行されます。 このプロセスでは、200 個すべての DP をループするのに時間がかかります。

これを最適化するには、まずいくつかの質問をする必要があります。

1. 平均して同時に追加/更新/配布されるパッケージの数を予測していますか?
2. サイト内の IP の数はいくつですか? サイト サーバーとこれらの DP の間のネットワーク構成はどのように行われますか?

最初の質問に対する回答が 5 で、2 番目の質問に対する回答がネットワーク接続が良好な 200 であると仮定すると、理論的には [パッケージの最大数] を 5 に、パッケージあたりの最大スレッド数を 200 に設定し、Configuration Manager 200 すべての DP に最大 5 つのパッケージを同時に送信できます。 ただし、これは、平均負荷を超える負荷がある場合、最大 1000 個のスレッド (多くのスレッド) を作成できることを意味します。 通常、より多くのスレッドが適していますが、実行される作業はハードウェアとネットワークの構成にも依存するため、常にとは限りません。 スレッドが多すぎると、ボトルネックが発生し、改善される代わりに処理速度が低下することがあります。

これらの設定を構成するときに覚えておくべき最も重要なことは、 残高を見つけることです。 上記の例では、スレッド構成を 5x100 (またはハードウェア/ネットワークによっては 5x50) に設定すると、5 つの異なるパッケージに対して最大 100 DP を同時に処理Configuration Managerできます。 これらの設定では、高負荷時に生成できるスレッドの最大数は 500 を超えなくなります。

同じ階層では、環境内に新しい DP を導入し、1000 個すべてのパッケージを DP に配布する必要がある状況が発生する可能性があります。 この場合、 5x100 のスレッド構成は、一度に 5 つのパッケージしか処理できず、1000 個のパッケージの処理にはかなりの時間がかかるため、有効になりません。 このシナリオでは、次のいずれかを選択できます。

• スレッド構成を現在の要件に適した 50x10 に一時的に設定しますが、長い目で見ると 200 個の DP があると考えると適切なオプションではありません。
• スレッド構成を 20 x 25 のように完全に設定すると、バランスが大幅に向上し、多数のパッケージを数個の DP に移動する必要があるシナリオや、多数のパッケージが多数の DP に移動する必要があるシナリオでも同様のパフォーマンスが提供されます。

送信者スレッドの構成

各Configuration Manager サイト (中央管理サイトとセカンダリ サイトを含む) には、1 つの送信者があります。 送信者は、1 つのサイトから宛先サイトへのネットワーク接続を管理し、同時に複数のサイトへの接続を確立できます。 サイトに接続するために、送信者はサイトへのファイル レプリケーション ルートを使用して、ネットワーク接続の確立に使用するアカウントを識別します。 送信者はこのアカウントを使用して、宛先サイトの SMS_SITE 共有にデータを書き込みます。

既定では、送信者は複数の同時実行スレッドを使用して、宛先サイトにデータを書き込みます。 各同時実行スレッドは、別のファイル ベースのオブジェクトをコピー先サイトに転送できます。 既定では、送信者がオブジェクトの送信を開始すると、オブジェクト全体が送信されるまで、そのオブジェクトのデータ ブロックを書き込み続けます。

すべてのConfiguration Managerサイトでは、Sender コンポーネントが他のサイトに同時にデータを送信するために使用できるスレッドの数を構成できます。 この構成は各サイトに固有であり、[サイト] ノードの [サイトのプロパティ] から [送信者] タブを選択してアクセスできます。既定の構成を次に示します。

すべてのサイト: この送信者に許可される同時通信の最大数。 既定値は 5 です。 これらの通信は、サイトごとに指定された最大値によって制限されている場合を除き、異なるサイトまたは同じ サイトのすべて宛てにすることができます。

サイトごと: 1 つの宛先サイトに対して許可される同時通信の最大数。 既定値は 3 です。

意味

[ すべてのサイト ] で指定された値は、Sender が他のサイトに同時にデータを送信するために使用できるスレッドの合計数を定義します。 [すべてのサイト] のスレッドの合計数のうち、任意の 1 つの宛先サイトにデータを送信するために使用できる [サイトごと] で最大スレッド数を割り当てることができます。 既定では、各サイトは 5 つの同時スレッドを使用するように構成され、1 つの宛先サイトにデータを送信するときに使用できる 3 つのスレッドがあります。 この数を増やすと、Configuration Managerがより多くのファイルを同時に転送できるようにすることで、サイト間のデータのスループットを向上させることができます。 この数を増やすと、サイト間のネットワーク帯域幅の需要も増加します。

適切な値を選択する

これらの設定に適切な値を決定するには、まずConfiguration Manager階層を理解する必要があります。 次の架空のConfiguration Manager環境を考えてみましょう。

• 中央管理サイト: CS1
• プライマリ サイト: PS1
• プライマリ サイト: PS2
• プライマリ サイト: PS3
• プライマリ サイト: PS4

この環境では、既定の Sender スレッド構成では、合計 5 つのスレッドを使用できます。 これらの 5 つのスレッドのうち、4 つの宛先プライマリ サイトのいずれかに 3 を使用できます。 管理者がこれらのすべてのサイトに 3 を送信すると、送信者がこれらのサイトの 1 つに対して 3 つのスレッドを使用する可能性があります (PS1 とします)。残りのサイトには 2 つのスレッドのみが残ります。 残りの 2 つのスレッドのうち、送信側は PS2 に 1 を使用し、もう 1 つのスレッドは PS3 に使用し、5 つの許可されたスレッドすべてを使用して PS4 に同時にデータを送信する余地を残しません。 この時点で、Sender は既存の 5 つのスレッドのいずれかが完了するのを待ってから、より多くのデータを送信する必要があります。 既存のスレッドが完了すると、Sender は PS2/PS3/PS4 サイトにさらに多くのデータを送信するために別のスレッドを使用できるようになります。

Sender が通信するサイトごとに 10 個のスレッドを確保することをお勧めします。 この場合、CS1 サイトは他の 4 つのサイトと通信できます。つまり、4 つのサイトに対して 10 のサイトごとの値を 40 に設定する必要があります。

帯域幅の制御とスレッド

Configuration Managerでは、スケジュールを構成し、リモート配布ポイントとサイトのファイル レプリケーション ルートに対して特定の調整設定を設定できます。 リモート配布ポイントへのスケジューリングと調整のコントロールは、標準の送信者アドレスの設定と似ていますが、この場合、設定はパッケージ転送マネージャーというコンポーネントによって使用されます。

パッケージ転送マネージャー コンポーネント ( サイト サーバー - >DP の場合) の場合、調整設定は、サイト サーバー上にない標準配布ポイントのプロパティで構成されます。

Sender コンポーネント (Site Server-Site<>Server の場合) の場合、調整設定は、階層構成ファイル レプリケーションの下のファイル レプリケーション ルートのプロパティで構成>されます。

スケジュール オプション

データを制限するには、期間を選択し、次のいずれかの設定を選択して可用性を確保します。

• [すべての優先順位で開く]: Configuration Managerが制限なしで配布ポイントにデータを送信することを指定します。

• [中優先度と高優先度を許可する]: Configuration Managerが配布ポイントに中優先度と高優先度のデータのみを送信することを指定します。

• [優先度の高いデータのみを許可する]: Configuration Managerが配布ポイントに優先度の高いデータのみを送信することを指定します。

• [閉じる]: Configuration Managerが配布ポイントにデータを送信しないことを指定します。

  優先順位によってデータを制限したり、選択した期間の接続を閉じることもできます。

レート制限オプション

これは、配布ポイントにコンテンツを転送するときに使用されるネットワーク帯域幅を制御するレート制限を構成するために使用されます。 以下のオプションから選択できます。

• [この宛先に送信する場合は無制限]: レート制限のない配布ポイントにコンテンツConfiguration Manager送信することを指定します。
• パルス モード: 配布ポイントに送信されるデータ ブロックのサイズを指定します。 また、各データ ブロックを送信するまでの時間遅延を指定することもできます。 このオプションは、低帯域幅ネットワーク接続経由で配布ポイントにデータを送信する必要がある場合に使用します。 たとえば、リンクの速度や特定の時刻の使用状況に関係なく、5 秒ごとに 1 KB のデータを送信する制約がある場合があります。
• 指定した最大転送速度に時間単位で制限する: 構成した時間の割合のみを使用して、サイトが配布ポイントにデータを送信するように、この設定を指定します。 このオプションを使用する場合、Configuration Managerは使用可能なネットワーク帯域幅を識別するのではなく、データを送信できる時間を時間のスライスに分割します。 その後、データは短時間送信され、その後にデータが送信されない時間のブロックが続きます。 たとえば、最大レートが 50% に設定されている場合、Configuration Managerは一定期間データを送信し、その後にデータが送信されない同じ期間にデータを送信します。 データの実際のサイズ量 (データ ブロックのサイズ) は管理されません。 代わりに、データが送信される時間のみが管理されます。

これらの設定の詳細については、「Configuration Managerでのコンテンツ管理の構成」を参照してください。

これが Sender スレッドと PkgXferMgr スレッドに与える影響

サイトに対して帯域幅制御が有効になっている場合、送信者コンポーネントはサイトの Sender スレッド構成を無視し、そのサイトに対して 1 つのスレッドのみを使用します。 同様に、DP に対して帯域幅制御が有効になっている場合、PkgXferMgr はスレッド構成を無視し、DP には 1 つのスレッドのみを使用します。

帯域幅制御が有効な場合、 PkgXferMgr.log は次のいずれかの行をログに記録します。

スケジューリング：

~DPNAME.CONTOSO.COM へのアドレスは現在帯域幅制御下にあるため、1 つの接続のみが許可され、プールに送信要求が返されます。

パルス モード:

~DPNAME.CONTOSO.COM への addres は現在パルス モードであるため、1 つの接続のみが許可されます。
~パルス モードでは 1 つの接続しか許可されないため、送信要求を破棄します。

Sender.log 帯域幅調整が構成されている場合、同様のエントリが表示されます。