重要: この記事を読む前に「免責事項」をお読みください。

はじめに

メモリー・チューナーを有効にすると、利用可能なメモリー・リソースが、いくつかのメモリー・コンシューマー (ソート・ヒープやパッケージ・キャッシュ、ロック・リスト、バッファー・プールなど) に動的に分配されます。この機能では、少しずつメモリー構成の修正を繰り返すことによって、全体としてのシステム・パフォーマンスを改善するという目標を達成しようとします。

STMM が行ったすべての変更は、db2diag.log ファイルと STMM ログ・ファイルという 2 つの場所にログとして記録されます。以下のセクションでは、この両方のファイルの内容について、また STMM が行った変更を db2diag ツールと parseStmmLogFile.pl ツールを使って監視するための方法について説明します。

上に戻る

STMM の動作

STMM は、指定されたヒープにメモリーを追加した場合の効果を予測する新しい内部メトリクスを利用して判断を下します。これらのメトリクスを STMM の高度なチューニング・アルゴリズムと組み合わせると、ほとんどの場合に、箱から出したばかりの状態の構成から最適に近いメモリー使用状態にまで、1 時間以内でシステムをチューニングすることができます。しかし STMM がシステムをチューニングする際には何百という判断がなされており、それぞれの判断に応じて構成パラメーターやバッファー・プールのサイズなどが変更されます。こうした変更のうち、構成ファイルに反映されるのは最も新しく行われた変更のみであるため、構成パラメーターやバッファー・プールの値の履歴を判断するためには db2diag.log ファイルと STMM log ファイルを調べる必要があります。

上に戻る

db2diag.log ファイルへの変更を監視する

db2diag.log ファイルは STMM が行った各構成変更に関する簡単な情報についてのリポジトリーです。このファイルの中を見ると、構成の変更を示すレコードがあることがわかります (リスト 1)。

2006-10-17-19.10.00.912218-240 I408210A457        LEVEL: Event
PID     : 946302               TID  : 1           PROC : db2stmm (MYDB1) 1
INSTANCE: ewhhr                NODE : 001         DB   : MYDB1
APPHDL  : 1-52                 APPID: *N1.cgarciaa.060809150048
AUTHID  : CGARCIAA
FUNCTION: DB2 UDB, config/install, sqlfLogUpdateCfgParam, probe:20
CHANGE  : STMM CFG DB DEWHR000: "Sheapthres_shr" From: "109306" <automatic>
                                                 To: "105115" <automatic>

上記のレコードでは構成の変更が「STMM CFG」で開始されており、この変更がユーザー操作による構成の更新ではなく STMM によって行われたことを示していることに注意してください。また、バッファー・プールの変更を示すレコードもあることがわかります (リスト 2)。

2006-10-17-19.03.58.672185-240 I395047A488        LEVEL: Event
PID     : 946302               TID  : 1           PROC : db2stmm (MYDB1) 1
INSTANCE: ewhhr                NODE : 001
APPHDL  : 1-52                 APPID: *N1.cgarciaa.060809150048
AUTHID  : CGARCIAA
FUNCTION: DB2 UDB, buffer pool services, sqlbAlterBufferPoolAct, probe:90
MESSAGE : Altering bufferpool “BUFFERPOOL_16K" From: “117268" <automatic>
                                               To: “109666" <automatic> 

db2diag ツールを使うと、これらのレコードを db2diag.log から容易に抽出することができます。例えば次のコマンドを使うと、バッファー・プール・サイズに対するすべての変更を検索することができます。

db2diag -g "message:=Altering bufferpool" db2diag.log

DB2 のデータ・パーティショニング機能を使って複数のパーティションを持つデータベースの場合、それぞれのパーティションに加えられた変更を抽出するためには -node オプションを使います。例えば次のコマンドを使うと、パーティション 1 に対するデータベース構成の更新をすべて抽出することができます。

db2diag -node 1 -g "changeevent:=CFG DB" db2diag.log

上に戻る

STMM ログ

変更は db2diag.log ファイルのログ・エントリーとして記録される他、もっと詳細な変更内容が STMM ログにも記録されます。STMM ログは db2diag.log ファイルと同じディレクトリーの中の stmmlog という名前のディレクトリーに保存されます。STMM ログは通常、DB2 による問題判別のサポートで使われるためのものです。しかし STMM ログの中にあるチューニング情報の一部は STMM がチューニングに関して下した判断をデータベース管理者が理解するために役立ちます。STMM ログ・レコードの各エントリーは、チューニングに関する判断を下す前に収集された統計と、そうした統計に基づいて実行されたアクションを記録しています。STMM ログは最大 5 つのファイルに分割され、各ファイルの最大サイズは 10MB です。これらのログ・ファイルは循環形式で保持され、必ず、最も古いファイルを削除してから新しいファイルが作成されます。

STMM ログ・ファイル・パーサーの目的は、重要なチューニング情報を抽出し、フォーマット設定することによって、メモリー構成がどのように進化してきたかを理解しやすくすることです。

上に戻る

STMM ログ・ファイルの解析

ここで紹介する解析ツール、parseStmmLogFile.pl の構文は次のとおりです。

parseStmmLogFile.pl <log file> <database name> <options>

このツールによって生成される出力は表の形式をしています。この表の最初の 4 列は、ユーザーがどのようなオプションを選択した場合も同じです。この最初の 4 列は次のとおりです。

• チューニング・インターバルの回数
• チューニング・インターバルが発生した時刻
• ログ・ファイルの中にある最初のチューニング・インターバルからの合計秒数
• その前のチューニング・インターバルを開始した時点からの経過時間の秒数。この値には、メモリー・ヒープのリサイズに費やした時間やチューニングに関する判断を下すための統計収集に費やした時間が含まれます。

リスト 6 は最初の 4 列の例として 2 つのチューニング・インターバルを持つものを示しています。

[ MEMORY TUNER - LOG ENTRIES ]
[ Interv ] [        Date         ] [ totSec ] [ secDif ]
[        ] [                     ] [        ] [        ]
[      1 ] [ 02/01/2006 09:45:02 ] [     76 ] [     76 ]
[      2 ] [ 02/01/2006 09:46:03 ] [    137 ] [     61 ]

このツールは選択されたオプションに基づいて STMM ログ・ファイル全体を解析し、指定されたオプションに関する具体的な詳細情報を収集します。選択できるオプションは次のように合計 4 つあります。

• (s) — 各メモリー・コンシューマーの新しいサイズを表示します (デフォルトのオプション)。
• (m) — 各メモリー・コンシューマーの最小サイズを表示します。
• (b) — 各メモリー・コンシューマーのベネフィット・データを表示します。ベネフィット・データは、メモリーを追加した場合に各メモリー・コンシューマーの状況がどの程度改善されるかを示します。
• (o) — DATABASE_MEMORY のチューニング情報を表示します。

さらに 2 つのオプション・フラグがあり (これらのフラグを指定する場合には、これらのフラグを上記のフラグへの追加として提供する必要があります)、これらのフラグによって出力を変更することができます。

• (4) — すべてのメモリー・コンシューマーを 4KB のページ・サイズに変更します。
• (d) — セミコロンで区切られた出力を生成します。このオプションはパーサー出力をスプレッドシートに入力しようとする場合に便利です。

例 1. ヒープのリサイズの履歴

このオプションは構成パラメーターとバッファー・プールに対して STMM が行った変更を表示するために使われます。

リスト 7 では parserStmmLogfile.pl コマンドによって 2 つのチューニング・インターバルの情報を表示しています。最初のチューニング・インターバルは STMM ログ・ファイルが作成されてから 76 秒後に開始されており、またチューニングされた 2 つのパラメーターは SHEAPTHRES_SHR と PCKCACHESZ です。2 行目はその 61 秒後に開始された 2 番目のチューニング・インターバルを示しており、この結果として PCKCACHESZ から SHEAPTHRES_SHR に 1000 ページが転送されています。

$ parseStmmLogFile.pl stmm.0.log mydbname s
                      
  [ MEMORY TUNER - LOG ENTRIES ] 
  [ Interv ] [        Date         ] [ totSec ] [ secDif ] [ newSz ]
  [        ] [                     ] [        ] [        ] [ SHEAPTHRES_SHR  PCKCACHESZ ] 
  [      1 ] [ 02/01/2006 09:45:02 ] [     76 ] [     76 ] [ 31482 19438 ]       
  [      2 ] [ 02/01/2006 09:46:03 ] [    137 ] [     61 ] [ 32482 18438 ]

例 2. データベース・メモリーのリサイズの履歴

次のコマンドは、データベースのメモリーをチューニングするための判断に関する基本的な情報を出力するために使われます。各列に含まれるデータには、メモリー・チューナーによって決まるシステム上の合計メモリー量 (configMem) や、DB2 が使用できる物理メモリー量 (memAvail)、DATABASE_MEMORY 構成パラメーターを使ってサイズを指定された、データベースの共有メモリー・セットの現在のサイズ (setConfSz) などがあります。

$ parseStmmLogFile.pl stmm.0.log mydbname o

[ MEMORY TUNER - DATABASE MEMORY AND OVERFLOW BUFFER TUNING - OG ENTRIES ]
[ Interv ][ Date                ][ totSec ][ secDif ][ configMem ][ memAvail ][ setCfgSz ]
[      1 ][ 02/01/2006 09:45:02 ][     76 ][     76 ][       N/A ][      N/A ][      N/A ]
[      2 ][ 02/01/2006 09:46:03 ][    137 ][     61 ][   4194304 ][  1559966 ][    62224 ]

SORTHEAP リサイズの履歴

このコマンドは SORTHEAP 構成パラメーターの値のチューニングに使われた情報の要約を出力するために使われます。各行は SORTHEAP の値が適切に自動更新されたことを示します。各列に含まれるデータは、SORTHEAP 構成パラメーターの、前の値 (OLD)、現在の値 (NEW)、そしてメモリー・チューナーが計算した最小値と最大値 (min と max) です。

$ parseStmmLogFile.pl stmm.0.log mydbname v

[ SORTHEAP TUNING - SORTHEAP CHANGE VALIDATION RECORDS ]
[ Date                ][ totSec ][ secDif ][ SHEAPTHRES_SHR ][ OLD ][ NEW ][ min ][  max ]
[ 02/01/2006 14:51:01 ][    184 ][    184 ][          11212 ][ 373 ][ 560 ][ 224 ][ 2243 ]

上に戻る

使い方のヒント

• このツールを実行する際には、指定されたデータベース名が確実に STMM ログ・ファイルの中に存在しているようにします。
• 最適な結果を得るためには、ツールの実行時に 1 つのオプション (m または s、o) のみを指定し、結果が読みやすいものになるようにします。
• 実行の際にオプションを指定しない場合には、デフォルト (つまり s オプション) で新しいサイズが表示されます。
• 詳細なオプション・リストは (上で説明した同じ例を含めて) スクリプト自体の中で提供されます。
• このツールを実行するシステムには Perl インタープリターがインストールされている必要があります。システムに Perl インタープリターが存在しない場合には http://www.perl.org からダウンロードすることができます。このソフトウェアをダウンロードしてインストールする前に、サードパーティーのソフトウェを使用することに関する皆さんの組織のポリシーを必ず確認してください。
• このツールはデータベース管理者がそれぞれの独自の要件に合わせて変更できるように Perl スクリプト言語で開発されています。例えば別のフォーマットを使うようにツールを変更し、そのフォーマットを他のツールにインポートして履歴データをグラフ表示するようなことができます。

上に戻る

免責事項

IBM は、この記事より参照もしくはアクセスできる、または IBM Webサイトにリンクされた IBM 以外の Web サイトもしくは第三者のリソースに対して一切の責任を負いません。IBM 以外の Web サイトにリンクが張られていることにより IBM が当該 Web サイトを推奨するものではなく、またその内容、使用もしくはサイトの所有者について IBM が責任を負うことを意味するものではありません。また、IBM は、お客様が IBM Web サイトから第三者の存在を知ることになった場合にも (もしくは、IBM Web サイトから第三者へのリンクを使用した場合にも)、お客様と第三者との間のいかなる取引に対しても一切責任を負いません。従って、お客様は、IBM が上記の外部サイトまたはリソースの利用について責任を負うものではなく、また、外部サイトまたはリソースからアクセス可能なコンテンツ、サービス、製品、またはその他の資料一切に対して IBM が責任を負うものではないことを承諾し、同意するものとします。第三者により提供されるソフトウェアには、そのソフトウェアと共に提供される固有の使用条件が適用されます。

上に戻る

ダウンロード

ダウンロード形式について

参考文献

学ぶために

• 「自己チューニング・メモリー・マネージャーのロードマップ」には DB2 V9 のセルフ・チューニング・メモリー・マネージャーに関するさらに詳しい情報が提供されています。
  
  
• 「Self-tuning Memory Manager Whitepaper」にも STMM が解説されています。
  
  
• developerWorks の Information Management ゾーンで DB2 について学んでください、技術資料やハウ・ツー記事、教育資料、ダウンロード、製品情報など、豊富な情報が用意されています。
  
  
• developerWorks technical events and webcasts で最新情報を入手してください。
  
  

製品や技術を入手するために

• developerWorks から直接ダウンロードすることができる IBM ソフトウェアの試用版を使って皆さんの次期開発プロジェクトを構築してください。
  
  

議論するために

• developerWorks blogs から developerWorks のコミュニティーに加わってください。
  
  

著者について

Askari Naqvi は IBM Toronto Lab の DB2 組織のメンバーです。彼はこの 6 年間、さまざまなバージョンの DB2 に関するいくつかの重要機能や機能強化の業務に従事してきました。主なプロジェクトには、DB2 Satellite、DB2 Query Patroller、Autonomics、Automatic Tablespaces、STMM などがあります。現在は DB2 の Workload Management と改善された Storage Management を中心とした業務を行っています。彼はモントリオールの McGill University にてコンピューター・サイエンスの修士号を取得しています。

Christian Garcia-Arellano は IBM Toronto Lab の DB2 Engine Development チームのメンバーです。彼はこの 5 年間、STMM など、主に DB2 のメモリー関連機能強化のためのいくつかの業務に従事してきました。その他に携わったプロジェクトには、構成アドバイザーやソート・メモリー管理への機能強化、稼働状態のワークロードに対するオンラインでのメモリー・チューニングの効果検討などがあります。またデザイン・アドバイザーなどのオートノミック・プロジェクトに従事したこともあります。

Haysam Alsayed は IBM Toronto Software Lab の DB2 System Verification チームのメンバーです。彼は 2006年5月に IBM に入社しましたが、その前には Schulich School of Engineering at the University of Calgary にてソフトウェア・エンジニアリングを学んできました。彼は現在まで、z/os や iSeries など、さまざまなホスト・サーバーでの DB2 Connect 製品のテストを主に行ってきました。また DB2 9 のテストにも従事したことがあり、そこでは主に STMM や DB2 コネクト、DB2 セキュリティーなどの機能の統合作業を行ってきました。

Adam Storm は IBM Toronto Lab の DB2 Engine Development チームのメンバーです。彼はこの 7 年間、主に DB2 のメモリー関連機能強化のためのいくつかの業務に従事してきました。そうしたプロジェクトには、DB2 Configuration Advisor への機能強化や DB2 Memory Tracker の作成、DB2 Memory Visualizer に関する業務などがあります。また db2support ツールや DB2 Design Advisor など、IBM における他のいくつかのオートノミック・プロジェクトにも従事してきました。ごく最近には DB2 9 の STMM の開発リーダーとして業務を行ってきました。

この記事を評価する

コメント

上に戻る

目次

• はじめに
• STMM の動作
• db2diag.log ファイルへの変更を監視する
• STMM ログ
• STMM ログ・ファイルの解析
• 使い方のヒント
• 免責事項
• ダウンロード
• 参考文献
• 著者について
• コメント