HADB パフォーマンスの問題

パフォーマンスは HADB に対するトランザクションが、遅延、または、強制停止した時に影響します。こうした状況の一般的な原因は、システムリソースの不足によるものです。いくつかのトランザクションに対する、５秒間以上のウェイトが原因となり、強制停止します。いくつかのノードが失敗することも又原因となり、そのノードで実行中のトランザクションクラッシュ時に、強制停止します。いくつかの二重の失敗は、 (ミラー両方の失敗) HADB を使用不可能にします。それら失敗の原因は、一般的には HADB の履歴ファイルから見つけ出すことができます。

問題を切り分けする為には、次のことに着眼してください。 :

• CPU 、又は、メモリーリソース不足、あるいはスワッピングが多発しているか ?
• 競合しているディスクがあるか ?
• HADB データデバイス領域が不足しているか ?
• 他の HADB リソースが不足しているか ?

CPU 、又は、メモリーリソース不足、あるいはスワッピングが多発しているか ?

• 解説
  \このケースでは、ノードの再起動、又は、二重の失敗は、 "プロセスが x 秒間ブロックされた、最長ブロック時間は、 2.500000 秒" に起因しており、 x は、そのプロセスがブロックされた時間の長さを示していて、 そしてその時間が 2.5 秒よりも長いと言うことです。
  \HADB ノード管理プロセス (NSUP/clu_nsup_srv) が監視した、最終時刻からの時間経過を記録します。持続時間が exceeds a 指定されている最大 ( デフォルト 2500ms) を超えた場合、 NSUP は、そのプロセスがブロックされた時間が長すぎるため終了し、そして、ノードを再起動します。
  \NSUP が 2.5 秒を超えてブロックされる原因は、ノードの再起動です。もし、ミラーノードが、同一ホスト上に配備されているのであれば、高い確率で、二重の障害を引き起こす可能性があります。また同時に、ミラーホスト上のブロッキングの発生も、二重の障害を引き起こすでしょう。
  \その状況は、他のプロセスが存在するとき、著しく発生するようです。 – たとえば、 共存構成における – CPU 又は、メモリが競合するシステム上で、多数のスワッピングの発生や、複数のプロセスが、再スケジュールされるような、多重ページの欠点などが揚げられます。
  \又、 NSUP がブロックされることは、システムクロックを調整する妨げによる原因になりえます。

• 解決方法
  \安全を保障するには、 HADB ノードが、十分なシステムリソースを取得することです。時刻同期デーモンが、長時間 (2 以上とならない ) に及ばないことも又、安全を保障します。

競合しているディスクがあるか ?

• 解説
  \ディスクの競合は、 HADB が、履歴ファイルに書き込むことと同様に、ユーザーデータを、ディスクデバイスへ、 読み込み / 書き込みする上で、悪影響を及ぼす可能性があります。深刻なディスクの競合は、ユーザーのトランザクションを、遅延、または、停止することが想定されます。ノードの再起動が原因である、履歴ファイル書き込みの遅延は、更に悪いことに、二重の障害を引き起こすことが想定されます。
  \ディスク競合は、 OS のディスクデータの利用に対する、デバイスログと履歴ファイルからの、ディスク I/O の監視によって、確認できます。履歴ファイル書き込み遅延は、 HADB 履歴ファイルに書き込まれます。これは、 "NSUP BEWARE timestamp Last flush took too long (x msecs)." 警告メッセージによって確認できます。
  \この警告は、ディスク I/O に時間がかかりすぎていることを示しています。もし遅延が 10 秒を超えた場合、ノードスーパーバイザはエラーメッセージによって、トランザクション処理を再起動します。 :\\\\\~UWC_TOKEN_START~1278691906832~UWC_TOKEN_END
  \このメッセージは、トランザクション処理の処理感覚チェックをノードスーパーバイザが要求している為に、トランザクション (clu_trans_srv) 処理が、ほかの処理によって ( 履歴ファイル出力待ち等 ) ビジー状態であることを示しています。この原因は、 nsup が、トランザクションが消滅してから、それを再起動していることを信頼しているからです。
  \オペレーティングシステムが、 莫大な量のプロセス (HADB ノードと、他のプロセスとの共同構成が多い ) によって、過重負荷を与えられている場合、 I/O 処理のスケジュールは遅延することが想定されます。HADB が、 I/O 処理の遅延に関連している場合、 HADB ノードは次の履歴ファイルを書き込みます。 "HADB warning: Schedule of async <read,write\> operation took ..."
  \この問題は、とりわけ Red Hat AS 2.1 上では、多重 HADB ノードが同一ホスト上に配置されていて、全てのノードが、それらデバイスが配置されている同一のディスクを使用している場合に、記録されています。

• 解決方法\\\\\ノードによって使用されるデバイスを配置し、ノードごとにひとつのディスクが使用されるようにてください。そのノードがひとつ以上のデータデバイスを持っているにも関わらず、ディスク競合が記録された場合は、データデバイスをほかのディスクへ移動して下さい。履歴ファイルに対しても、同様に適応してください。
  \全てのデータ、及びログデバイスと、履歴ファイルが、ローカルディスク ( NFS マウント、あるいは、リモートにマウントされたディスクではない ) 上に存在するか確認してください。
  \未だ尚監視ツールが、 HADB ディスク上の競合を表示する場合は、データバッファプールサイズが、上昇している可能性があります。

HADB データデバイス領域が不足しているか ?

• 解説
  \トランザクション失敗の理由付けが出来るものの 1 つは、データデバイス領域外で実行することです。この状況が発生する場合、 HADB は、履歴ファイルへ警告を書き込みすることが想定され、行の挿入、若しくは、更新を試行したトランザクションが、停止します。
  \代表的なメッセージは、次のとおりです。 :\\\\\~UWC_TOKEN_START~1278691906833~UWC_TOKEN_END
  \サムの一般的なルールは、ユーザーデータボリュームの空間を、最低４回はデータデバイスに持つ必要があると言うことです。ガイドに戻って、付加説明を参照してください。

• 解決方法 1
  \データデバイスサイズを大きくするには、次のコマンドを利用します。 :\\\\\~UWC_TOKEN_START~1278691906834~UWC_TOKEN_END
  \この解決方法は、全てのノード上にある、 HADB データデバイスによって利用されている、利用可能な動作中のディスク空間が、存在することを要求しています。
  \HADBM は、データベースノード毎に、自動的に再起動します。

• 解決方法 2
  \HADB の停止と消去を行い、 より多くのノード、より大きなデータデバイス、あるいはノード毎のデータデバイスに、新しいインスタンスを作成してください。残念ながらこの解決方法の利用は、 GlassFish アプリケーション・サーバーによって作成された、永続的なデータやスキーマを、消去してしまいます。この手続きについてのより詳しい情報として、管理者ガイドを見てください。

他の HADB リソースが不足しているか ?

HADB ノードが起動された時、 それは割り当てられます。 :

• 永続的に固定化されたサイズで配分された、メモリーセグメント
• 固定化されたサイズの、データ内部構造

HADB ノードが、リソース外で実行している場合、それは、トランザクションの遅延、若しくは、停止を引き起こします。リソース使用情報は、ミラーノードの両方に適用されるので、一方のノードが遅延、あるいは停止すると、ミラーノードでも障害が発生した様に見えます。

トランザクションが、繰り返し遅延しタイムアウトすると、クライアントへ、エラーメッセージを返信します。もしタイムアウトしなかった場合、この状況は、システムリソース不足による、クライアントへの処理終了までの間のパフォーマンス劣化として明白です。

それら問題は、高負荷な状況で、頻繁に発生します。詳細については、高負荷の問題を参照ください。

^Back

日本語翻訳: jack spallaw

英文 (翻訳したバージョン: 49)