空きメモリは、以下のものに使用されます。
- 管理プログラム(プログラム テキストとデータ、メッセージ バッファ、カーネル リソース、およびメモリを必要とするFastLoadなどの他のアプリケーション)。
- 非ファイル システム アクティビティ用のvproc。以下に例をあげます。
アクティビティ 説明 AWT 特定のAMPタスクで使用されるAMP論理の一部 構文解析プログラム タスク SQLの構文解析を担当するPE論理の一部 ディスパッチャ タスク 作業のディスパッチを担当するPE論理の一部 スクラッチ セグメント 一時作業領域 メッセージ vproc間の通信 ディクショナリ キャッシュ 構文解析のためのディクショナリ ステップ リクエスト キャッシュ ステップの実行時に使用される一時領域
利用可能な空きメモリの確認について
ResNodeマクロは、空きメモリに関する限定情報を表示します。ResNodeレポートには、Free Mem%列が示されます。これは、未使用メモリのパーセンテージを示します。
利用可能な空きメモリが少ない場合の調整
- ctlを使用してFSGキャッシュのパーセントを下げることにより、空きメモリに利用できるメモリを増やす。システムでFSGキャッシュのために多くのメモリを取りすぎて、OSでそのメモリが使用されない場合、空きメモリは無駄になります。
- 再配置が頻繁に行なわれる期間に使用可能な空きメモリが100 MBを下回る場合は、DBS制御レコードのRedistBufSizeフィールドの値を小さくします(<Teradata Vantage™ - データベース ユーティリティ、B035-1102>の「RedistBufSize」を参照)。
保証される最小非FSGキャッシュ サイズ
Teradataは、AMPごとの最小非FSGキャッシュ サイズについて以下の構成ガイドラインを推奨しています。
- すべてのノードが起動している場合はAMPごとに135 MB
- クリーク内で1つのノードが停止している場合はAMPごとに112 MB
- クリーク内で許容されている最大数のノードが停止している場合はAMPごとに90 MB
上記の構成ガイドラインは、メモリが圧迫されている場合のメモリのスワップとページング、メモリの枯渇、CPU不足に関する性能の問題を回避するのに役立ちます。
性能管理上の推奨事項
多数のサイトは、共有メモリについてで計算されたデフォルトよりも多くの空きメモリを必要とする可能性があります。FSGキャッシュ パーセントを100%未満に設定することで、AMPごとにメモリを空きメモリに追加することを推奨します。
以下の計算を使用する必要があります。
FSGキャッシュ パーセント= (FSGキャッシュ - 39 MB * AMP数) / FSGキャッシュ
| メモリ サイズ(GB) | 基盤ドライバとAMP10個/PE Vproc 2個のメモリ | FSGキャッシュ(MB) | AMP Vproc 1個につき58 MBを差し引いた容量 | FSGキャッシュ パーセント |
|---|---|---|---|---|
| 6.0 | 1854 | 4290 | 3822 | 89% |
| 8.0 | 1914 | 6278 | 5810 | 92% |
大規模な構成の場合、入出力ボトルネックまたは過度のメモリ スワッピングを解決するために、以下のオプションのうち1つ以上を考慮する必要があります。
- 問合わせ処理の際の計算を減らすために、集約結合インデックスの使用を検討する。
- 例えば4 KBから3 KBへと、RedistBufSizeに設定する増分値を下げる。
- 合計メモリ サイズを考慮に入れて、FSGキャッシュ パーセントを100%未満に設定する。
- 行の再配置が減るようにアプリケーションを変更することを検討する。
- サポート担当者に内部再配置バッファ サイズを減らすことを依頼する。 これは内部調整パラメータであり、ユーザーが調整できるRedistBufSizeではない。
起こりうる問題
大規模な構成のアプリケーションでBYNETを介して多くのメッセージが生成されるときに、すべてのノードに関係する行の再配置が並行して行なわれると、問題が起こる可能性があります。
以下のものは問題ではありません。
- 行の重複
- 解答セットの併合
行の再配置におけるメモリ要件
BYNETに小さいメッセージを大量に送信するオーバーヘッドを回避するため、バッファを使用して行の再配置プロセス中に個々の行をバッチ処理します。ロード ユーティリティと問合わせには、いずれもこのような再配置が含まれていますが、この外部バッファに対するアプローチは異なります。
問合わせ処理での行の再配置では、システムの各ノードのAMPに対して、別個の単一バッファが使用されます。したがって、1つのノードで再配置に必要なメモリの量は、システムの拡大につれて増加します。
DBC 制御レコードのフィールド、「RedistBufSize」フィールドは、再分散バッファのサイズを管理します。RedistBufSizeのパフォーマンス上の影響を参照してください。
- デフォルトの問合わせ再配置バッファ サイズ = ターゲット ノードにつき32 KB
- 送信AMPごとの合計メモリ = 32 KB * システムのノードの数
- ノードごとに8つのAMPがある場合、ノードごとに必要な合計メモリ = 8 * 32 KB * システムのノードの数
再配置バッファのサイズ変更
以下の例では、8ノード構成のシステムで、ノードごとに8つのAMPがあるケースについて、再配置バッファのサイズ変更を行なう場合の計算が示されています(システムで予約されるのはAMPごとに32 MBです)。
- 単一ノード要件(単一ユーザー)= 32 KB * 8 = 256 KB
- マルチユーザー(20人の並行ユーザー)= 20 * 256 KB = 5 MB (32 MBのデフォルトより少ない)
以下の例では、96ノード構成のシステムで、ノードごとに8つのAMPがあるケースの計算が示されています。この例では、要件はシステム デフォルトを上回っています。
- 単一ノード要件(単一ユーザー)= 32 KB * 96 = 3072 KB (3 MB)
- マルチユーザー(20人の並行ユーザー)= 20 * 3072 KB = 64 MB (AMPにつき32 MBをはるかに超える)
大量の再配置処理が行なわれると、性能に対して次のような影響が見られます。
- 過度のメモリ ページング/スワッピング
- BYNETの入出力で生じうる入出力ボトルネック