コラム/第7回 JBoss EAP 6 運用管理で押さえておきたい情報

Red Hat

2015年6月15日

第7回 JBoss EAP 6 運用管理で押さえておきたい情報

Red Hat JBoss Middleware

JBoss Enterprise Application Platform 6(以降、JBoss EAP 6)を運用・管理していくにあたり、トラブルが一切無いことが理想ですが、現実は中々そうはいきません。本コラムではJBoss EAP 6 でトラブルが発生する前から押さえておくべき情報、発生した際に押さえておくべき情報について紹介します。

トラブル発生前から抑えておくべき情報

トラブルが発生する前から、あらかじめシステムの稼動情報を押さえておくことは、システム運用において重要なポイントです。平常時から情報を採取しておくことで、トラブル発生時に変異点を見つけやすく、原因特定につながります。
定期的な取得を推奨する情報について、OSの情報、JBoss EAP 6 の情報に分けて、ご紹介します。

(1) OSの情報
ここでは、Red Hat Enterprise Linux(以降、RHEL)を前提に説明します。RHELのリソース状況を取得するコマンドのうち代表的なものを以下に示します。特に、top, sarについては、多くの情報を収集できますので、使用を推奨いたします。 これらのコマンドをcronなど用いて常時取得しておくことがトラブル発生時の調査材料としてとても重要になります。

# 機能 コマンド
1 システム全体のCPU使用率の表示 top、vmstat、iostat、mpstat [-P 番号|ALL]、sar
2 プロセス毎のCPU使用率の表示 top、ps u[ax]
3 負荷平均の表示 top、uptime、w
4 システム全体の物理メモリの使用状況の表示 top、free、vmstat、sar –r
5 プロセス毎の物理メモリ使用率の表示 top、ps u[ax]
6 スワップ領域の使用状況の表示 top、free、vmstat、sar -r、swapon -s
7 スワップイン・アウトの状況表示 vmstat
8 ディスクIO iostat、vmstat、sar –b
9 ネットワークIO netstat -i|-s、sar -n DEV|EDEV
10 プロセスのPID確認 pstree -p、ps [uax]、top、lsof

表 1 取得しておくべきOSの情報

(2) JBoss EAP 6の情報
JBoss EAP 6 の情報について、あらかじめ取得しておくべき内容などをご紹介します。 特に指定の無い限り、JBoss EAP 6のバージョンは、最新の6.4.0(2015/05/20現在)で確認しています。

(i) GCログ
JavaVMのGC(Garbage Collection)の動作状況をログファイルに出力します。システムがスローダウンや一定時間無応答になる場合、GCが原因の可能性があります。このような場合の原因究明に利用します。

本ログを出力するためには、JBoss EAP 6 起動時のJavaVMの引数に表2に示す項目を指定します。

# 項目 内容
1 -verbose:gc GCログを出力する
2 -Xloggc:”ログファイル名” 指定したログファイル名へGCログを出力する
3 -XX:+PrintGCDetails GCの詳細情報を出力する
4 -XX:+PrintGCDateStamps GCログに日時を出力する
5 -XX:+UseGCLogFileRotation GCログをローテーションする
6 -XX:NumberOfGCLogFiles=x ローテーションをxファイル行う
7 -XX:GCLogFileSize=xM GCログサイズがxMBに達した場合、ローテーションを行う

表 2 GCログを出力するJVMパラメータ

この指定は、標準で有効となっています(NumberOfGCLogFiles: 5、GCLogFileSize: 3M)。
standaloneプロファイルの場合、binディレクトリ下のstandalone.confまたはstandalone.shにて指定します。

(ii) サーバログ
JBoss EAP 6 の各サブシステムやJBoss EAP 6 で稼動するJavaアプリケーションから出力されるログファイルです。 正常稼動している状況や、異常が発生した際のエラーメッセージなどが出力されます。
本ログの設定パラメタについて以下に示します。

# 項目 内容
1 handler.FILE.level ログレベル。
(ALL/TRACE/DEBUG/INFO/WARN/ERROR/FATAL/OFF)
2 handler.FILE.append ログファイルを追記書き込みするかどうか。
3 handler.FILE.autoFlush ログ書き込み時ごとにファイルへ出力するかどうか。
4 handler.FILE.suffix 本ログのローテーション時にファイル名に付加するサフィックス。
5 handler.FILE.fileName ログ出力先。
6 formatter.PATTERN.pattern ログのフォーマット。

表 3 サーバログ設定パラメータ

サーバログの設定は、プロファイルディレクトリ下の”configuration/logging.properties”で設定します。

(iii) サブシステムの稼働状況
サブシステムの稼働状況を取得する方法はいくつかありますが、JBoss EAP 6が提供する管理CLI(jboss-cli.sh)を使用すると、コマンドラインでの取得が可能です。今回は、管理CLIを利用した稼働状況の確認方法を紹介します。

① JavaVMスレッドプール情報
稼動しているスレッド数などを確認します。

$ jboss-cli.sh -c —commands="cd/core-service=platform-mbean/type=threading,ls"
# 項目 内容
1 peak-thread-count JBoss EAP 6 起動後からのピークスレッド数
2 daemon-thread-count ライブデーモンスレッドの現在の数
3 thread-count デーモンおよび非デーモンスレッド両方を含むライブスレッドの現在の数

表 4 JavaVMスレッドプールの情報

② JavaVMメモリ情報
メモリの使用状況などを確認します。

$ jboss-cli.sh -c —commands="cd/core-service=platform-mbean/type=memory,ls"
# 項目 内容
1 non-heap-memory-usage JavaVMが利用するヒープ以外のメモリの現在の使用量
2 heap-memory-usage オブジェクトの割り当てに利用するヒープの現在のメモリ使用量

表 5 JavaVMメモリの情報

③ データベースプール情報
データソースのプール情報を確認します。

$ jboss-cli.sh -c --commands="cd /subsystem=datasources/data-source=ExampleDS /statistics=pool/,ls"

データソース名(”ExampleDS”)は実際の使用環境に合わせて変更してください。また、データが取得できない場合、statistics-enabledをtrueに設定してください。

# 項目 内容
1 ActiveCount アクティブな接続数
2 AvailableCount 使用可能な最大接続数
3 AverageBlockingTime プールの排他ロックの取得をブロックするために費やされた平均時間(ms)
4 AverageCreationTime 接続の作成に費やされた平均時間(ms)
5 CreatedCount 作成された接続数
6 DestroyedCount 破棄された接続数
7 InUseCount 現在使用中の接続数
8 MaxCreationTime 接続の作成にかかった最大時間(ms)
9 MaxUsedCount 使用された接続数の最大
10 MaxWaitCount 接続待ちとなったスレッド数の最大
11 MaxWaitTime プールの排他ロックの待機に費やされた最大時間(ms)
12 TimedOut タイムアウトした接続数
13 TotalBlockingTime プールの排他ロックの待機に費やされた合計時間(ms)
14 TotalCreationTime 接続の作成に費やされた合計時間(ms)

表 6 データベースプール情報

トラブル発生後に抑えておくべき情報

続いて、トラブルが発生した後に押さえておくと良い情報を記載していきます。発生前に押さえておくべき情報と合わせて分析し、問題の原因を究明します。

(1) 発生状況の整理
JBoss EAP 6 に限ったことではありませんが、まずは発生状況の整理をする必要があります。これにより発生原因を絞り込んでいきます。場合によってはこれだけでも原因を特定できることもあります。以下の観点で整理してみましょう。

# 項目 内容
1 発生時刻 現象が発生した時刻。複数回ある場合はそれぞれの時刻。
2 発生現象 何をしようとして何が発生しているのか。
どうなるべきで何ができないか。
3 エラー情報 エラーメッセージ、エラーコードなど。
4 他サーバでの発生状況 正常に動作しているか。同じ現象が発生しているか。異なる現象が発生しているか。
5 システム変更有無 現象発生前から、設定変更・バージョンアップ・セキュリティパッチ・ネットワーク変更・他アプリケーションの変更・他サーバの追加など、実施していることはないか。
6 類似現象の有無 これまで同じ様な現象が発生したことがあるか。発生したことがある場合、規則性(一定の手順で発生する。定期的に発生する。など)はあるか。
7 対策結果 問題解決のためになんらかの対策を実施済みの場合、その方法と結果。

表 7 発生状況を整理するポイント

(2) 既存の不具合情報の確認
発生している事象から、OSや関係するソフトウェアに既存の不具合がないかを確認しましょう。RHELの場合はカスタマーポータルのナレッジ情報、コミュニティより入手したオープンソースを利用している場合はコミュニティのBugTrackerから情報を探します。

(3) JavaVMからの情報取得
Javaのコマンドを使用して、Javaプロセスの現在の稼働情報を採取します。

(i) スレッドダンプ
スレッドダンプは、JBoss EAP 6 上のスレッドがデッドロックした場合や、処理がタイムアウトする場合などの調査に利用できます。実行すると、現在のJBoss EAP 6 で稼動するすべてのスレッドの状態と、取得時点でのスタックトレースが出力されます。
スレッドダンプは必ず複数回採取するようにしましょう。採取したスレッドダンプを比較することで各スレッドの変化を見ることができます。採取する間隔は、状況にもよりますが、数秒程度あけて採取しましょう。

まず、JBoss EAP 6 のプロセスIDを調べます。

$ jps
2391 jboss-modules.jar
3456 Jps

次に、JBoss EAP 6 のプロセスIDを引数として、スレッドダンプを出力します。

$ jstack 2391 > thread-dump.txt

(ii) ヒープダンプ
ヒープダンプは、メモリリークや、メモリ不足が発生した場合などの調査に利用できます。実行すると、現在のJBoss EAP 6 が稼動するJavaVMのヒープ内容がダンプされます。
ヒープダンプは取得しただけでは解析が難しいため、jhatコマンドを利用すると良いでしょう。

まず、JBoss EAP 6 のプロセスIDを調べます。

$ jps
2391 jboss-modules.jar
3456 Jps

次に、JBoss EAP 6 のプロセスIDを引数として、ヒープダンプを出力します。

$ jmap -dump:format=b,file=heap-dump.dat 2391
Dumping heap to /home/user/heap-dump.dat ...
Heap dump file created

取得したヒープダンプを指定して、jhatコマンドを実行します。

$ jhat heap-dump.dat
Reading from heap-dump.dat...
(略)
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.

ブラウザからhttp://localhost:7000/にアクセスすると、様々な方法でダンプ内容を解析できます。

最後に

いかがでしたでしょうか。一度トラブルが発生すれば、原因を究明し解決するまでは大変な作業です。そのとき少しでも解決を早めるためには、今回の様な情報が1つでも多く揃っているとが重要です。是非本コラムを参考にしていただき、皆様のシステム運用に役立てていただければ幸いです。

著者紹介

株式会社日立ソリューションズ
カスタマサポートセンタ
加藤 尚樹

Red Hat コンテンツ一覧

関連商品・キーワード