目次


IBM WebSphere Portal の Web Content Manager および DB2 のチューニング・ガイド

Comments

環境のパフォーマンス・チューニング

WebSphere Portal 環境のチューニングとは、環境に含まれるさまざまなシステムおよびコンポーネントのチューニングと構成を行うことです。このセクションでは、一般的な概念を説明し、筆者が使用している測定環境で使用されている構成の特性を詳細に説明します。WebSphere Portal の Web Content Management (WCM) AIX® Power4 測定環境のチューニングと構成は、WebSphere Portal AIX Power4 環境 (「IBM WebSphere Portal バージョン 6.0 チューニング・ガイド(US)」に詳細説明があります) に基づきます。WCM の測定に使用される環境における相違点についてはすべて、この章で明示的に言及します。WebSphere Portal 環境のチューニングと構成の全体的なアプローチには、以下のことが含まれます。

  • アプリケーション・サーバーと、そのアプリケーション・サーバーのために定義されたリソースを構成する。
  • 環境を拡大または拡張するためのクローン作成戦略を決定する。
  • データベースとデータベース・サーバーをチューニングする。
  • ディレクトリー・サーバーとそのデータベースをチューニングする。
  • Web サーバーをチューニングする。
  • オペレーティング・システムとネットワークをチューニングする。
  • WebSphere Portal サービスをチューニングする。

個々のシステムをチューニングするにあたっては、ベースラインから開始して、パフォーマンス測定基準を監視してパラメーターの変更が必要かどうかを判断し、変更が行われた時にはパフォーマンス測定基準を監視して変更の有効性を判断することが重要です。

環境を理解する

WebSphere Portal V6.0 は、追加サーバーを使用してその機能を発揮します。筆者の測定環境には、ポータル・サーバーそのものに加えて Web サーバー、データベース・サーバー、およびディレクトリー・サーバーがあります。最大限のパフォーマンスを得るためには、これらのサーバーを WebSphere Portal システムとは別のシステム上に置く必要があります。このような構成による主な利点は、複数のサーバーが単一システム上に置かれた場合に発生するリソースの競合を回避できることです。追加サーバーと WebSphere Portal サーバーとの間でシステム・リソースの競合が起きると、システムの達成可能なスループットに影響が及びます。この記事で説明する測定環境で使用した構成では、WebSphere Portal と同じシステム上に IBM HTTP Server が搭載されていました。

アプリケーション・サーバーのチューニング

WebSphere Application Server におけるアプリケーション・サーバーの構成とチューニングにはさまざまなアスペクトがあります。この記事および「IBM WebSphere Portal バージョン 6.0 チューニング・ガイド(US)」で取り上げられているアスペクトは、研究環境で WebSphere Portal を適切に機能させ、最適なパフォーマンスを得るためにきわめて重要なものとなりました。WebSphere Application Server のチューニングの詳細については、インフォメーション・センターの「チューニング」セクションを参照してください。

表 1 は、本書で説明したワークロードでの筆者の経験に基づき、「IBM WebSphere Portal バージョン 6.0 チューニング・ガイド(US)」で Power4 プラットフォーム上の AIX 向けとして記載されている設定と異なる設定をまとめたものです。

表 1. アプリケーション・サーバーのパラメーター

パラメーター 設定値詳細
Java™ 仮想マシン (JVM) ヒープ・サイズ1792JVM のヒープ・サイズの値は、システムの物理メモリー容量に直接関係することに注意してください。JVM のヒープ・サイズをシステムの物理メモリー容量より大きく設定しないようにします。
「JVM ヒープ・サイズの最大限度」を参照してください。
JVM ヒープ大容量ページ-Xlp IBM JVM とともに、大容量ページを使用するヒープを割り振るために使用されます。
「JVM ヒープ大容量ページ」を参照してください。
kCluster と pCluster -Xk30000
-
Xp24000k,2400k
固定クラスター。クラス・ファイルのために JVM ヒープを事前割り振りしておきます。そうでないと、ロードされた時点でメモリーに固定されてしまうためです。
「kCluster と pCluster」を参照してください。

JVM ヒープ・サイズの最大限度

アプリケーション・サーバーについてヒープ・サイズを設定する際には、以下のことを念頭に置いてください。システムに、すべてのプロセスを物理メモリーに収容できる程度に十分であり、さらにオペレーティング・システムにとって十分な物理メモリーが搭載されていることを確認します。システム内の物理メモリーを上回るメモリーが割り振られると、ページングが起こり、その結果パフォーマンスが著しく低下するおそれがあります。

筆者は最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定しましたが、IBM JDK 上で実行されている実動システムの場合には、これが最善の選択とはならない場合があります。筆者の測定実行では、システムに負荷がかかる時間は比較的短く (約 3 時間)、システムはメモリー所要量が大きくないポートレットとともに実行されていました。メモリー所要量が大きいポートレットを使用している場合、または連続稼働の場合には、初期ヒープ・サイズを 320 メガバイトに設定することによりヒープ・フラグメントを削減できる場合があります。

何らかの形でヒープ・サイズのチューニングを行った後は、システムを監視して、ページングが起こっていないことを確認します。前述のように、ページングはパフォーマンスの低下をもたらすおそれがあります。

パラメーターの設定方法:

WebSphere の管理コンソールで、「Servers」 > 「Application Servers」 > 「WebSphere Portal」 > 「Server Infrastructure: Java and Process Management」 > 「Process Definition」 > 「Java Virtual Machine」を選択します。
以下の 2 カ所のヒープ・サイズを変更することができます。
-初期ヒープ・サイズ
-最大ヒープ・サイズ

JVM ヒープ大容量ページ

この設定を IBM JVM とともに使用して、大容量ページを使用するヒープを割り振ることができます。AIX オペレーティング・システムでは、大容量ページがサポートされるよう構成する必要があります。大容量ページを使用することにより、ヒープを追跡するために必要な CPU オーバーヘッドを削減できます。このチューニングによって、筆者の測定環境では 10% のスループット改善が見られました。

パラメーターの設定方法:

  1. WebSphere の管理コンソールで、「Servers」 > 「Application Servers」 > 「WebSphere Portal」 > 「Server Infrastructure: Java and Process Management」 > 「Process Definition」 > 「Java Virtual Machine」 > 「Generic JVM Argument」を選択します。 「-Xlp」と追加します。
  2. WebSphere の管理コンソールで、「Servers」 > 「Application Servers」 > 「WebSphere Portal」 > 「Server Infrastructure: Java and Process Management」 > 「Process Definition」 > 「Custom Properties」 > 「New」 > 「EXTSHM=OFF」を選択します。 (注: EXTSHM がオンになっていると、大容量ページを使用できなくなります。)
  3. Portal サーバーを停止します。
  4. AIX を大容量ページがサポートされるよう構成します。筆者は以下の手順で、1856 MB の RAM を大容量ページ (16MB) として割り振りました。この容量を選択した根拠は、これらのシステムに 4GB の物理メモリーが搭載されていたことです。物理メモリーの容量が異なるシステムの場合には、それに応じてこの値を調整する必要がある可能性があります。 vmo -r -o lgpg_regions=116 -o lgpg_size=16777216 bosboot -a reboot -q vmo -p -o v_pinshm=1 chuser capabilities=CAP_BYPASS_RAC_VMM,CAP_PROPAGATE $USER
  5. Portal Server を再始動させます。大容量ページが使用されていることを検証するには、AIX コマンド vmstat -l 1 5 を実行して、使用されるアクティブな大容量ページである「alp」列をチェックします。大容量ページが使用されていれば、その値がゼロ以外の値となっています。

kCluster と pCluster

JVM ヒープ上にあるオブジェクトは通常、移動体です。すなわち、Garbage Collector (GC) が、ヒープの順序を再設定すると決定した場合には、これらのオブジェクトを移動させることができます。しかし、オブジェクトの中には、永続的にも一時的にも移動することができないものがあります。そのような移動不能なオブジェクトを固定オブジェクトと呼んでいます。

リリース 1.3.1 サービス・リフレッシュ 7 以降では、GC は kCluster をヒープ末尾の第 1 のオブジェクトとして割り振ります。kCluster とは、クラス・ブロックのためのみに使用されるストレージ域です。1280 ものエントリーを収容できるほどの大きさがあります。各クラス・ブロックの長さは 256 バイトです。

GC は次に、pCluster をヒープ上の第 2 のオブジェクトとして割り振ります。pCluster とは、固定オブジェクトを割り振るために使用されるストレージ域です。長さは 16 KB です。

kCluster がいっぱいになると、GC は pCluster 内にクラス・ブロックを割り振ります。pCluster がいっぱいになると、GC は 2 KB の大きさの新規 pCluster を割り振ります。

この新規 pCluster はヒープ内のどの場所にも割り振ることができると同時に、固定しなければならないため、フラグメント化の問題をもたらす可能性があります。固定オブジェクトによって、GC がヒープ圧縮中にフリー・スペースを結合させる能力が損なわれ、その結果、大量のフリー・スペースを含むが相対的に小容量のヒープが生まれるおそれがあります。すると、合計フリー・スペースを大きく下回っているように見える割り振りに障害が起こります。この問題を解決するため、リリース 1.3.1 の SR7 以降では、kCluster (-Xk)、pCluster (-Xp)、および pCluster overflowsize (-Xp) を指定するコマンド行オプションが用意されています。これらのオプションを使用して、クラスターの初期サイズを、フラグメント化の問題を回避できる程度に十分に大きいサイズに設定します。

パラメーターの設定方法:

WebSphere の管理コンソールで、「Servers」 > 「Application Servers」 > 「WebSphere Portal」 > 「Server Infrastructure: Java and Process Management」 > 「Process Definition」 > 「Java Virtual Machine」 > 「Generic JVM Argument」を選択します。
「-Xk30000 -Xp24000k,2400k」と入力します。

データ・ソースのチューニング

WebSphere Portal インフォメーション・センターに説明があるように、WebSphere Portal V6.0 では複数のデータベースが使用されています。筆者の環境では、それぞれ独自のデータ・ソースを持つ 7 つの異なるデータベースを使用しました。それらのデータベースとデータ・ソースは以下のとおりです。

表 2. データ・ソース名

データベースデータベース名データ・ソース名
リリースreleasereldbDS
コミュニティーcommunitycommdbDS
カスタマイズcustomcusdbDS
フィードバックfdbkdbfdbkdbDS
ライクマインドlmdblmdbDS
JCRjcrdbjcrdbDS
メンバー・マネージャーwmmdbwmmdbDS

作成されたステートメントのキャッシュ・サイズのパスは、「Resources > JDBC Providers > provider name > Data Sources > datasource name > WebSphere Application Server data source properties」となります。プロバイダー名とデータ・ソース名は、データベース転送手順でそのデータベースの名前として選択されたものに基づいています。パラメーター・ステートメントのキャッシュ・サイズを確認します。

作成されたステートメントのキャッシュ・サイズをすべてのデータ・ソースについて 1 ステートメントと設定して、ネイティブ・メモリーに対する要求を減らし、それにより異常終了を回避しました。

DB2 レジストリー変数

作成されたステートメントのキャッシュ・サイズをすべてのデータ・ソースについて 1 ステートメントと設定して、ネイティブ・メモリーに対する要求を減らし、それにより異常終了を回避しました。

表 3. DB2 レジストリー変数の説明

レジストリー変数説明
DB2_RR_TO_RS このパラメーターは、DB2 v8.2 以降、非推奨となっています。8.2 より後のバージョンの DB2 でパラメーターを設定しようとした時にエラーが発生しないようであれば、設定しても構いません。エラーが発生しても、心配無用です。以下の 2 つの変数で置き換えることができます。 DB2_RR_TO_RS がオンになっていると、ユーザー・テーブルのスキャンでの RR の動作を保証することができません。次のキー・ロッキングが索引キーの挿入と削除の間に完了しないためです。このオプションによってカタログ・テーブルに影響が生じることはありません。この他に動作に変化が生じるのは、DB2_RR_TO_RS がオンになっている場合です。その場合、削除されたがコミットされていない行 (スキャンの適格性を有した行でであっても) のスキャンがスキップされます。
DB2_EVALUNCOMMITTED この変数が有効になっていると、この変数はテーブルまたは索引のアクセス・スキャンに、データ・レコードが述部の評価を満たすことがわかるまで、行のロッキングを延期または回避させるようにできる場合があります。DB2_EVALUNCOMMITTED は、カーソル固定または読み取り固定のいずれかの分離レベルを使用しているステートメントにのみ適用されます。索引スキャンについては、索引はタイプ 2 の索引でなければなりません。さらに、削除された行はテーブル・スキャン・アクセスで無条件にスキップされます。一方、タイプ 2 索引のスキャンでは、削除されたキーは、レジストリー変数 DB2_SKIPDELETED がそこでも設定されていない限りスキップされません。
DB2_SKIPDELETED この変数が有効になっていると、この変数はカーソル固定または読み取り固定のいずれかの分離レベルを使用しているステートメントに、索引アクセス中に削除されたキーを、またテーブル・アクセス中に削除された行を無条件にスキップさせます。DB2_EVALUNCOMMITTED が有効になっていると、削除された行は自動的にスキップされますが、タイプ 2 索引における、削除されたように見えるがコミットされていないキーは、DB2_SKIPDELETED がそこでも有効になっていない限りスキップされません。
DB2_INLIST_TO_NLJN 場合によっては、最適化プログラムが、再書き込みされたクエリーのバージョンのための最善の結合メソッドを判断するための正確な情報を得られないことがあります。これは、IN リストに、最適化プログラムがカタログ統計を使用して選択度を決定することを妨げるパラメーター・マーカーまたはホスト変数が含まれる場合に起こる可能性があります。このレジストリー変数により、最適化プログラムは、結合内の内部テーブルとして IN リストに寄与するテーブルを使用して、値リストを結合するネストされたループ結合のように振る舞うようになります。
DB2_MINIMIZE_LISTPREFETCH JCR データベース内のテーブルの 1 つに対する共通クエリーのための非効率なアクセス・プランを回避するために必要です。

インスタンスのユーザーとして、以下のコマンドを入力して DB2 レジストリー変数を設定します。

db2set DB2_RR_TO_RS=YES
db2set DB2_EVALUNCOMMITTED=YES
db2set DB2_SKIPDELETED=ON
db2set DB2_INLIST_TO_NLJN=YES
db2set DB2_MINIMIZE_LISTPREFETCH=ON

オプションの変数

DB2 が実行されているシステムに CPU の制約がある場合には、以下のパラメーターも設定します。この変数は、6 個以上の結合が関与するすべてのステートメントに影響するため、慎重に使用する必要があります。このパラメーターは、最適化過程での時間とリソース使用の削減に役立つことがあります。最適化の時間とリソース使用が削減される可能性がありますが、最適とは言えないデータ・アクセス・プランが作成されるリスクも高まります。

DB2_REDUCED_OPTIMIZATION=5

重要: このパラメーターは、IBM から明示的な助言があった場合にのみ設定してください。

データベース・マネージャーの構成パラメーター

表 4 に、データベース・マネージャーの構成パラメーターを示します。

表 4. データベース・マネージャーの構成パラメーター

パラメーター名
QUERY_HEAP_SZ 32768
MAXAGENTS 1000
SHEAPTHRES 50000
HEALTH_MON OFF
ASLHEAPSZ 60
RQRIOBLK 65535

インスタンスのユーザーとして、以下のコマンドを入力してデータベース・マネージャー構成を更新します。

db2 "update dbm cfg using query_heap_sz 32768"
db2 "update dbm cfg using maxagents 1000"
db2 "update dbm cfg using sheapthres 50000"
db2 "update dbm cfg using health_mon off"
db2 "update dbm cfg using aslheapsz 60"
db2 "update dbm cfg using rqrioblk 65535"
db2 "update dbm cfg using federated no"

: フェデレーテッド・データベース・サポートが必要な場合には、「FEDERATED」を「NO」に設定しないでください。

データベース構成パラメーター

すべてのデータベースのためのパラメーター

表 5 に、すべてのデータベースについて設定する必要のあるデータベース構成パラメーターを示します。

表 5. すべてのデータベースのためのデータベース構成パラメーター

パラメーター名
APPLHEAPSZ 4096
APP_CTL_HEAP_SZ 1024
STMTHEAP 8192
DBHEAP 2400
LOCKLIST 1000
LOGFILSIZ 1000
LOGPRIMARY 12
LOGSECOND 20
LOGBUFSZ 128
AVG_APPLS 5
LOCKTIMEOUT 30
MAXLOCKS 70
MAXAPPLS AUTOMATIC

インスタンスのユーザーとして、以下のコマンドを入力してすべてのデータベースのためのデータベース構成を更新します。「DBNAME」を実際のデータベース名に変更することに注意してください。

db2 "update db cfg for DBNAME using applheapsz 4096"
db2 "update db cfg for DBNAME using app_ctl_heap_sz 1024"
db2 "update db cfg for DBNAME using stmtheap 8192"
db2 "update db cfg for DBNAME using dbheap 2400"
db2 "update db cfg for DBNAME using locklist 1000"
db2 "update db cfg for DBNAME using logfilsiz 1000"
db2 "update db cfg for DBNAME using logprimary 12"
db2 "update db cfg for DBNAME using logsecond 20"
db2 "update db cfg for DBNAME using logbufsz 128"
db2 "update db cfg for DBNAME using avg_appls 5"
db2 "update db cfg for DBNAME using locktimeout 30"
db2 "update db cfg for DBNAME using maxlocks 70"
db2 "update db cfg for DBNAME using maxappls automatic"

JCR データベースのためのパラメーター

表 6 に、JCR データベースについて設定する必要のあるデータベース・パラメーターを示します。

表 6. JCR データベースのためのデータベース・パラメーター

パラメーター名
DBHEAP 4800
SORTHEAP 4096
APPLHEAPSZ 16384
APP_CTL_HEAP_SZ 20000
STMTHEAP 16384
NUM_IOCLEANERS 11
NUM_IOSERVERS 11

インスタンスのユーザーとして、以下のコマンドを入力して JCRDB 固有のデータベース構成を更新します。「JCRDB」を実際のデータベース名に変更してください。

db2 "update db cfg for JCRDB using dbheap 4800"
db2 "update db cfg for JCRDB using sortheap 4096"
db2 "update db cfg for JCRDB using applheapsz 16384"
db2 "update db cfg for JCRDB using app_ctl_heap_sz 20000"
db2 "update db cfg for JCRDB using stmtheap 16384"
db2 "update db cfg for JCRDB using num_iocleaners 11"
db2 "update db cfg for JCRDB using num_ioservers 11"

データベースのチューニング

データベースのパフォーマンスは、WCM から良好なパフォーマンスを得るためにきわめて重要です。この記事および「IBM WebSphere Portal Version 6.0 チューニング・ガイド(US)」で紹介されている保守のタスクとプラクティスは、研究環境における WebSphere Portal のパフォーマンスと適切な運用のためにとってきわめて重要なものであることがわかりました。実稼働環境では、追加のデータベース保守とチューニングが必要となる場合があります。DB2 の管理、チューニング、および監視についての詳細は、DB2 のインフォメーション・センター (「参考文献」参照) を参照してください。

照合シーケンス

DB2 では、データベース作成時に照合シーケンスを選択することができます。この選択により、パフォーマンスに影響が生じる場合があります。UCA400_NO 照合を使用した場合、この記事で説明したシナリオのスループットに対して実質的にいかなる影響もなかったにもかかわらず、データベース CPU コストは大幅に上昇しました。しかし別の調査測定環境では、UCA400_NO 照合の使用により、一部の WCM オーサリング・トランザクションに明らかな影響が見られました。経験法則として、特別なロケール固有のデータ配列が必要な場合には、その必要性と、データベース CPU コストがいくらか上昇する可能性との兼ね合いを勘案する必要があります。筆者がデータベースを作成した時には、いかなる「COLLATE」オプションも指定しませんでした。

JCR テーブルを安定状態になるように変更する

JCR スキーマの DB2 構成では、大半のテーブルに「VOLATILE CARDINALITY」のマークが付きます。初回の転送中は確かにこれに該当します。多くのテーブルが、ゼロまたは少数の行から多数の行に拡大するためです。この属性は、DB2 の最適化プログラムに対し、テーブルのサイズがきわめて小さいことを示すテーブル統計を信頼しないよう指示します。これは、最適化プログラムは通常であれば、小容量テーブルの索引を使用することよりもテーブルをスキャンすることを選択するためです。データベースが定常状態に到達したら、最適化プログラムがカタログ統計に応じて最善のアクセス・プランを選択するようにする必要がある場合があります (統計を保持する方法に関する推奨事項については、以下のセクションを参照してください)。これを行うには、以下のコマンドを実行します。

db2 -x -r "nonVolatile.db2" "select rtrim(concat('alter table ', concat(rtrim(tabSchema),
concat('.', concat(rtrim(tabname), ' not volatile'))))) from syscat.tables where type='T'
and volatile='C' and tabSchema='JCR'"

db2 -v -f "nonVolatile.db2"

継続的なデータベース保守

Runstats と reorg

DB2 が最適なパフォーマンスを発揮するために使用するデータベース属性のうちの 2 つは、データベース・カタログ統計と、テーブル内のデータの物理編成です。カタログ統計は、データベースの存続期間中、特に転送フェーズなどの大量のデータ変更 (挿入、更新、および削除) が行われる期間が終わった後に、定期的に再計算する必要があります。これらの統計の計算に伴う激しい競合のため、この保守作業は業務時間外、アクセス要求が少ない時、またはポータルがオフラインの時に実行するのが最善です。DB2 の runstats コマンドは、テーブル、索引、および列に関する詳細な統計情報を算出して記録するために使用されます。筆者は、使用している環境で、2 つの手法を使用してこれらの統計情報を計算しました。推奨する形式は以下のようなものです。

db2 "runstats on table tableschema.tablename on all columns with distribution
on all columns and sampled detailed indexes all allow write access"

これらのオプションにより、最適化プログラムが複雑な SQL のための最適なアクセス・プランを決定することができるようになります。カタログ統計を計算するための、より単純で便利な手法としては以下のものがあります。

db2 reorgchk update statistics on table all

このコマンドは、カタログ統計の一部を算出および記録するだけでなく、テーブルの編成上の問題を特定するために利用できるレポートも生成します。ただし、最適化プログラムが複雑な SQL、特に JCR データベースのクエリーのための効率的なアクセス・プランを選択するには、このコマンドによって生成される情報では不十分であるケースもありました。reorgchk コマンドと同じくらい便利で、かつ最適化プログラムにとって望ましい詳細な統計情報が得られる手法が必要な場合には、以下のコマンドを使用します。

db2 -x -r "runstats.db2" "select rtrim(concat('runstats on table',
concat(rtrim(tabSchema), concat('.',concat(rtrim(tabname),
' on all columns with distribution on all columns and sampled detailed
indexes all allow write access'))))) from syscat.tables where type='T'"

db2 -v -f "runstats.db2"

すべてのテーブルを再編成することは、実稼働環境においては荷が重過ぎます。どのテーブルに再編成するメリットが見込まれるかを判断するには、以下のコマンドを使用します。

db2 reorgchk current statistics on table all > "reorgchk.txt"

再編成が必要なテーブルには、テーブル名の隣の 3 つの列の少なくとも 1 つに「*」が記載されています。再編成が必要なテーブルについては、以下のコマンドを使用します。

db2 reorg table tableschema.tablename

監視

スナップショット監視は、長期間にわたるデータベースの動作を特定するために使用されます。また、システムの微調整と、パフォーマンスに関する問題の検出にも使用されます。

スナップショット監視を機能させるためには、初めにさまざまなモニターをアクティブにする必要があります。これを行う方法は 2 つあります。データベース・マネージャーを構成してインスタンス・レベルでの監視を起動するか、または現在のセッションの特定の時点で監視をオンにするかのいずれかを行います。

デフォルトの監視をインスタンスの起動時またはインスタンス・レベルでオンにするには、以下のコマンドを使用します。

db2 update dbm cfg using DFT_MON on

ここで、DFT_MON は以下の値のいずれかとします。

DFT_MON_BUFPOOL DFT_MON_LOCK DFT_MON_SORT DFT_MON_STMT DFT_MON_TABLE DFT_MON_TIMESTAMP DFT_MON_UOW

現在のセッションについて監視をオンにするには、以下のコマンドを使用します。

db2 update monitor switches using MON_SWITCH on

ここで、MON_SWITCH は以下の値のいずれかとします。

表 7. モニター・スイッチ

モニター
バッファー・プール・アクティビティー情報BUFFERPOOL
ロック情報LOCK
ソート情報SORT
SQL ステートメント情報STATEMENT
テーブル・アクティビティー情報TABLE
タイム・スタンプ取得情報TIMESTAMP
作業単位情報UOW

: モニターをアクティブにすると CPU 使用率が上がるため、すべてのモニターをアクティブにするのは必要な時のみとしてください。

現在アクティブになっているモニター・スイッチを確認するには、以下のコマンドを使用します。

db2 get monitor switches

データベースのスナップショットを取得するには、以下のコマンドを実行します。

db2 get snapshot for all on DBNAME >snap.out

DB2 システムを監視するもう 1 つの手段として、db2top があります。このユーティリティーは http://www.alphaworks.ibm.com/tech/db2top (US) から入手できます。

バッファー・プール分析

バッファー・プールとは、テーブルおよび索引データ・ページをディスクからの読み込み中または変更中にキャッシュに入れるために使用されるメモリーです。バッファー・プールにより、ディスクからではなくメモリーからデータにアクセスできるようになるため、データベース・システムのパフォーマンスが向上します。メモリー・アクセスはディスク・アクセスより遥かに高速であるため、データベース・マネージャーがディスクからの読み取りまたはディスクへの書き込みを行う頻度が低くなるほど、パフォーマンスが向上します。

DB2 v8 には SYSIBMADM.BP_HITRATIO テーブルがないため、筆者はバッファー・プールのヒット率を計算するために 2 つのストアード・プロシージャーを記述しました。bphr は、実際のデータベースのバッファー・プールのヒット率を示すもので、bphr_all は、インスタンス内のすべてのアクティブなデータベースのバッファー・プールのヒット率を示すものです。

このストアード・プロシージャーは以下のコマンドで呼び出します。

db2 call bphr
db2 call bphr_all

インストール (データベースに接続した後) は以下のコマンドで行います。

db2 -td@ -f bphr.db2

リスト 1. バッファー・プールのヒット率を計算するストアード・プロシージャーのコード

CREATE PROCEDURE bphr ()
SPECIFIC tessus_bphr LANGUAGE SQL DYNAMIC RESULT SETS 1

BEGIN
  DECLARE res CURSOR WITH RETURN FOR
WITH bp_snap (snapshot_timestamp, database, bufferpool, bp_hr, data_hr, 
              idx_hr, page_clean_ratio )
AS
(
  SELECT snapshot_timestamp, SUBSTR(db_name,1,16), SUBSTR(bp_name,1,32),
  CASE
    WHEN ((pool_data_p_reads > 0 OR pool_index_p_reads > 0) AND 
          (pool_data_l_reads > 0 OR pool_index_l_reads > 0))
      THEN
        DECIMAL( ((1-(double(pool_data_p_reads + pool_index_p_reads)/
        DOUBLE(pool_data_l_reads + pool_index_l_reads+1)) )*100.0),3,1 )
      ELSE
        NULL
      END CASE,
      CAST( (CAST( pool_data_l_reads - pool_data_p_reads
        AS DOUBLE)*100.0)/(pool_data_l_reads+1) AS DECIMAL(3,1)),
      CAST( (CAST( pool_index_l_reads - pool_index_p_reads 
        AS DOUBLE)*100.0)/(pool_index_l_reads+1) AS DECIMAL(3,1)),
      CAST( (CAST( pool_async_data_writes + pool_async_index_writes
        AS DOUBLE)*100.0)/(pool_data_writes+pool_index_writes+1) 
        AS DECIMAL(3,1))
  FROM TABLE(snapshot_bp('',-1)) AS BP
  ORDER BY 2,3
)
SELECT snapshot_timestamp, database, bufferpool, bp_hr, data_hr, idx_hr 
FROM bp_snap;

  OPEN res;
END@

CREATE PROCEDURE bphr_all ()
SPECIFIC tessus_bphr_all LANGUAGE SQL DYNAMIC RESULT SETS 1

BEGIN
  DECLARE res CURSOR WITH RETURN FOR
WITH bp_snap (snapshot_timestamp, database, bufferpool, bp_hr, data_hr, 
              idx_hr, page_clean_ratio )
AS
(
  SELECT snapshot_timestamp, SUBSTR(db_name,1,16), SUBSTR(bp_name,1,32),
  CASE
    WHEN ((pool_data_p_reads > 0 OR pool_index_p_reads > 0) AND 
          (pool_data_l_reads > 0 OR pool_index_l_reads > 0))
      THEN
        DECIMAL( ((1-(double(pool_data_p_reads + pool_index_p_reads)/
        DOUBLE(pool_data_l_reads + pool_index_l_reads+1)) )*100.0),3,1 )
      ELSE
        NULL
      END CASE,
      CAST( (CAST( pool_data_l_reads - pool_data_p_reads
        AS DOUBLE)*100.0)/(pool_data_l_reads+1) AS DECIMAL(3,1)),
      CAST( (CAST( pool_index_l_reads - pool_index_p_reads 
        AS DOUBLE)*100.0)/(pool_index_l_reads+1) AS DECIMAL(3,1)),
      CAST( (CAST( pool_async_data_writes + pool_async_index_writes
        AS DOUBLE)*100.0)/(pool_data_writes+pool_index_writes+1) 
        AS DECIMAL(3,1))
  FROM TABLE(snapshot_bp(CAST(NULL AS VARCHAR(128)),-1)) AS BP
  ORDER BY 2,3
)
SELECT snapshot_timestamp, database, bufferpool, bp_hr, data_hr, idx_hr 
FROM bp_snap;

  OPEN res;
END@

DB2 9 では、この 2 つのストアード・プロシージャーか、または以下の SQL ステートメントのいずれかを使用して、バッファー・プールのヒット率を得ることができます。

db2 "select snapshot_timestamp, substr(db_name,1,10) as dbname,
substr(bp_name,1,18) as bufferpool, total_hit_ratio_percent as total,
data_hit_ratio_percent as data, index_hit_ratio_percent as index
from sysibmadm.bp_hitratio"

バッファー・プールのヒット率は、96% を超えるのが理想的です。バッファー・プールのサイズを大きくして、ヒット率が上昇するかどうかを見てみるのも有益です。ヒット率が低いままであれば、テーブル・スペースとバッファー・プールの論理レイアウトを再設計する必要も考えられます。

バッファー・プールのサイズは、以下のコマンドを使用してオンラインで変更できます。

db2 alter bufferpool BPNAME immediate size NUMBER_OF_PAGES

ディレクトリー・サーバーのチューニング

筆者の測定環境では、IBM Tivoli Directory Server (ITDS) バージョン 5.2 をディレクトリー・サーバーとして使用していました。詳細な構成は、「IBM WebSphere Portal Version 6.0 チューニング・ガイド(US)」で指定されている AIX ITDS V5.2 ディレクトリー・サーバーの構成と同じです。

WebSphere Portal のサービス・プロパティー

WebSphere Portal には、いくつかの構成可能なサービスが用意されており、それぞれに利用可能なパラメーターがあります。このセクションでは、「IBM WebSphere Portal Version 6.0 チューニング・ガイド(US)」に記述のあるサービスと異なるチューニングを行ったサービスについて説明します。

異なるチューニングを行ったサービスは、キャッシュ・マネージャー・サービスのみです。このサービスについては、以下の表に挙げた変更点を除き、WebSphere Portal の出荷時のデフォルト設定のままにしました。

表 8. キャッシュ・マネージャー・サービスのパラメーター

キャッシュ名AIX POWER4 WCM のレンダリング・シナリオ
com.ibm.wps.ac.ExplicitEntitlementsCache.ICM_CONTENT.size 2000
com.ibm.wps.datastore.services.Identification.SerializedOidStringCache.size 5000
com.ibm.wps.model.content.impl.ResourceCache.lifetime 14400

まとめ

このチュートリアルでは、WebSphere Portal WCM および DB2 環境のチューニング手順を説明しました。チューニング時に特別な配慮が必要となる、環境の特殊な部分についておわかりいただけたのではないかと思います。また、指定された値に設定する必要がある、さまざまなレジストリー変数といくつかのデータベース・マネージャーおよびデータベース構成パラメーターの重要性についても説明しました。最後に、システムの成長に合わせて DB2 システムの良好な稼動を維持するための保守の方法を紹介しました。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus, Information Management, WebSphere
ArticleID=347462
ArticleTitle=IBM WebSphere Portal の Web Content Manager および DB2 のチューニング・ガイド
publish-date=02212008