DBS制御フィールドを使用したメモリの管理 - Advanced SQL Engine - Teradata Database

Teradata Vantage™- データベースの管理

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Published
2021年7月
Language
日本語
Last Update
2021-09-23
dita:mapPath
ja-JP/upb1600054424724.ditamap
dita:ditavalPath
ja-JP/wrg1590696035526.ditaval
dita:id
B035-1093
Product Category
Software
Teradata Vantage

DBS制御ユーティリティは、データベース レベルのさまざまな構成パラメータを表示および変更できます。これらのいくつかのパラメータを使用すると、メモリ管理を調整できるため、システム パフォーマンスに影響を与えることができます。

DictionaryCacheSizeパフォーマンスへの影響

デフォルト値では、キャッシュされるテーブル ヘッダーとデータベース オブジェクトのアクセス権の情報が増えて、必要なI/Oの数が減ります。多数のテーブル(200以上)にアクセスするワークロードや、多数のディクショナリ シークを生成するワークロードでは、特に効果的です。

ディクショナリ キャッシュのサイズを増加させることにより、構文解析プログラムは、データ ディクショナリおよびテーブル ヘッダー情報をさらにキャッシュすることができます。

戦術的なワークロードやOnline Complex Processing(OLCP)タイプのワークロードでは、応答時間を常に短く(数秒以内)保つことが重要です。そうしたワークロードに対しては、ディクショナリ キャッシュを大きくすると(問合わせ計画がリクエスト キャッシュにキャッシュされていない場合は特に)効果的です。ディクショナリ キャッシュを大きくすると、解析や最適化に必要なディクショナリの詳細がより多く、より長くメモリに保持されるようになります。応答時間が1分を超えるような問合わせのワークロードでは、このフィールドの値を高くしてもあまり効果はありません。

IdCol Batch Sizeパフォーマンス上の影響

IdCol Batch Sizeの設定は、挿入のパフォーマンスと、識別列を持つテーブルに挿入される行の番号付けで生じる可能性のあるずれとの間のトレードオフを伴います。

大きく設定すると、ある負荷に関するひとまとまりの番号の予約でDBC.IdColへの更新が少なくなります。これにより、識別列テーブルに対して行なう一括挿入のパフォーマンスが向上する場合があります。ただし、予約された番号はメモリに保存されるため、データベースの再起動が生じると、未使用の番号が失われ、結果として識別列のナンバリングにギャップが生じます。

PPICacheThrPパフォーマンスへの影響

使用例の大半では、PPICacheThrPのデフォルト値は適切であるため、変更しないでください。ただし、この値を調整することでパフォーマンス上の問題が解決する可能性がある場合、このセクションに記載された情報を検討してください。

対応するパーティション(または列パーティション テーブルへの挿入の場合はバッファ)における現在のデータ ブロックは、それぞれのコンテキストに関連づけられています。同時にパーティションのセットを処理する場合のパフォーマンスを向上させるため、データ ブロックまたはバッファの現在のセット(コンテキストごとに1つ)は、可能な場合メモリに保存されています。メモリが不足している場合、これらのブロックまたはバッファをディスクにスワッピングする必要が生じることがあります。ただし、過度のスワッピングはシステムのパフォーマンスを低下させる可能性があります。

以下の場合は、値を大きくすると、パーティション化操作のパフォーマンスが向上することがあります。

  • 各コンテキストのデータ ブロックまたはAMPバッファは、メモリに保存できます。メモリに保存できなくなり、ディスクにスワッピングする必要が生じると、パフォーマンスが低下することがあります。
  • パーティション操作では、コンテキストの数は、空でなく除去されてもいないパーティションの数を超えることはありません。(超えた場合、各パーティションにコンテキストが設定されるためパフォーマンスが向上せず、追加のコンテキストが未使用になります)。

場合によっては、PPICacheThrPの値を初期値より大きくすると、これらのパーティション化操作を実行する各問合わせのパフォーマンスが向上することがあります。ただし、これらの問合わせが同時に多数実行される場合は、メモリ競合やメモリ不足が発生する可能性があることに注意してください。

デフォルト設定の10は安定性を重視したものであり、そのようなメモリに関する問題を避けることを目的としています。デフォルト設定が10で、システム上にAMPあたり80のAMPワーカー タスク(AWT)がある場合に、80個のリクエストに対するスライディング ウィンドウ結合など、すべてのAMPが同時に実行されるパーティション化操作であるときは、これらのパーティション化操作に使用できるFSGキャッシュの最大量は、FSGキャッシュ メモリの80%になります。最大数として80を超えるAWTが定義されている構成では、AWTの数に合わせてこの設定値を大きくします。例えば、デフォルト設定の10では、このようなシステムでAMPごとのFSGキャッシュ メモリの80%が上限として有効なままになります。

多くのサイトにとっては、このデフォルトは安定性を重視しすぎているかもしれません。80のAWTがすべて同時に実行されるパーティション化操作とは限りません。同時に発生すると予想されるパーティション化操作が多くても60である場合は、PPICacheThrPの値を15に上げることもできます。同様に、多くても40と予想される場合は、この値を20に上げることもできます。このパラメータの最適な値は、システムを同時に利用すると予想されるユーザーの最大数とそのワークロードによって決まります。あらゆるシステムに適した特定の値はありません。

また、スライディング ウィンドウ結合などの同時パーティション化操作の数が、パーティション使用率の上昇とともに増加する可能性があることも考慮してください。値を大きくすることで、現時点でメモリ競合やメモリ不足なしにパフォーマンスが向上したとしても、今後、同時に実行されるパーティション化操作が増えるにつれ、パフォーマンスが低下したり、メモリが不足する事態が発生したりする場合があります。

サイトで予想される同時パーティション化操作が80未満であり、PPICacheThrPの値を大きくすることでパフォーマンスが向上する可能性があると考えられる場合は、PPICacheThrPの複数の設定を試して、値を大きくしたPPICacheThrPの設定がサイトに最適で、ワークロードに関して安全であるかどうかを調べることができます。変更の影響を評価するために、予想される現在および将来のワークロードで、変更前と変更後のパフォーマンスやメモリ競合の程度を測定します。この値をサイトにとってほぼ安全な値に増やしても、スライディング ウィンドウ結合などのパーティション化操作のパフォーマンスが十分に改善されない場合は、スライディング ウィンドウ結合で使用されるパーティションが少なくなるように、より大きな粒度のパーティションを定義することを検討してください。

RedistBufSizeのパフォーマンス上の影響

BYNETに小さいメッセージを大量に送信するオーバーヘッドを回避するため、バッファを使用して行の再配置プロセス中に個々の行をバッチ処理します。RedistBufSizeの設定値は、ロード ユーティリティ中に使用される行再配置バッファのサイズをキロバイト単位で指定します。

デフォルトは4です(この値は4 KBに変換されます)。そして、ロード ジョブ行再配置中には、構成に含まれる各AMPごとに、そのAMPのメモリ内にこのサイズバッファが確保されます。

システムに存在するAMPが比較的少ない場合には、サイズの大きな再配置バッファはロード パフォーマンスに対して肯定的に作用します。しかし、AMPの数が多い大規模なシステムでは、サイズの大きなバッファはメモリを大量に消費することがあります。このことは、多数のロード ジョブが同時に実行される場合に特に当てはまります。

ノードあたり8 AMPのケースでは、最大48ノードまでRedistBufSizeを4 KBに維持します。システム構成が大きくなるに従って、以下のうち1つ以上を実行して適宜調整を行なってください。

  • AMPの合計数が増えるに従って、RedistBufSizeの設定を小さくする。これは、メッセージのサイズを小さくして個数を増やすことを意味します。
  • メモリを追加してシステム内の合計メモリを増やすことにより、大きめの再配置バッファを格納できるようにする。
  • FSGキャッシュのパーセントを小さくして、再配置バッファ用として使用可能な空きメモリの量を増やす。

RedistBufSizeの設定が高すぎると判定するための目安として、ロード ユーティリティの再配置が頻繁に行なわれる期間中に、使用可能な最小空きメモリが常に100 MB未満であることを確認します。また、この期間中にスワッピングが頻繁に行われている(毎秒10回超)かどうかもチェックします。これに該当する場合は、例えば4 KBから3 KBへと、RedistBufSizeに設定する増分値を下げてください。