コンテンツ配布用のコンポーネントとスレッド
この記事は、コンテンツ配布のコンポーネントとスレッドを理解するのに役立ちます。
元の製品バージョン: Configuration Manager Current Branch、Microsoft System Center 2012 Configuration Manager、Microsoft System Center 2012 R2 Configuration Manager
コンテンツ配布に使用されるコンポーネント
コンテンツ配布に使用される主要コンポーネントの簡単な一覧を次に示します。
| Name | コンポーネント名 | フレンドリ名 | 説明 |
|---|---|---|---|
| 配布マネージャー | SMS_DISTRIBUTION_MANAGER | DistMgr | コンテンツを管理し、PkgXferMgr のジョブを作成します |
| パッケージ転送マネージャー | SMS_PACKAGE_TRANSFER_MANAGER | PkgXferMgr | パッケージを配布ポイントに転送する |
| 階層マネージャー | SMS_HIERARCHY_MANAGER | Hman | サイト階層への変更を処理してレプリケートする |
| センダー | SMS_SENDER | センダー | TCP/IP ネットワーク間のサイト間通信を開始します |
| Despooler | SMS_DESPOOLER | Despooler | 親サイトまたは子サイトからの受信レプリケーション ファイルを処理する |
| スケジューラ | SMS_SCHEDULER | スケジューラ | 送信者ジョブを作成します |
| データベース通知モニター | SMS_DATABASE_NOTIFICATION_MONITOR | SmsDbMon | データベースで特定のテーブルに対する変更を監視し、それらの変更の処理を担当するコンポーネントの受信トレイにファイルを作成します |
| SMS プロバイダー | SMS プロバイダー | SMSProv | サイトの Configuration Manager データベースに読み取りと書き込みアクセスを割り当てる Windows Management Instrumentation (WMI) プロバイダー |
| SMS DP プロバイダー | SMS DP プロバイダー | SMSDPProv | DP に対するコンテンツ ライブラリ操作を管理する Windows Management Instrumentation (WMI) プロバイダー |
| SMS エージェント ホスト | SMS エージェント ホスト | CcmExec | SMS エージェント ホストは、管理ポイントやプル配布ポイントなどのサーバー側コンポーネントもホストする Configuration Manager クライアント エージェント サービスです |
| データ転送サービス | DataTransferService | DTS | データ転送サービスは、BITS 経由でファイルをダウンロードする CcmExec のコンポーネントです。 |
ディストリビューション マネージャー (DistMgr) スレッド
配布マネージャー (DistMgr) は、配布ポイント (SP) にコンテンツを配布するためのさまざまな操作を実行します。 これらの操作はさまざまな種類のスレッドによって処理されます。次の図では、既定のスレッド構成の DistMgr スレッド階層について説明します。
メイン 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ディレクトリ内の次のファイルを処理します。ファイル 説明 .STA データベースの PkgStatusテーブルのパッケージの状態を更新します。.FWD パッケージを送信するミニ ジョブを作成して、指定したパッケージを指定した宛先サイトに転送します。 .DMD オンデマンド要求を分散します。 指定したパッケージを指定した DP を対象とします。 .PUL DB の PullDPResponseテーブルのプル DP パッケージ応答を更新します。Note
このスレッドはシングル スレッドであり、これらのファイルを処理するためのスレッドを作成しません。
DP マネージャー スレッド
識別用のログ エントリ:
Starting the DP Manager thread, thread ID = 0x5D8 (1496)このスレッドは、メインの DistMgr スレッドによって開始され、サイト コントロール ファイルの変更を検出するときに、SP の削除を処理します。 適切なサイト コントロール ファイルの変更が発生すると、SMSDBMON は、このスレッドによって処理される
に DPN (DP 通知) ファイルを削除します。 DPN ファイルは DP の変更を通知するために使用されます。これには DP の削除が含まれます (
DistributionPointsテーブルの Action = 3 によって検出されます)。Note
このスレッドはシングル スレッドであり、作業を実行するためにスレッドを作成しません。
コンテンツ クリーンアップ スレッド
識別用のログ エントリ:
Starting the content cleanup thread, thread ID = 0x1604 (5636)このスレッドは、メインの DistMgr スレッドによって開始され、コンテンツのクリーンアップを実行します。 データベースから孤立したコンテンツを検出することによって、コンテンツのクリーンアップが必要かどうかを判断します。 このスレッドは、リモート DP に対して一度に削除するように指示できるコンテンツの数に対して、既定のバッチ サイズ 50 を使用します。 ただし、この値は、次のレジストリ キーを設定することでオーバーライドできます。
SMS\Components\SMS_DISTRIBUTION_MANAGER\RemoteContentCleanupBatchSizeDWORD 値は、 1 から 500 の間で指定できます。
Note
Microsoft サポート担当者に相談せずに、この値を変更しないでください。 このスレッドはシングル スレッドであり、作業を実行するためにスレッドを作成しません。
DP 証明書監視スレッド
識別のためのログ エントリ:
Starting the DP cert monitoring thread, thread ID = 0x7290 (29328)このスレッドは、メインの DistMgr スレッドによって開始されます。 このスレッドは を処理します。CER 拡張 HTTP モードが有効になっている場合、IIS で証明書バインドをファイルおよび構成します。 このモードでは、IIS で Configuration Manager で生成された証明書を使用する必要があります。
Note
このスレッドはシングル スレッドであり、作業を実行するためにスレッドを作成しません。
コンテンツ ライブラリの移動スレッド
識別のためのログ エントリ:
Starting the content library move thread, thread ID = 0x11D6C (73068)このスレッドは、メインの DistMgr スレッドによって開始され、コンテンツ ライブラリを の後の新しい場所に移動します。CML ファイルは
DistMgr.boxで削除されます。Note
このスレッドはシングル スレッドであり、作業を実行するためにスレッドを作成しません。
IIS 構成変更処理スレッド
識別のためのログ エントリ:
Starting the IIS config change processing thread, thread ID = 0x408C (16524)このスレッドは、メインの DistMgr スレッドによって開始され、IIS ファイルが
DistMgr.boxで削除された後に、標準およびプル配布ポイント用の IIS 仮想ディレクトリの構成を処理します。 このスレッドは、SMS_DISTRIBUTION_MANAGERコンポーネントのIISConfigChangeThreadLimitSite Control File (SCF) プロパティを読み取り、IIS の変更を同時に実行するために開始できるスレッドの数を決定します。IISConfigChangeThreadLimitSCF プロパティの既定値は 50 ですが、必要に応じて変更できます。 ただし、何らかの理由でこの SCF プロパティが存在しない場合は、既定値の 50 がIISConfigChangeThreadLimitに使用されます。Note
このスレッドは、DP IIS 構成の変更を実行するスレッドをさらに作成します。 各ワーカー スレッドは、特定の DP の IIS 仮想ディレクトリの構成を処理します。
DP 再割り当てスレッド
識別のためのログ エントリ:
Starting the shared DP reassignment thread, thread ID = 0x9C0C (39948)このスレッドは、メインの DistMgr スレッドによって開始され、 されたときに標準配布ポイントとプル配布ポイントの DP 再割り当てを処理します。DPU ファイルは
DistMgr.boxにドロップされます。 このスレッドは、SMS_DISTRIBUTION_MANAGERコンポーネントのSharedDPImportThreadLimitサイト コントロール ファイル (SCF) プロパティを読み取り、DP 再割り当てを同時に実行するために開始できるスレッドの数を決定します。SharedDPImportThreadLimitSCF プロパティの既定値は 50 ですが、必要に応じて変更できます。 ただし、何らかの理由でこの SCF プロパティが存在しない場合は、既定値の 50 がSharedDPImportThreadLimitに使用されます。Note
このスレッドでは、DP 再割り当てを実行するスレッドが増えます。 各ワーカー スレッドは、特定の DP の再割り当てを処理します。
アップグレード処理スレッド
識別用のログ エントリ:
Starting the DP upgrade processing thread, thread ID = 0x1968 (6504)このスレッドは、メインの DistMgr スレッドによって開始され、DP のインストールとアップグレードを標準配布ポイントとプル配布ポイントで処理します。
spGetDPsForUpgradeを呼び出して、アップグレードする必要があるDPの一覧を取得します。 このスレッドは、SMS_DISTRIBUTION_MANAGERコンポーネントのDPUpgradeThreadLimitSite Control File (SCF) プロパティを読み取り、DP インストール/アップグレードを同時に実行するために開始できるスレッドの数を決定します。DPUpgradeThreadLimitSCF プロパティの既定値は 50 ですが、必要に応じて変更できます。 ただし、何らかの理由でこの SCF プロパティが存在しない場合は、既定値の 5 がDPUpgradeThreadLimitに使用されます。Note
このスレッドは、DP のインストール/アップグレード作業を実行するために、さらに多くのスレッドを作成します。 各ワーカー スレッドは、特定の DP のインストール/アップグレードを処理します。
パッケージ処理スレッド
識別用のログ エントリ:
Started package processing thread for package 'PKGID', thread ID = 0x8E8 (2280)これらのスレッドは、メインの DistMgr スレッドによって開始されます。 パッケージ処理スレッドの数は、Software Distribution Component Configuration プロパティの Maximum number of packages thread 設定によって決まります。 各パッケージ処理スレッドは、パッケージ コンテンツのハッシュを実行し、コンテンツの圧縮コピーを作成します。
Note
すべてのパッケージ処理スレッドは同時に実行されますが、パッケージ ソースのハッシュと圧縮を担当します。 圧縮の周りにクリティカル セクションがあります。つまり、コンテンツを一度に圧縮できるスレッドは 1 つだけです。 多数の新しい大規模なパッケージが作成および配布されると、パッケージごとのスレッドは、圧縮ロックを取得する順番を待機しているチェーン内でブロックできます。
パッケージ アクション (追加/更新/削除) に応じて、各パッケージ処理スレッドも次の処理を作成します。
- DP 上のコンテンツを追加/更新するためのパッケージ転送マネージャー ジョブを作成する DP スレッド。
- DP スレッドは、コンテンツ ライブラリからコンテンツを削除するようにリモート配布ポイントに指示します。
各パッケージ処理スレッドが作成できる DP スレッドの数は、パッケージごとの Maximum スレッド数によって決まります Software Distribution Component Configuration プロパティの設定です。
Note
パッケージ処理スレッドはマルチスレッドであり、各パッケージ処理スレッドは、作業を実行するためにより多くのスレッドを作成します。 各ワーカー スレッドは、SP の追加/更新/削除操作を処理します。
Distribution Manager スレッドの構成
すべての Configuration Manager サイト (中央管理サイトを含む) では、配布ポイント (SP) にコンテンツを配布するために使用できるスレッドの数を構成できます。 この構成は各サイトに固有であり、Sites ノードの下にあるサイトを右クリックし、[サイト コンポーネントの構成>ソフトウェア配布選択することでアクセスできます。 既定の構成を次に示します。
ほとんどの場合、パッケージごとの Maximum の数 および Maximum スレッド 設定にのみ関係します。
- パッケージの最大数: ConfigMgr が同時に SP に送信できるパッケージの最大数を指定します。 指定する値は、 1 から 50 の間である必要があります。
- パッケージあたりの最大スレッド数: 配布中に各パッケージに割り当てられるスレッドの最大数を指定します。 指定する値は、 1 から 999 の間である必要があります。
Maximum number of packages=3 および Maximum threads per package=5 の既定の構成は、3x5 とも呼ばれます。 これは、ワークフローでスレッド構成が示されることが多い方法です。
これが本当に意味するもの
ディストリビューション マネージャー (DistMgr) への影響
3x5 の既定のスレッド構成では、DistMgr は 3 つのパッケージを同時に処理し、各パッケージに最大 5 つのスレッドを使用できるため、作業を実行するために最大 15 個のスレッドを使用できます。 5 つ以上のDPに配布する必要があるパッケージが 3 つ以上あると仮定すると、これがどのように分解されるかを次に示します。
個々のパッケージを処理するために、パッケージ処理スレッドがメインの DistMgr スレッドによって生成されます。 このパッケージ処理スレッドは、 Maximum 個のパッケージ数 設定から 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 スレッド
標準の SP の場合、PkgXferMgr スレッドはコンテンツを送信する実際の処理を実行するため、これらのスレッドの有効期間はパッケージのサイズによって異なります。 より大きなパッケージの場合、パッケージのサイズとネットワーク速度によっては、これらのスレッドに長い時間がかかる場合があります。 これらのスレッドの完了には時間がかかる場合がありますが、DistMgr スレッドの有効期間は大幅に短くなります。つまり、DistMgr は PkgXferMgr の多数のジョブをキューに入れることができ、キューにジョブのバックログが作成されます。
プル DP の場合、PkgXferMgr スレッドはプル DP に通知し、プル DP にコンテンツのダウンロードを求めます。 その結果、プル DPs の PkgXferMgr スレッドの有効期間は短くなります。 PkgXferMgr は、(構成されたポーリング間隔に基づいて) プル DP ポーリングを実行する別のスレッドを開始して、ジョブの進行状況を確認します。 ただし、これは簡単な操作でもあり、これらのスレッドの有効期間も短くなります。
適切な値の選択
これらの設定に適切な値を決定するには、まず Configuration Manager 階層を理解する必要があります。 次の架空の Configuration Manager 環境について考えてみましょう。
- 中央管理サイト: CS1
- プライマリ サイト: PS1
- PS1 に報告する通常の配布ポイントの数: 200
- パッケージの合計数: 1000
この環境では、既定のスレッド構成 (3x5) は、新しいパッケージを 200 すべてのDPに配布する必要がある場合、一度に 5 つのDPのみを処理することを意味します。 DP スレッドが終了すると、別の DP スレッドが生成され、すべての DP が処理されるまでプロセスが続行されます。 このプロセスでは、200 個すべてのDPをループ処理するのに時間がかかります。
これを最適化するには、まずいくつかの質問をする必要があります。
- 平均で同時に追加/更新/配布されるパッケージの数を予測していますか?
- サイトにいくつのDPがありますか? サイト サーバーとこれらの IP の間のネットワーク構成はどのように行われますか。
最初の質問に対する答えが5であると仮定します 2 番目の質問に対する答えは 200 です優れたネットワーク接続を使用して、理論的にはパッケージの最大数 を 5 に設定しパッケージあたりの最大スレッド数を 200 に200 DPs すべてに最大 5 個のパッケージを同時に送信できます。 ただし、平均負荷を超える負荷がある場合は、最大 1,000 個のスレッド (多くのスレッド) を作成できることを意味します。 通常、より多くのスレッドが適していますが、実行される作業はハードウェアとネットワークの構成にも依存するため、常にではありません。 スレッドが多すぎると、ボトルネックが発生し、改善される代わりに処理速度が低下することがあります。
これらの設定を構成する際に覚えておくべき最も重要なことは、バランスを することです。 上記の例では、適切なオプションとして、スレッド構成を 5x100 (またはハードウェア/ネットワークに応じて 5x50 ) に設定します。これにより、Configuration Manager は 5 つの異なるパッケージに対して最大 100 DP を同時に処理できます。 これらの設定では、高負荷時に生成できるスレッドの最大数は 500 を超えなくなります。
Note
一般的なガイドラインとして、スレッドの合計数が 750 を超えないようにすることをお勧めします。 つまり、スレッド構成を 3x250、 5x150、 10x75 に設定できます。
同じ階層では、環境内に新しい DP を導入し、1000 個のパッケージをすべて DP に配布する必要がある状況が発生する可能性があります。 この場合、 5x100 のスレッド構成は、一度に 5 個のパッケージしか処理できず、1000 パッケージの処理にはかなりの時間がかかるため、有効になりません。 このシナリオでは、次のいずれかを選択できます。
- スレッド構成を一時的に 50x10 現在の要件に適したものに設定しますが、長い目で見ると 200DP があると考えると適切なオプションではありません。
- スレッド構成を 20x25 のように完全に設定すると、バランスが大幅に向上し、多数のパッケージを少数のDPに移動する必要があるシナリオや、少数のパッケージが多数のDPにアクセスする必要があるシナリオでも同様のパフォーマンスが提供されます。
重要
スレッド構成の値に関する一連の推奨事項はありません。環境ごとに異なり、環境と要件を理解した後に設定する必要があります。 常にバランスを を見つめてください!
送信者スレッドの構成
各 Configuration Manager サイト (中央管理サイトとセカンダリ サイトを含む) には、1 つの送信者があります。 センダーは、あるサイトから転送先サイトへのネットワーク接続を管理します。同時に複数のサイトへの接続を確立することもできます。 サイトに接続するために、センダーはサイトへのファイル レプリケーション ルートを使用し、ネットワーク接続の確立に使用するアカウントを識別します。 送信者はこのアカウントを使用して、宛先サイトの SMS_SITE 共有にデータを書き込みます。
既定では、送信者は複数の同時実行スレッドを使用して、宛先サイトにデータを書き込みます。 各同時実行スレッドは、異なるファイル ベースのオブジェクトを転送先サイトに転送できます。 既定では、送信者はオブジェクトの送信を開始すると、オブジェクト全体が送信されるまで、そのオブジェクトのデータ ブロックを書き込み続けます。
すべての Configuration Manager サイトでは、Sender コンポーネントが他のサイトに同時にデータを送信するために使用できるスレッドの数を構成できます。 この構成は各サイトに固有であり、Sites ノードの Site Properties から Sender タブを選択してアクセスできます。既定の構成を次に示します。
![ConfigMgr プライマリ サイト プロパティ ウィンドウの [送信者] タブの情報を示すスクリーンショット。](media/components-and-threads/configmgr-primary-site.png)
すべてのサイト: この送信者に対して許可される同時通信の最大数。 既定値は 5 です。 これらの通信は、 Per site で指定された最大値によって制限される場合を除き、異なるサイトまたは同じサイトに対してすべて宛てにすることができます。
サイトごとの: 1 つの宛先サイトに対して許可される同時通信の最大数。 既定値は 3 です。
Note
他のサイトと通信するときに使用する同時送信スレッドの合計数を構成する場合、送信スレッドの合計数は、サイトごとの設定用に構成されたスレッドよりも大きい数として構成する必要があります。 送信スレッドの合計数が、サイトごとに使用するように構成された数と同じで、受信サイトが使用できない場合、使用できないサイトとの通信を試みるときにすべての送信スレッドが使用され、他のサイトとのサイト間通信を妨げる可能性があります。
この意味
[すべてのサイト で指定された値 は、Sender が他のサイトに同時にデータを送信するために使用できるスレッドの合計数を定義します。 すべてのサイトのスレッドの合計数のうち、任意の 1 つの宛先サイトにデータを送信するために使用できるスレッドの最大数Per siteに割り当てることができます。 既定では、各サイトは 5 つの同時実行スレッドを使用するように構成され、1 つの宛先サイトにデータを送信するときに 3 つのスレッドを使用できます。 この数を増やすと、Configuration Manager で同時により多くのファイルを転送できるようにすることで、サイト間のデータのスループットを向上させることができます。 ただし、この数を増やすと、サイト間で必要なネットワーク帯域幅も大きくなります。
適切な値を選択する
これらの設定に適切な値を決定するには、まず Configuration Manager 階層を理解する必要があります。 次の架空の Configuration Manager 環境について考えてみましょう。
- 中央管理サイト: CS1
- プライマリ サイト: PS1
- プライマリ サイト: PS2
- プライマリ サイト: PS3
- プライマリ サイト: PS4
この環境では、既定の Sender スレッド構成では、合計 5 つのスレッドを使用できます。 これらの 5 つのスレッドのうち、3 つは、4 つの宛先プライマリ サイトのいずれかに使用できます。 管理者がこれらのサイトすべてに 3 を送信した場合、送信者はこれらのサイトの 1 つに 3 つのスレッド (PS1 など) を使用し、残りのサイトには 2 つのスレッドのみを残す可能性があります。 残りの 2 つのスレッドのうち、送信者は PS2 に 1 を使用し、もう 1 つを PS3 に使用して、5 つの許可されたスレッドすべてを使用して、PS4 に同時にデータを送信する余地を残さない場合があります。 この時点で、Sender は既存の 5 つのスレッドのいずれかが完了するのを待ってから、さらにデータを送信する必要があります。 既存のスレッドが完了すると、Sender は別のスレッドを使用して PS2/PS3/PS4 サイトにさらにデータを送信できるようになります。
Sender が通信するサイトごとに 10 個のスレッドを確保することをお勧めします。 この場合、CS1 サイトは他の 4 つのサイトと通信できます。つまり、4 つのサイトの Per サイト 値が 10 の場合、 すべてのサイト 値を 40 に設定する必要があります。
Note
これは一般的な推奨事項であり、サイトが他のサイトに同時に送信する必要があるパッケージの数に応じて、これらの値をさらに調整する必要がある場合があります。
帯域幅の制御とスレッド
Configuration Manager では、スケジュールを構成し、リモート配布ポイントおよびサイトのファイル レプリケーション ルートに対して特定の調整設定を設定できます。 リモート配布ポイントへのスケジュール設定と調整のコントロールは、標準の送信者アドレスの設定と似ていますが、この場合、設定は Package Transfer Manager というコンポーネントによって使用されます。
Package Transfer Manager コンポーネント ( Site Server - >DP の場合、調整設定はサイト サーバー上にない標準配布ポイントのプロパティで構成されます。
Sender コンポーネント ( Site Server<->Site Server の場合)、調整設定は、ファイル レプリケーション ルートのプロパティで Hierarchy Configuration>File Replication で構成されます。
Note
時刻の設定は、配布ポイントではなく、送信サイトからのタイム ゾーンに基づいています。
スケジュール オプション
データを制限するには、期間を選択し、次のいずれかの設定を選択して可用性を確保します。
[すべての優先順位で開く: Configuration Manager が制限なしで配布ポイントにデータを送信することを指定します。
[中と高の優先度を許可する: Configuration Manager が配布ポイントに送信するのは、中と高のデータだけであることを指定します。
高優先度のみを許可する: Configuration Manager が配布ポイントに送信するのは優先度の高いデータだけであることを指定します。
Closed: Configuration Manager が配布ポイントにデータを送信しないことを指定します。
優先順位によってデータを制限したり、選択した期間の接続を閉じたりすることができます。
レート制限オプション
これは、配布ポイントにコンテンツを転送するときに使用されるネットワーク帯域幅を制御するレート制限を構成するために使用されます。 次のオプションから選択できます。
- この宛先に送信する場合は無制限: Configuration Manager がレート制限のないコンテンツを配布ポイントに送信することを指定します。
- パルス モード: 配布ポイントに送信されるデータ ブロックのサイズを指定します。 また、データ ブロックを送信する間隔を指定することもできます。 このオプションは、低帯域幅のネットワーク接続を介して配布ポイントにデータを送信する必要がある場合に使用します。 たとえば、リンクの速度や特定の時点での使用状況に関係なく、5 秒ごとに 1 KB のデータを送信する制約がある場合があります。
- 時間単位で指定された最大転送レートに制限する: 構成した時間の割合のみを使用して、サイトが配布ポイントにデータを送信するように、この設定を指定します。 このオプションを使用すると、Configuration Manager は使用可能なネットワーク帯域幅を識別せず、代わりにデータを送信できる時間を時間のスライスに分割します。 その後、データは短時間送信され、その後にデータが送信されない時間のブロックが続きます。 たとえば、最大レートが 50% に設定されている場合、Configuration Manager は一定期間データを送信し、その後にデータが送信されない場合は同じ期間にわたってデータを送信します。 データの実際の量やデータ ブロックのサイズは考慮されません。 代わりに、どれだけの時間データを送信するかが管理されます。
これらの設定の詳細については、「 Configuration Manager でのコンテンツ管理の構成」を参照してください。
これが Sender スレッドと PkgXferMgr スレッドに与える影響
サイトに対して帯域幅制御が有効になっている場合、送信側コンポーネントはサイトの Sender スレッド構成を無視し、そのサイトに対して 1 つのスレッドのみを使用します。 同様に、DP に対して帯域幅制御が有効になっている場合、PkgXferMgr はスレッド構成を無視し、DP に対して 1 つのスレッドのみを使用します。
Note
これは、[ 使用可能な帯域幅の制限 (%) ] を 100%に設定した場合も当てはまります。
帯域幅制御が有効な場合、 PkgXferMgr.log は次のいずれかの行をログに記録します。
スケジューリング:
~DPNAME.CONTOSO.COM へのアドレスは現在帯域幅の制御下にあるため、1 つの接続のみが許可され、プールへの送信要求が返されます。
パルス モード:
~DPNAME.CONTOSO.COM へのアドレスは現在パルスモードであるため、1つの接続のみが許可されています。
~パルスモードで許可される接続は 1 つだけであるため、送信要求を破棄します。
帯域幅調整が構成されている場合、Sender.log 同様のエントリが表示されます。