Informatica でのパフォーマンス チューニング: 完全なチュートリアル
デビッドカーター
⚡ スマートサマリー
Informaticaのパフォーマンスチューニングでは、セッション内で最も遅いリンクを、ターゲットからソース、マップへと遡って、一度に1つのレイヤーずつ削除します。pingセッション、そして最後にオペレーティングシステム。
Informaticaにおけるパフォーマンスチューニングとは何ですか？
Informaticaにおけるパフォーマンスチューニングとは、セッションの実行速度を制限しているコンポーネントを特定し、その制限を取り除き、次に最も遅くなるコンポーネントに対して同じ手順を繰り返すことです。セッションの速度は常に最も遅いレイヤーによって決まるため、そもそも問題の原因ではなかった変換処理をチューニングしても、目に見える効果は得られません。
Informaticaは、ボトルネックが発生する可能性のある5つの箇所を特定し、それらを一定の順序で確認することを推奨しています。
| 注文 | 層 | 典型的な原因 |
| 1 | Target | 書き込み速度が遅い、チェックポイント間隔が短い、データベースのネットワークパケットサイズが小さい |
| 2 | ソース | クエリが遅い、インデックスが欠落している、不要な列が読み込まれている |
| 3 | 地図ping | 高コストまたは不適切な場所に配置された変換、過大なキャッシュ |
| 4 | セッション | Buffer メモリ、コミット間隔、パーティショニング、ロードタイプ |
| 5 | システム | 統合サービスマシンにおけるCPU飽和、I/O待機、ページング |
この順序は意図的なものです。行を十分に速く吸収できないターゲットは、上流のすべてのレイヤーを遅く見せるため、最初にチェックされます。完全なメソッドは、 PowerCenter パフォーマンスチューニングガイド.
パフォーマンスのボトルネックを特定する方法
どの層が遅いかを推測するよりも、実際に測定する方がはるかに効率的です。上記5つの層を網羅する4つの手法をご紹介します。
- テストセッションを実行します。 コピーを構成する セッション フラットファイルターゲットに書き込みます。セッションの速度が著しく向上すれば、ターゲットがボトルネックです。同じ手法の鏡像として、フラットファイルソースから読み込むことで、ソースのボトルネックを特定できます。
- スレッド統計を分析する。 データ変換マネージャは、リーダー スレッド、1 つ以上の変換スレッド、およびライター スレッドを実行します。セッション ログで最もビジー時間が高いスレッドは、処理対象のレイヤーを直接指しています。ソースの場合はリーダー、マップの場合は変換スレッドです。pingターゲット向けのライター。
- パフォーマンスの詳細を分析する。 セッションでパフォーマンスデータ収集を有効にして、カウンターを読み取ります。エラー行が多い場合、またはルックアップキャッシュに多数の行がある場合は、マップに問題があることを示しています。ping これはデータベースの問題というより、むしろ問題だ。
- システムを監視する。 OperaCPU使用率、I/O待機、ページングを表示するシステムツールと、 ワークフローモニター リソースビューを見ると、単に処理能力が不足しているマシンであることがわかる。
責任のあるレイヤーがわかれば、次のセクションの変換レベルのアドバイスを適用する価値が出てきます。セクションは、データが入力される時点からパイプラインの順に並んでいます。 地図ping 集約される段階まで。
ソース修飾子の変換
ソース修飾子が読み取らない行は、他の変換処理が不要な行であり、マップ全体で最もコストの低い場所となる。ping 時間を節約するために。
- 必要な列のみをソースから取得します。 ほとんどの場合、ソース テーブルのすべての列が必要なわけではないため、不要な列を削除して必要なフィールドのみを取得します。
- 内部で order by 句を使用することを避けてください ソース修飾子 SQLの上書き。ORDER BY句は追加の処理を必要とするため、これを避けることでパフォーマンスを向上させることができます。
フィルター変換
フィルタリングはパイプラインの1ステップ後の段階で同じ原則に従います。マップが不要な行を最も早い段階で破棄します。ping 彼らを特定するのに十分な情報を持っている。
- フィルタ変換 マップ内でできるだけ早くping不要なデータをマップの早い段階で破棄できる場合pingそうすれば、スループットが向上するだろう。
- ソース修飾子を使用してデータをフィルタリングします。フィルタ変換を使用する代わりに、ソース修飾子のSQLオーバーライドを使用してレコードをフィルタリングすることもできます。
ジョイナーの変換
参加は、典型的なマップにおける最初の本格的な高額な操作です。pingなぜなら、詳細行を照合する前に、マスターソースをキャッシュする必要があるからです。
- 可能であれば、データベースで結合を実行することを常に優先してください。データベースでの結合は、Informaticaで作成された結合よりも高速です。 ジョイナーの変革.
- 結合中に実行されるディスク I/O を減らすため、可能であれば結合前にデータを並べ替えます。
- 行数の少ないテーブルをマスターテーブルとして作成してください。
3つ目のポイントは、最も見落とされがちな点です。インテグレーションサービスはマスターソースをキャッシュするため、より小さなテーブルをマスターとして指定することで、キャッシュのサイズを小さく保つことができます。
ルックアップ変換
検索は、行ごとにデータベースに一度クエリを実行するか、メモリ内にキャッシュを構築するかのいずれかの方法で行うが、どちらの方法も、より小さく、より適切にインデックス化された検索元の方が有利となる。
- 列のインデックスを作成します ルックアップテーブル これは検索条件で使用されます。一致するデータを検索するために検索テーブルがクエリされるため、インデックスを追加するとパフォーマンスが向上します。
- 可能であれば、参照変換を使用する代わりに、データベースで結合を使用してください。 データベースの結合が高速になると、パフォーマンスが向上します。
- ルックアップテーブルから不要な列を削除し、必要な列だけを残します。 これにより、データベースから追加の列をフェッチするオーバーヘッドが削減されます。
アグリゲーターの変換
An アグリゲーター データは行をグループ化する間キャッシュに保持されるため、キャッシュに到達するデータ量を減らすことで、必要なキャッシュ容量も減少します。
- データを集計する前にフィルタリングしてください。マップでフィルタ変換を使用している場合pingそして、集計器を使用する前にデータをフィルタリングすることで、不要な集計操作を減らすことができます。
- アグリゲーター変換で使用するポート数を制限してください。これにより、アグリゲーター変換がキャッシュ内に保存するデータ量を削減できます。
Informaticaにおけるセッションレベルのチューニング
地図がping それ自体はクリーンな処理であり、残りのパフォーマンス向上はセッションプロパティによるものです。これらの設定は、メモリ使用量と速度をトレードオフするものがいくつかあるため、変更するたびに時間を計測しながら、一度に1つずつ変更することをお勧めします。
| Setting | 制御するもの | いつ変更するか |
| DTMバッファサイズ | 統合サービスがソースデータブロックとターゲットデータブロックに割り当てる合計メモリ量 | セッションが多数のパーティション、ソース、またはターゲットを処理する場合に増加します。 |
| Buffer ブロックサイズ | 個々のメモリブロックのサイズ | 行数が異常に多い場合は増加、物理メモリが限られている場合は減少 |
| コミット間隔 | コミットが発行される前に書き込まれる行数 | 書き込みスレッドがデータベースのチェックポイントを待機しているときに、この値を上げてください。 |
| プッシュダウン最適化 | 地図のどの部分ping ロジックはSQLに変換され、データベースによって実行されます。 | ソースとターゲットが同じ強力なデータベース上にある場合に使用します。 |
Buffer メモリは推測ではなく、文書化された計算に基づいて割り当てられます。統合サービスは、ソースパーティションとターゲットパーティションそれぞれに少なくとも2つのブロックを割り当てるため、セッションバッファブロックの数は（ソースの総数＋ターゲットの総数）×2となり、DTMバッファサイズはそのブロック数にバッファブロックサイズを乗じて0.9で割った値となります。
プッシュダウン最適化には注意が必要です。データベースが統合サービスマシンよりも実際に高速で、変換ロジックが表現できる場合にのみ有効です。 SQL翻訳できないロジックはセッション内に残るため、期待される効果よりも小さくなることがよくあります。デフォルトで有効にするのではなく、有効にする前と後で効果を測定してください。
