test

Sun Java System Application Server Enterprise Edition 8.2 パフォーマンスチューニングガイド

パフォーマンス

最適なパフォーマンスを得るには、すべての HADB プロセス (clu_xxx_srv) が物理メモリーに収まるようにします。ページングやスワッピングが起こらないようにしてください。同じことが、使用される共有メモリーセグメントにも当てはまります。

共有メモリーセグメントのいくつかはサイズを設定できます。それらのセグメントが小さすぎると、パフォーマンスが低下し、ユーザートランザクションが遅延したり、さらには中止されたりします。セグメントが大きすぎると、物理メモリーが無駄になります。

次のパラメータを設定できます。

DataBufferPoolSize

HADB のデータは、ディスク上に割り当てられたデータデバイスに保存されます。データが処理されるには、そのデータが主メモリーにある必要があります。HADB ノードでは、この用途に共有メモリーの一部が割り当てられます。割り当てられたデータベースバッファーが、処理されるデータに比べて小さいと、多くの処理容量がディスク入出力によって浪費されます。書き込み集約型の操作を行う (たとえば、頻繁に更新されるセッション状態がある) システムでは、ディスク入出力に使用される処理容量が多すぎて要求処理が阻害されないように、データベースバッファーを十分な大きさにしてください。

データベースバッファーは、ファイルシステムのキャッシュに似ています。パフォーマンスを向上させるには、ディスク読み取り操作を待つ必要がないように、できるだけ容量の大きいキャッシュを使用します。データベース全体の内容がデータベースバッファーに収まるようにすれば、最高のパフォーマンスが得られます。しかし、ほとんどの場合、これは実現不可能です。クライアントアプリケーションの作業セットがバッファーに収まることを目標にします。

また、ディスク入出力も調べます。HADB で多数のディスク読み取り操作が実行される場合は、データベースのバッファー容量が不足していることになります。データベースバッファーは、ディスクで使用されるブロックサイズと同じ 16K バイトのブロックに分割されます。HADB では、1 回の入出力操作で読み取り用と書き込み用に複数のブロックがスケジュールされます。

ディスクの使用状況を調べるには、hadbm deviceinfo コマンドを使用します。たとえば、hadbm deviceinfo --details というコマンドを実行すると、次のような出力が表示されます。

NodeNo   TotalSize       FreeSize        Usage
0        512             504             1%
1        512             504             1%

出力の各列の表記の意味は次のとおりです。

DataBufferPoolSize のチューニング

データベースバッファーのサイズを変更するには、次のコマンドを使用します。

hadbm set DataBufferPoolSize

このコマンドを実行すると、変更を有効にするためにすべてのノードが 1 つずつ再起動されます。このコマンドの使用の詳細については、『Sun Java System Application Server Enterprise Edition 8.2 高可用性 (HA) 管理ガイド』の「HADB の設定」を参照してください。

LogBufferSize

HADB では、データの挿入、削除、更新、読み取りなど、データベースを変更するすべての操作が、実行前にログに記録されます。それらの操作が記述されたログレコードは、(タプル) ログバッファーと呼ばれる共有メモリー部分に配置されます。HADB では、これらのログを使用して、トランザクションが中止されたときの取り消し操作、ノードクラッシュ時の復元、およびミラーノード間のレプリケーションが行われます。

ログレコードは、ローカルで処理されてミラーノードに送られるまでは、バッファー内に残っています。ログレコードは、トランザクションの結果 (コミットまたは中止) が確定するまで保持されます。HADB ノードでタプルログの残りが少なくなると、ユーザートランザクションが遅延し、場合によってはタイムアウトになります。

LogBufferSize のチューニング

デフォルト値から開始します。履歴ファイルで HIGH LOAD 情報メッセージを探します。関連するメッセージには必ず、tuple log または log と、発生した内部リソース競合の説明が含まれます。

通常の操作では、ログ領域の使用率は 70 〜 80% と報告されます。領域再生が「低速」と言われるのはこのためです。HADB では、ノードクラッシュが発生時した場合、復旧するためにできるだけ多くのログデータを必要とします。

ログバッファーのサイズと使用状況に関する情報を表示するには、次のコマンドを使用します。

hadbm resourceinfo --logbuf

たとえば、次のような出力が表示されます。

Node No.     Avail         Free Size
0            44            42
1            44            42

出力の各列の表記の意味は次のとおりです。

InternalLogbufferSize

ノード内部ログ (nilog) には、ローカルノードの物理的 (論理的の反対、行レベル) 操作に関する情報が記録されます。たとえば、ディスクブロックの割り当てと解放、および B ツリーブロックの分割があるかどうかに関する情報が提供されます。このバッファーは、共有メモリーに保持され、定期的にディスク (個別のログデバイス) との照合も行われます。このバッファーのページサイズおよび関連付けられているデータデバイスのサイズは 4096 バイトです。

大きい BLOB には、必然的に多くのディスクブロックが割り当てられるので、ノード内部ログの負荷が大きくなります。nilog の各エントリは小さいため、通常はこれが問題になることはありません。

InternalLogbufferSize のチューニング

デフォルト値から開始します。履歴ファイルで HIGH LOAD 情報メッセージを探します。関連するメッセージには、nilog と、発生した内部リソース競合の説明が含まれています。

ノード内部ログバッファーの情報を表示するには、次のコマンドを使用します。

hadbm resourceinfo --nilogbuf

たとえば、次のような出力が表示されることがあります。

Node No.     Avail         Free Size
0            11            11
1            11            11

nilog バッファーのサイズを変更するには、次のコマンドを使用します。

hadbm set InternalLogbufferSize

hadbm を実行すると、変更を有効にするためにすべてのノードが 1 つずつ再起動されます。このコマンドの使用の詳細については、『Sun Java System Application Server Enterprise Edition 8.2 高可用性 (HA) 管理ガイド』の「HADB の設定」を参照してください。

注 –

nilog バッファーのサイズが変更されると、関連付けられているログデバイス (データデバイスと同じディレクトリにある) のサイズも変更されます。内部ログバッファーのサイズは、内部ログデバイスと同じサイズにします。hadbm set InternalLogBufferSize コマンドによって、この要件を確実に満たします。このコマンドを実行すると、ノードが停止され、InternalLogBufferSize の値が増やされ、内部ログデバイスが再初期化され、ノードが再起動されます。この一連の操作は、すべてのノードに対して実行されます。

NumberOfLocks

行レベル操作ごとに、データベースのロックが必要です。ロックは、トランザクションがコミットまたはロールバックされるまで保持されます。ロックは行 (BLOB チャンク) レベルで設定されます。つまり、大きなセッション状態には多数のロックが必要になります。ロックは、主ノードとミラーノードの両方の操作に必要です。したがって、1 回のBLOB 操作で、2 つの HADB ノードに同じ数のロックが割り当てられます。

テーブルの再断片化が実行される場合、HADB には追加のロックリソースが必要です。そのため、通常のユーザートランザクションが獲得できるのは、割り当てられたロックのうち半分だけです。

利用可能なロックオブジェクトが HADB ノードにない場合は、ログファイルにエラーが書き込まれます。詳細については、『Sun Java System Application Server Enterprise Edition 8.2 Error Message Reference』の第 14 章「HADB Error Messages」を参照してください。

ロック数の計算

必要なロック数を計算するには、次のパラメータを見積もります。

注 –

ロックは、主レコードとホットスタンバイレコードの両方で保持されます。したがって、挿入、更新、および削除の操作では、1 回のトランザクションに、レコード数の 2 倍のロック数が必要です。読み取り操作では、主レコードのロックのみが必要です。再断片化と二次インデックスの作成が行われるときには、関係するテーブルのログレコードも、作成されるフラグメントレプリカに送信されます。その場合、1 回のトランザクションに、関係するレコード数の 4 倍のロック数が必要です (すべてのクエリーが、その影響を受けるテーブルに対するものと想定した場合)。

サマリー

再断片化が実行される場合、設定するロック数は次のようになります。

Nlocks = 4x (y/7000 + 2) = 2xy/3500 + 2x

それ以外の場合、設定するロック数は次のようになります。

Nlocks = 2x (y/7000 + 2) = xy/3500 + 4x

NumberOfLocks のチューニング

デフォルト値から開始します。Application Server のログファイルで、指示されたエラーコードを持つ例外を探します。再断片化が行われていない通常の操作では、クライアントアプリケーションはロック数の半分しか使用しないこともあります。

割り当てられたロック数と使用中のロック数に関する情報を得るには、次のコマンドを使用します。

hadbm resourceinfo --locks

たとえば、このコマンドを実行したときに、次のような出力が表示されることがあります。

Node No.     Avail             Free            Waits
0            50000             50000           na
1            50000             50000           na

タイムアウト

ここでは、パフォーマンスに影響するいくつかのタイムアウト値について説明します。

JDBC 接続プールのタイムアウト

これらの値は、サーバーがタイムアウトになるまでにプールからの接続を待機する時間を制御します。ほとんどの場合はデフォルト値で十分です。チューニングの詳細については、「JDBC 接続プールのチューニング」を参照してください。

ロードバランサのタイムアウト

次に、パフォーマンスに影響する可能性がある値のいくつかを示します。

ロードバランサプラグインの設定の詳細については、『Sun Java System Application Server Enterprise Edition 8.2 高可用性 (HA) 管理ガイド』の「ロードバランサの設定」を参照してください。

HADB のタイムアウト

sql_client タイムアウト値が、パフォーマンスに影響する場合があります。