インスタンス数の使用状況の判定
Teradata PTのほとんどのオペレータは、複数のインスタンスを使用するスケール アップによって最大限のスループットを達成できますが、逆に限度を超えてインスタンスの数が増えると、並列処理過剰になり、パフォーマンスに悪影響が生じます。 ジョブにインスタンスを追加するたびに、データ転送により多くのデータ ストリームが発生し、メモリの共有度が上昇し、セマフォも顕著化して、システム プロセスも増えます。
インスタンス数の利用状況を管理するために推奨する方法を以下に述べます。
- ひとつは、必要以上にインスタンスを作成しないことです。システム リソースの消費量が無駄に増えるだけです。 最初はインスタンス2つから始めて、必要に応じて増やしてください。
どのようなオペレータの場合も、おそらくほとんどのロード シナリオで、インスタンスは1つから4つで十分です。 ただし、ディレクトリ スキャンやLOB/JSON/XMLロードのようなシナリオでは、いずれも、より多くのプロデューサ インスタンスとコンシューマ インスタンスが必要な場合もあります。
- データをロードする際に、どこがボトルネックになるかよく判断してください。 Teradata PTでは、スケール アップにより、データI/Oとロード プロセスCPUのボトルネックを解消できます。
- TWB_STATUSプライベート ログを読み取ってください。このログには、インスタンスごとに処理したデータ量の統計が表示されます。 ジョブ パフォーマンスはCPUの処理速度の秒数とTWB_STATUSログの経過時間の秒数で評価してください。
- オペレータのインスタンスの中に活用されていないものが見つかったら、インスタンスの数を減らします。 オペレータ プライベート ログとTWB_STATUSログのいずれからも、インスタンス レベルで詳細な情報が得られます。 下記の「TWB_STATUSプライベート ログでジョブ ステータスを把握」を参照してください。
共有メモリの使用状況の判断
ジョブ内のオペレータのインスタンス数が増えれば増えるほど、データ ストリームの共有メモリの割り当て量は増えます。 デフォルトで、Teradata PTはジョブごとに共有メモリを20M割り当てます。 並列処理とスケーラビリティを強化する目的で、使用するプロデューサ インスタンスやコンシューマ インスタンスを増やす場合は、共有メモリ量を増やすしかありません。 共有メモリのサイズはtbuild -hオプションで増加します。 <Teradata Parallel Transporterリファレンス、B035-2436>の「tbuild」を参照してください。
マルチ プロデューサ インスタンスとコンシューマ インスタンスのジョブに必要な共有メモリのサイズの計算式を以下に示します。
[65000 x (Producer_count x Consumer_count) x 2] bytes + [65000 x (Producer_count + Consumer_count)] bytes
例1
プロデューサ2つとコンシューマ2つの消費共有メモリ量:
(65000 x 2 x 2 x 2) bytes + (65000 x (2 + 2)) bytes = 780000 bytes
例2
プロデューサ4つとコンシューマ4つの消費共有メモリ量:
(65000 x 4 x 4 x 2) bytes + (65000 x (4 + 4)) bytes = 2600000 bytes
バッファ モード ロードについては、後の「バッファ モード ロード用の共有メモリ サイズの判断」を参照してください。 このセクションでは、共有メモリの割り当てに関してさらに説明を続けます。
大量のファイルをディレクトリから読み取るディレクトリ スキャンの場合、DataConnectorオペレータが生成するチェックポイント レコードのサイズに対応できるよう、以下の量の共有メモリを追加してください。
1K + file_count * 580 bytes
ジョブごとのセマフォ使用状況の判断
セマフォには、並列処理環境下で、プロセスとリソース アクセスを同期させるという目的があります。 例えば、プロデューサ インスタンス(あるプロセス)からコンシューマ インスタンス(別のプロセス)に、データ ストリームでバッファ データを転送するとき、プロデューサ インスタンスとコンシューマ インスタンスが共有するデータ ストリームに対するアクセスはセマフォで同期させます。 ジョブで使用するインスタンス数が増えれば増えるほど、必要なセマフォ数も増えます。
プロデューサ インスタンスとコンシューマ インスタンスが複数あるジョブに必要なセマフォ数は次の式で計算します。
Nprocs = MAX( 25, Consumer_count + Producer_count + 2) Semaphores = 2 * (Nprocs + 3) + 5
使用場所:
Nprocsは、ジョブ プロセス数です。Teradata PTインフラストラクチャが使用するプロセスもこの値に含まれます。
バッファ モード ロード用の共有メモリ サイズの判断
Teradata PTのバッファ モードは、Teradata PTインフラストラクチャでCPU集約型の行単位の処理をせずに、スループット パフォーマンスを増強して、Producerオペレーターから Consumerオペレータにバッファ データを直接転送するロード メカニズムです。
バッファ モードに対応したプロデューサ ジョブやコンシューマ ジョブの場合、ジョブ スクリプトにはCASE/WHEN句やWHERE句などのフィルタリング条件をTeradata PT SELECT文に含めるわけにいきません。
以下の動作はバッファ モード対応の代表的な動作です。
- Teradata Databaseテーブルから行をエクスポートして、
- それをファイルに書き込み
- エクスポートした行を別のTeradata Databaseテーブルにロード
- 行を抽出
- ファイルから行を抽出してそれをTeradata Databaseテーブルにロード
- ODBCソース テーブルから行を抽出して、それをTeradata Databaseテーブルにロード
- INMODモジュールとアクセス モジュールで行を抽出して、それをTeradata Databaseテーブルにロード
バッファ モードでは、データ ストリームにおけるバッファ データの転送量を最小限に抑えられるため、複数のバッファ データが1つのデータ ストリーム メッセージに流れ込むのを阻止することもできます。 バッファ モードをブロックするときの最大の判断基準は、ブロッキング係数、すなわちメッセージ内のバッファ数です。 ブロッキング係数は、以下の式で算出します。
Buffers/Block = (MemoryPercent * TotalSharedMemory) / ((ProducerCount + (QueueDepth * ProducerCount + 1) * ConsumerCount) * BufferSize).
ここで、MemoryPercentは、データ ストリーム メッセージが占有している共有メモリの比率であり、QueueDepthはデータ ストリームに配置できる最大メッセージ数です。 ConsumerオペレータはBufferSizeを動的に設定します。
Teradata PTには、ブロッキング係数のデフォルト設定値が用意されていますが、デフォルト値はMemoryPercent (80)、TotalSharedMemory (10M)、QueueDepth (2)を想定してブロッキング係数を決定しているため、どのような条件下でも最適な値というわけではありません。 データ ストリームで転送されるバッファ数を最小限に抑えるためにブロッキング係数を増加する場合は、tbuild -hオプションで共有メモリ量をジョブ レベルで増加する必要があります。