インスタンス数の使用状況の判定
Teradata PTのほとんどのオペレータは、複数のインスタンスを使用するスケール アップによって最大限のスループットを達成できますが、逆に限度を超えてインスタンスの数が増えると、並列処理過剰になり、パフォーマンスに悪影響が生じます。 ジョブにインスタンスを追加するたびに、データ転送により多くのデータ ストリームが発生し、メモリの共有度が上昇し、セマフォも顕著化して、システム プロセスも増えます。
- 必要以上の数のインスタンスを作成しないでください。システム リソースの消費量が無駄に増えるだけです。最初はインスタンス2つから始めて、必要に応じて増やします。
どのようなオペレータの場合も、おそらくほとんどのロード シナリオで、インスタンスは1つから4つで十分です。 ただし、ディレクトリ スキャンやLOB/JSON/XMLロードのようなシナリオでは、いずれも、より多くのプロデューサ インスタンスとコンシューマ インスタンスが必要な場合もあります。
- データをロードする際に、どこがボトルネックになるかよく判断してください。 Teradata PTでは、スケール アップにより、データI/Oとロード プロセスCPUのボトルネックを解消できます。
- TWB_STATUSプライベート ログを読み取ってください。このログには、インスタンスごとに処理したデータ量の統計が表示されます。 ジョブ パフォーマンスはCPUの処理速度の秒数とTWB_STATUSログの経過時間の秒数で評価してください。
- 利用率が低いオペレータのインスタンスが見つかったら、インスタンスの数を減らします。オペレータのプライベート ログとTWB_STATUSログのどちらでもインスタンス レベルでの詳細情報が提供されます。<Teradata PTジョブの管理とモニター>の「TWB_STATUSプライベート ログでジョブ ステータスを把握」を参照してください。
共有メモリの使用状況の判断
ジョブ内にオペレータのインスタンスが多いほど、データ ストリームに割り当てる必要がある共有メモリが増えます。TPTは、スクリプト内のすべての情報(インスタンスの総数やスキーマのサイズ)に基づいて、そのジョブに最適な共有メモリ量を決定するように最善を尽くします。
- スクリプトでDataConnectorプロデューサ(ファイル リーダーなど)が指定されていない場合の式。
TotalSharedMemorySize = ( ( ProducerCount + ConsumerCount x (ProducerCount x QueueDepth + 1) ) x MaxRowSizeInSchema ) x 1.3
- スクリプトでDataConnectorプロデューサ(ファイル リーダーなど)が指定されている場合の式。
TotalSharedMemorySize = ( ( ( ProducerCount + ConsumerCount x (ProducerCount x QueueDepth + 1) ) x MaxRowSizeInSchema ) x 1.3 ) + (3MB x DCProducerInstanceCount)
説明- QueueDepthは現時点では2に設定されています。
- MaxRowSizeInSchemaは、ジョブのスキーマの最大サイズです。
MaxRowSizeInSchemaが1MB未満である場合は、MaxRowSizeInSchemaの最小サイズとして1MBが使用されます。
例1
Exportオペレータの1つのインスタンスと2つのコンシューマ インスタンスで使用される共有メモリ量。
((1 + 1) * ((1 * 2) + 1)) * 1048576) * 1.3 = ~8,178,893 bytes (~8MB)
例2
Exportオペレータの2つのインスタンスと2つのコンシューマ インスタンスで使用される共有メモリ量。
((2 + 2) * ((2 * 2) + 1)) * 1048576) * 1.3 = ~27,262,976 bytes (~26MB)
例3
DCプロデューサの1つのインスタンスと1つのコンシューマ インスタンスで使用される共有メモリ量。
(((1 + 1) * ((1 * 2) + 1)) * 1048576) * 1.3) + (3MB * 1) = ~11,324,621 bytes (~11MB)
ディレクトリ スキャンに関する考慮事項
ディレクトリ スキャン機能では、DataConnectorオペレータは、処理するすべてのファイルに関する情報を、ジョブの実行のさまざまな時点でチェックポイント レコードに格納する必要があります。ディレクトリから非常に多くのファイル(500個超)を読み取るディレクトリ スキャンでは、追加の共有メモリの割り当てが必要になることがあります。ベスト プラクティスとして、必要となる共有メモリ量を決定し、「共有メモリの使用状況の判断」で決定された計算にその追加の共有メモリ量を追加します。
チェックポイント レコードに必要な共有メモリの量を決定するには、次の式を使用します。
((12K * FileCount) + 12K) * 2 bytes
tbuildの-hオプションを使用すると、共有メモリ サイズを増やすことができます。<Teradata® Parallel Transporterリファレンス, B035-2436>の「tbuild」を参照してください。
例
((12K * 1000) + 12K) * 2 = ~24MB bytes of extra shared memory
ジョブごとのセマフォ使用状況の判断
セマフォには、並列処理環境下で、プロセスとリソース アクセスを同期させるという目的があります。 例えば、プロデューサ インスタンス(あるプロセス)からコンシューマ インスタンス(別のプロセス)に、データ ストリームでバッファ データを転送するとき、プロデューサ インスタンスとコンシューマ インスタンスが共有するデータ ストリームに対するアクセスはセマフォで同期させます。 ジョブで使用するインスタンス数が増えれば増えるほど、必要なセマフォ数も増えます。
プロデューサとコンシューマの複数のインスタンスがあるジョブで必要となるセマフォ数を計算するには、次の式を使用します。
Nprocs = MAX( 25, Consumer_count + Producer_count + 2)
Semaphores = 2 * (Nprocs + 3) + 5
説明:
Nprocsは、ジョブ プロセス数です。Teradata PTインフラストラクチャが使用するプロセスもこの値に含まれます。