JRun サポートセンター

JRun4: 反応のない JRun サーバのための一般的なトラブルシューティング テクニック

JRun サーバがハングしている、あるいはクラッシュした状態になる数多くの条件と、その問題の原因を分離するのを支援するために使われる数多くのテクニックがあります。このテックノートはこれらの条件を検討し、何が、そして何故起こっているかをより理解するために役立つトラブルシューティング テクニックのチェックリストを提供します。

1. メトリクス ロギング
2. JVM ヒープ サイズ
3. クライアント リクエスト スレッド
4. JVM 問題
5. コンテナ中のスレッド デッドロック
6. システム リソースが低い

メトリクス ロギング

メトリクス ロギングは JRun で提供される重要なモニタリング メカニズムです。それは Web サーバと JRun コンテナ間のコネクションに関する統計情報を得ることができます。これらの統計は取り扱われるリクエストの数、リクエストを取り扱うために利用可能なスレッドとメモリ利用のようなデータを含みます。期間中に JRun がハングしたように見える時、この情報は JRun に送信されるリクエストのボリュームの決定を支援し、メモリ利用傾向を提供します。JRun が無反応の間、増加するリクエストとスレッドはアプリケーション内で並列性問題を示すことがあります。空きメモリ量の減少は過度のオブジェクト作成やガベージ コレクション チューニングに関連した問題を示すことがあります。

メトリクス ロギングを利用可能にするには、サーバの jrun.xml 構成ファイルから以下のセクションを探し、コメントを外してください:

<!-- ============================================ -->
<!-- This Service provides metrics information    -->
<!-- ============================================ -->
<!-- To enable metrics: uncomment this service and
 in LoggerService set metricsEnabled to true -->


<!--
<service class="jrunx.metrics.MetricsService" name="MetricsService">
<attribute name="bindToJNDI">true</attribute>
</service>
-->

次 (jrun.xml で) に、metricsEnabled プロパティを "true" にセットし、metricsLogFrequency に適切な値 (これはログ ファイル エントリ間の秒単位の時間間隔です) をセットしてください:

...

<service class="jrunx.logger.LoggerService" name="LoggerService">
<attribute name="errorEnabled">true</attribute>

<attribute name="warningEnabled">true</attribute>
<attribute name="infoEnabled">true</attribute>
<attribute name="debugEnabled">false</attribute>
<attribute name="metricsEnabled">true</attribute>
<attribute name="metricsLogFrequency">10</attribute>

<attribute name="metricsFormat">Web threads (busy/total):
  {jrpp.busyTh}/{jrpp.totalTh} Sessions: {sessions}
  Total Memory={totalMemory} Free={freeMemory}</attribute>
...

以下の例はこの形式のログ メッセージを示します:

JRun メトリクス ロギングに関する詳細については JRun 管理者ガイド の第 7 章 ("コネクション モニタリング") をご参照ください。

JVM ヒープ サイズ

ヒープは JVM (JVM 内で実行する JRun とアプリケーションの両方) に割り当てられるメモリの量です。ヒープ サイズはスタートアップ時に JVM プロセスに渡されるパラメータによって制御され、可変の最大サイズに従属します。アプリケーションとユーザの数に依存して、JVM に割り当てられるメモリを使い果たす可能性があります。それが発生する場合、JVM 引数を調整することによってヒープ サイズを増加することができます。

適切なヒープ サイズを設定すると、全体のシステム パフォーマンスに肯定的なインパクトを与えることができます。大きなヒープは比較的数多くのオブジェクトを含むことができるので、ガベージ コレクションはそれほど頻繁には要求されません。しかし、GC が大きなヒープ上で実行する時、長い時間がかかり、顕著にアプリケーション応答時間に負の影響を及ぼすかも知れません。Sun からの JDK バージョン 1.4.x を使っている場合、新しい GC オプションとメモリ アロケーション スイッチを利用することができます。詳細については、以下をご参照ください:

• Java Options For Garbage Collection
  
• Improving Java Application Performance and Scalability
  

特定のアプリケーションの最適な設定を決定するために、異なる最大ヒープ サイズでテストを試みることはよい考えです。

JVM ヒープ サイズを変更するには、JVM に渡されるコマンド ライン引数を変更してください。これは {JRun_home}/bin ディレクトリの jvm.config ファイルを変更することによって実行します。例:

java.args=-Xmx128M -Xms32m

• -Xmx は JVM ヒープ (この例では 128MB) に割り当てるメモリの最大量を示します。
• -Xms はスタートアップ時 (この例では 32MB) にヒープに割り当てるメモリの量を示します。

適切なヒープ サイズの設定に関する付加情報については以下の JRun テックノートで見つけることができます:

• JRun: java.lang.OutOfMemoryエラー (テクニカルノート 17470)

Note: アプリケーション開発者がこのランタイム条件がアプリケーション コーディングの結果でないことを保証するために、高メモリ使用の潜在的な原因を調査すること(JProbe または OptimizeIt のようなプロファイリング ツールを使用)が大いに推奨されます。

クライアント リクエスト スレッド

入ってくるあらゆるリクエストはJRun スレッドによってバインドされ、管理されます。 JRun ハンドラ スレッドの数は可変で、外部 Web サーバ ("jrpp") スレッドと JRun Web サーバ スレッド ("web") の両方を含むかも知れません。クライアント リクエストの数が利用可能なスレッドの数を上回る場合、リクエストはキューに入れられ、ユーザはサーバからの応答の受け取りが遅延することを経験するかも知れません。リクエストの数が利用可能なハンドラ スレッドの数をかなり上回る場合、リクエストはキューに入れられず、完全に削除されるかも知れません - JRun がハングしたように見える

アプリケーションが高リクエスト ボリュームを取り扱う場合、さらに JRunProxyService (jrun.xml 構成ファイル中の) ActiveHandlerThreads と MaxHandlerThreads 設定を変更することができます。熟考したボリュームに基くパフォーマンス負荷テストを実行し、これらのパラメータに従って調整することは常に良い考えです。これは通常のスレッディング アクティビティと異常なアクティビティを区別するのに役立ちます。強固なパフォーマンス ベースラインを最初に確認せずにパラメータ値を変更することは良い考えではありません。

JRun スレッディング パラメータを変更するには、jrun.xml ファイルの JRunProxyService セクションを編集してください:

Web サーバと JRun 間にコミュニケーション問題が存在するかどうか確かめる 1 つのテクニックは内部 Web サーバ (JWS) を使ってリクエストを行うことです。たとえすべての jrpp スレッドが使用中であるとしても、JWS はリクエスト ("web") を取り扱うために異なるポート (デフォルトでは 8100) と異なるスレッド グループを使って応答し続けます。外部 Web サーバへのリクエストが失敗する一方、JWS へのリクエストが働く場合、これは JRun と Web サーバ間にコネクション問題があることを示します。さらにこの条件を検査するために、JRun サーバ (jrun.xml 構成ファイル中の) の メトリクス ロギング を利用可能にしてください。

JVM 問題

JRun またはアプリケーションがハングするように見える場合、これは時に JVM プロセスに関する問題を示します。サーバがハングしている間、JVM プロセスが依然として実行している (オペレーティング システム レベルで) かどうかをチェックしてください。それが実行されていない場合、JVM は停止しています。JRun は JVM が実行されていることをを必要とするので、JRun もユーザ アプリケーションも機能し続けることができません。この場合、JDK をより新しい、あるいは異なるバージョンに切り替えたいかも知れません。新しい JDK のインストールは、比較的速くて単純な手続です。新しい JDK の正確な位置を指すために、jvm.config ファイル中の java.home プロパティが更新されることを必要とします:

新しい JVM は Sun Java 2 Platform, Standard Edition (J2SE) downloads を含む、数多くの異なるベンダーから得られるかも知れません。

コンテナ中のスレッド デッドロック

J2EE アプリケーション内の多くのコンポーネントはマルチスレッド アクセスを必要とし、その結果、スレッド関連パフォーマンス問題を起こすことがあります (例、同時性、競合条件、デッドロック)。アプリケーション内のスレッド デッドロックが JRun ハングの原因であることは珍しくありません。これを検査する最良の方法はサーバがハングしている間に一連の JVM スレッド ダンプを生成することです (良い経験則では 60 秒間隔で 3～5 回ダンプを生成)。

スレッド ダンプは JVM 内に含まれる各スレッドの現在の状態を表示します。それはネットワーク アクセスでブロックされたスレッド、データベース アクセス、長時間実行しているデータベース クエリ、CORBA サーバ、その他のようなサードパーティ コンポーネントへのアクセスのような他の条件同様に、潜在的なデッドロックを識別するために役立ちます。リモート システムまたはリソースにアクセスしようとする間にスレッドがブロックされる場合、それが実際にアクセス可能 (ネットワーク問題がない、サーバを実行している、他) であることを確認するためにシステムやリソースを調査する必要があるでしょう。

スレッド ダンプを生成し、解釈する方法に関するプラットフォーム固有の情報については以下の JRun テックノートをご参照ください:

JRun Server: スレッド ダンプ/スタック トレース記事に関するテックノート インデックス (テクニカルノート 18362)

システム リソースが低い

時々、ハードウェアはユーザベースによって要求されるパフォーマンスと反応を提供する十分な力を持っていません。システム リソースが枯渇するにつれて、特に運用環境では、競合を最小にするために特定の JRun サービスをオフにすることができます。例えば、メトリクスとデバッグ ロギングは膨大な量のログ ファイル データを生成することができます。大きなログ ファイルはアプリケーション パフォーマンスに負の影響を与え、一部の極端なケースではサーバがハングする原因にもなります。

上記の項目をチェック後、質問あるいは追加の援助が必要であれば、サポート インシデントを開くために Macromedia JRun Product Support にお問合せください。JRun Support Engineer は問題を解決することを支援するために直接働くことができます。JRun Support Engineer にすべてのメトリクス ログとスレッド ダンプ ファイルを提供する準備をお願いします。

関連テクニカルノート

Jrun 3.x：応答のないJrunサーバのトラブルシューティングテクニック (テクニカルノート 17986）
Jrun 3.x : アプリケーションのパフォーマンス低下の診断チェックリスト (テクニカルノート 18058）

追加情報

このテクニカルノートは、米国 Macromedia, Inc. の JRun 4: General Troubleshooting Techniques for an Unresponsive JRun Server(TechNote18744)をもとに作成されました。

株式会社　アイ・ティ・フロンティア にて翻訳されました。