レベル: 上級 福井 清香, 情報マネジメント技術/ソフトウェア開発研究所, IBM
2006年 11月 07日 DB2Alphablox（以下Alphabloxと呼ぶ）は、データ分析を行うWebアプリケーションを作成、使用する際の強力な支援ツールです。Alphablox タグやJava APIを使ってリレーショナル・データベース、多次元データベースを照会し、結果セットをキャッシュで保持することで高速にデータにアクセスできるという特徴を持っています。しかしその特徴によりメモリーが圧迫され、パフォーマンス劣化などの問題が起こる場合もあります。本稿ではAlphablox 8.4に対して効果的なパフォーマンス・チューニングを行い、メモリー使用量や画面表示パフォーマンスを調整するための以下の方法をガイドします。
メモリー使用量調整法
1.JVMのヒープサイズ調整
AlphabloxのようなJ2EEアプリケーションの場合、アプリケーション・サーバーが稼働しているJava仮想マシン（以下JVMと呼ぶ）でのメモリー不足がパフォーマンス劣化やサーバーダウンにつながります。ここではJVMヒープ・サイズのチューニング方法を、WebSphere Application Server（以降WAS）の場合について説明します。
Alphabloxが稼働するWASのJVMがキャッシュのために使用するヒープはJavaヒープとネイティブ・ヒープの2種類があります。データベースの種類によってキャッシュの使われ方は異なりますが、例えばHyperion Essbase（以下Essbaseと呼ぶ）の場合は上記2つのヒープの双方を使ってデータベースのアウトラインがキャッシュされます。Alphablox Cubeのキャッシュについては以下をご参照ください。
メモリー・ヒープ最大サイズの変更
WASが32bit環境で稼働している場合、JVMが使用できるヒープは最大2GB程度なので、Javaヒープ、ネイティブ・ヒープのサイズをバランスよく調整する必要があります。
(1) Javaヒープのサイズ調整方法
WASの場合、Javaヒープ・サイズはJVMの初期ヒープ・サイズ、最大ヒープ・サイズによって決定されます。設定方法などの詳細は以下のWAS 6.0の資料をご覧ください。
Java 仮想マシン設定
メモリーが不足してアプリケーションが使用できない場合はOutOfMemoryExceptionが発生し、WASのSystemOut.logにログが出力されます。<WAS_HOME>にjavacore, heapdumpが出力されることもあります。このような場合はアプリケーション・サーバーごとにこの設定を行い、必要であればヒープのサイズ設定（特に最大ヒープサイズ）を増やします。
(2) AIXにおけるネイティブ・ヒープのサイズ調整方法
以下にAIXのメモリー・モデルに関する情報があります（英語の資料です）。
Running your Java application on AIX, Part 2: JVM memory models(US)
この資料によれば、環境変数"LDR_CNTRL"を設定することでネイティブ・ヒープの使用するメモリーを増やすことが可能となります。例えば、WASを起動するシェルで以下のように環境変数を設定することで、ネイティブ・ヒープでセグメントを13個使用することが可能です(以下のコマンドはBash、Kornシェルの場合です)。
>export LDR_CNTRL=MAXDATA=0xD0000000@DSA |
Essbaseがアウトライン・キャッシュを作成する際にネイティブ・ヒープが足りないと、
"Essbase(1030201) Cannot create object: null"
|
というエラーがAlphabloxのメッセージ・ダイアログやServer.logに表示され、照会が失敗します。
(補足1) ヒープ・サイズ調整時の注意点
32ビット環境の場合、1つのプロセスが使用できるメモリーは最大4GBです。半分ほどがOSのカーネル部分に割り当てられるので、JVMが使用できるのは約2GBです（セグメントで10個程度）。Javaヒープまたはネイティブ・ヒープのどちらかを大きくしすぎた場合はもう一方が不足するという事態に陥りますので、この双方のサイズを調整し、実環境でのテストによって最適値を見つける必要があります。
(補足2)メモリー使用量測定方法
AIXの場合はpsやsvmonコマンドを使ってプロセスのメモリー使用量を計測することができます。コマンドを使ったチューニングについて詳細は以下をご覧ください。
パフォーマンス・マネージメント・ガイド
また、Javaヒープのメモリー使用量はガーベッジ・コレクションのログをWAS<WAS_HOME>/logs/<node>/SystemErr.logで参照することで測定できます。WAS管理コンソールのJava仮想マシン設定 ( (1)のリンクを参照) で冗長ガーベッジ・コレクションの設定をONにするとSystemErr.logにガーベッジ・コレクションの動作状況が出力されますので、その内容を解析します。その結果によりJavaヒープが足りているか、ガーベッジ・コレクションが頻繁に走ることでパフォーマンス劣化が発生していないかなどがチェック可能です。
2. DataBloxの操作
AlphabloxはDataBloxを使ってデータを照会し、結果をセッションに保持します。複数のJSPからデータを照会するアプリケーションの場合、JSPごとに異なるID（bloxNameも使用している場合は異なるbloxName）のDataBloxを指定すると、セッション・タイムアウトまですべてのDataBloxがキャッシュされることになります。データが多い場合はメモリーを圧迫しパフォーマンス劣化やメモリー不足の原因になりますが、Alphablox Java APIを使った以下のような対処が可能です。
(1) DataBlox共通化
DataBloxはセッションに保存されているので、同じセッション内であればタグで同一のIDを(bloxNameも使用している場合はbloxNameも)指定することで取得可能です。同じデータ・ソースを使用する場合は、DataBloxに以下の例のように新しい照会文をセットし、ResultSetを更新することができます(”myDataBlox”はDataBloxのIDです)。
myDataBlox.setQuery("select * from db2admin.table");
myDataBlox.updateResultSet();
|
この方法は複数のJSPで同じデータ・ソースを使用する場合でセルフォーマットなど各DataBloxに固有の設定があまりない場合に有効です。DataBlox固有のソートなどの設定を引き継がない場合は新しいJSP上でそれをクリアする必要があるので注意してください。
(2) DataBlox.disconnect(true)によるResultSetの削除
セルフォーマットなどの各DataBloxに固有の設定が多い場合は各JSPで異なるID (bloxNameも使用する場合は異なるbloxName) のDataBloxを使用することになります。それぞれのDataBloxに対するResultSetが残存しているとメモリーを圧迫することになりますが、適当なタイミングで以下のメソッドを実行してResultSetを削除することが可能です。
myDataBlox.disconnect(true);
|
上記メソッドの引数が”true”の時はデータ・ソースからの切断と同時にResultSetが削除されます。類似のメソッドとして、以下を実行した場合はデータ・ソースから切断されずResultSetの削除だけが行われます。
myDataBlox.clearResultSet();
|
(3) DataBlox.deleteBlox()によるDataBloxオブジェクトの削除
DataBloxでソートやイベント・フィルターなどDataBlox固有の設定を大量に行っている場合、DataBloxに関連するオブジェクトがすべてセッションに残るのでメモリーが圧迫されることがあります。これを防ぐ手段として、AbstractBlox.deleteBlox()を使いBloxそのものをセッションから削除する方法があります。以下にセッションのすべてのBloxを削除する方法、およびある特定のBloxを削除する方法が書かれています(英語の資料です)。
Deleting a DB2 Alphablox Blox instance using the BloxContext object(US)
※閲覧にはIBM IDの取得が必要ですがどなたでも登録可能です
(補足1) (1), (2)に挙げたメソッドはそれぞれ以下のように目的に応じて使い分けます。
- DataBlox.updateResultSet()
データ・ソースとのコネクションを維持したまま照会結果を更新したい場合
- DataBlox.clearResultSet()
データ・ソースとのコネクションを維持したまま照会結果を消去したい場合
- DataBlox.disconnect(true)
データ・ソースとのコネクションと照会結果を破棄したい場合
同じデータ・ソースで異なる照会結果を取得する場合は、コネクションを維持したまま照会結果を変更することで高速にデータを取得することができます。一方、異なるデータ・ソースに接続し直す場合は、あらかじめ照会結果を削除し切断しておくことでメモリーやコネクションを節約できます。
（補足2）ここに挙げた項目は(1)が最も簡単であり、(2), (3)は処理のタイミングの考慮を必要とするのでやや難しい内容です。どの手段を適用するかはアプリケーションの実装方針によります。
3. クラスターによるJVM分割
1.JVMヒープ調整に書いたように、32bit環境で一つのJVMが使用できるメモリーは2GB程度です。Alphablox 8.4は水平クラスター、垂直クラスターの双方をサポートしていますので、チューニングを行ってもなおメモリーが不足する場合は、JVMを複数に分ける方法を検討可能です。プロセスはアプリケーション・サーバーごとに別なので、おおよそ 2GB × アプリケーション・サーバー数 のメモリーを使用することが可能になります。
(1) 水平クラスターによる負荷分散
複数の筐体に導入されたWAS上でそれぞれアプリケーション・サーバーを作成し、WAS Network Deploymentによりすべてのアプリケーション・サーバーを管理する構成方法です。各アプリケーション・サーバー上にデプロイされたAlphabloxが一つのレポジトリーを共有しながらそれぞれの筐体のJVM上で稼働するので、CPUおよびメモリー使用量の負荷分散が可能となります。
(2) 垂直クラスターによる負荷分散
一筐体のWASに複数のアプリケーション・サーバーを作成し、WAS Network Deploymentによりすべてのアプリケーション・サーバーを管理する構成方法です。各アプリケーション・サーバー上にデプロイされたAlphabloxが一つのレポジトリーを共有しながらそれぞれのJVM上で稼働するので、メモリー使用量の負荷分散が可能となります。
以上に挙げたように、水平クラスターまたは垂直クラスターによりサーバーの負荷分散が可能です。Alphabloxのクラスター環境導入の詳細については以下の資料をご覧ください。
WebSphere® クラスター環境での DB2 Alphablox の使用
画面表示パフォーマンス調整法
1. Essbaseアウトライン・キャッシュの事前作成
データ・ソースがEssbaseなどの多次元データベースの場合、Alphabloxはサーバー起動後の初回アクセス時にアウトラインをキャッシュします。また、アウトラインが変更された場合も新たにキャッシュを作成します。よってサーバー起動またはキューブ変更の後の初回アクセスではキャッシュ作成の分だけ照会時間が多くかかり、パフォーマンス劣化の原因となります。
Alphablox 8.4で新規追加されたAlphablox APIである
com.alphablox.blox.repository.DataSource.updateOutlineCache()
を使って事前にアウトライン・キャッシュを作成することにより、この現象を回避することができます。以下にサーブレットを使った具体的なサンプルがあります(英語の資料です)。
Using a timer servlet to automate tasks in DB2 Alphablox like clearing the MSAS connection Pool and rebuilding Alphablox Essbase Outline Caches
前バージョンまではAlphablox起動後のデータ・ソースへの初回アクセス時にアウトライン・キャッシュが作成されていたためパフォーマンス遅延が発生していました。バージョン8.4ではこの点についての改善要望により上記のメソッドが追加され、リンクにあるようにサーブレットを使って事前にキャッシュを作成することが可能になっています。
2. HTTPサーバーによるデータ圧縮
Alphabloxのグリッドでは大量の属性を持つタグで各セルが定義されるため、Alphabloxが生成するHTMLは非常にサイズが大きいものとな ります。照会するデータが大きくなればなるほど生成するHTMLが大きくなるため、 極端に大きいデータの照会によりパフォーマンス劣化が発生することがあ ります。サーバーからクライアントへ送信するデータを縮小する一つの方法として、HTTPサーバーでデータを圧縮する方法があります。IBM HTTP Server 2.0以降では以下の方法によるデータ圧縮がサポートされています。
Apache モジュール mod_deflate
この方法により、サーバーからクライアントへ送信するデータサイズを縮小し、通信量を削減することが可能です（データ圧縮によりパフォーマンスは改善する場合が多いですが、新たにデータ圧縮・展開のオーバーヘッドが発生する点にご留意ください）。
3.データ表示量調整
本書でこれまでに挙げたチューニング方法でパフォーマンス劣化が防げない場合（CPUネックの場合や大量データによるメモリー不足が防げない場合など）、以下の方法で照会するデータ量を調整する必要があります。
(1) データ・ソース設定
Alphabloxのデータ・ソースを作成または編集する際、MAXROW、MAXCOLSの設定が可能です。この設定を行うことにより、表示可能な行数、または列数の最大値を設定することでサーバーリソースの限界を超えた照会を防ぐことが可能です。
（ただしこれらの設定はいったん照会を行った後に行数・列数をカウントし、設定を超過した場合はエラーを返すため、照会そのものは実行されResultSetがいったん作成された後破棄されます。HTML生成を防げるので通信やクライアントの負荷を抑えますが、サーバー側のメモリー消費の節約にはあまり効果がありません）
(2) クライアントで一度に取得するデータ量の調整
GridBloxで多くの行・列を取得した場合、スクロールを行うと一時的に画面がビジー状態になった後データが表示されることがあります。これは一度の照会で取得されるデータがデフォルトで100行、25列と設定されているからです。以下のAlphablox JavaDocのgetFetchWindowRows()などにその情報が載っています。
クラス Grid
このメソッドを使うことで一度にサーバーからクライアントへ送信するデータ量のコントロールが可能です。画面操作のパフォーマンスを最大限に良くするためにはGridFetchRows, GridFetchColumnsの値を照会文の結果の行数・列数より大きくし、スクロール時に画面がビジーになることを防ぎます。逆にポータブルデバイスでの通信など細い回線でデータを取得する際はこれらの値を照会文より小さくし、クライアントで一度に取得するデータを減らすことで画面表示にかかる時間を短くします。
具体的な設定方法を以下に示します ("myPresentBlox"はPresentBloxのIDです）。
GridBrixModel gridBrixModel = myPresentBlox.getPresentBloxModel().getGrid();
gridBrixModel.setFetchWindowRows(50);
gridBrixModel.setFetchColumnOverlap(1);
gridBrixModel.setFetchWindowColumns(20);
|
(3) 照会する行数、列数の調整
(1), (2)がパフォーマンス向上の助けにならない場合、初期表示のデータを減らすことで照会結果を小さくし、その結果、画面表示を高速化することが可能です。
DB2に対するSQLであれば、以下のように照会する行数を減らすか、照会する行・列を限定するようなSQLに変更します。
SELECT * from db2admin.table fetch first 100 rows only
|
EssbaseのようなMDBの場合も同様に、初期表示の照会文を変更して、例えば世代を1から4まで取得していたところを1から3までに変更する、などの方法をとります。初期表示のデータ量を減らすことでユーザビリティー上の問題がある場合は、後から簡単にメンバーを追加できるような部品を作成することも検討可能です。初期表示はすべての部品を取得、生成するため最も時間がかかりますので、画面がいったん表示された後からデータを取得し直す方法は一回の操作による待ち時間を減らすという意味で有効です。
まとめ
本ガイドにあげたパフォーマンス・チューニング方法は多くがAlphabloxに特化した内容です。WASなどのアプリケーション・サーバーでアプリケーションを動かす場合やDBにアクセスする場合、一般的なJ2EEアプリケーションと同様にアプリケーション・サーバーやDBなどのパフォーマンス・チューニングを行うことも重要です。ボトルネックがどこにあるかは環境ごとに違いますので、それぞれの環境に合ったパフォーマンス・チューニングを実施することをお勧めします。
参考文献
著者について  | | | 福井 清香はソフトウェア開発研究所のエンジニアで、Business Intelligenceの分野におけるプロジェクトでの開発・支援業務を担当しています。 |
記事の評価
| 
