Comments
Description
Transcript
問題判別 WASV6 Workshop による基幹システム設計
WASV6による基幹システム設計Workshop
問題判別
Agent
WebSphere Application Server問題判別
Edge Component問題判別
Rational Developer問題判別
WAS
（WebSphere Application Server）
問題判別の基本手順
問題発生
• プロセスの生存確認
• 各コンポーネントの応答調査
• ログメッセージの確認
等
問題の種類 / 発生箇所の特定
対応
・パッチの適用
・設定の変更
・アプリの修正
…
問題原因の究明
採集資料（ログやトレース）の分析
既知の問題
再現手順の調査
さらなる資料の採集・分析
質問・採集した資料の送付
サポートセンターに連絡
既知情報の
収集
情報の保存
修正の適用の必要性
WASの瑕疵が原因のトラブルでは，
最終的な解決方法は「Fixの適用」となるケースが大部分
「運用による」回避は非現実的な場合が多い
WASのFixについて，必ずしも単独のFixが提供されるとは限らない
「Fix Packの一部として提供」となるケースや，
「最新のFix Pack＋単独Fixとして提供」となるケースも多い
特定のRefresh Pack/Fix Packレベルでの運用の継続は難しい
重要なシステムについては，
サーバー構築時にFix適用の計画についても策定しておくことが望ましい
全体のサービスを継続したままFix適用ができるトポロジー
テスト環境 ＋ 本番環境
Fix適用時に実施するテストの自動化の検討
参考：WAS 6.0で提供される修正について
Refresh Pack
New Function追加や対応プラットフォーム追加など
V.R.M.Fのバージョン表記のMが増加する
WAS 5.0/5.1の「Fix Pack」に相当
Fix Pack
Defect対応の修正のみが含まれる
V.R.M.Fのバージョン表記のFが増加する
Fが奇数のものはOpen系用，偶数のものはzOS用
WindowsやLinux系などでは6.0.2.1の次は6.0.2.3
WAS 5.0/5.1の「Cumulative Fix」に相当
WASのログ
Node単位のログ
IBM保守ログ(activity.log)
JVMログに詳細な情報を追加したログ。
ログ・アナライザーを用いて読み取る。
プロセス単位のログ
JVMログ (SystemOut.log / SystemErr.log)
ネイティブ・コードやJVM自身の出力が書き込む情報の出力先
JVMのverboseGC出力はnative_stderr.logに記録される。
FFDCログ (<process_name>_<timestamps>.log)
JavaのSystem.outおよびSystem.errへの出力を独立したログファイルに転送したもの
WAS自身のメッセージの対部分が記録される，ログ解析の基本
循環ログの指定により，時間・サイズによる世代管理が可能
プロセスログ (native_stdout.log / native_stderr.log)
WAS 5.0/5.1から
ログの種類・内容は
変更なし
First Failure Data Captureとはエラー情報を発生時に自動記録する機能。
サポートセンター、開発部門が障害対応時に見るログ。
ユーザーによる構成はできない。
HTTPトランスポートログ (http_access.log / http_error.log)
ASのWebコンテナのHTTPトランスポートに対するアクセスを記録するログ。
管理ポートに対しても記録が可能。
デフォルトでは取得されない。
HTTPトランスポート・ログの有効化
ログの格納ディレクトリ
WAS 5.0/5.1から
一部のログファイルが
プロファイルディレクトリの下に移動
導入ディレクトリの/logs
•インストール・Fix適用のログ
• プロファイル管理コマンドのログ
プロファイルディレクトリの/logs
•activity.log
等
logsの下の/ffdc
•FFDCログ
logsの下のサーバー名ディレクトリ
•JVMログ
•プロセスログ
•HTTPトランスポートログ 等
ログの考慮点
JVMログのログ回転
足りない！
デフォルトがサイズ1M × 1世代バックアップ
サイズで回転
ディスク容量の見積もりが事前に可能
出力量が多すぎる場合には，必要なログが残らないことも
要件に
応じて判断
時間で回転
少なくとも10M × 10世代バックアップを
バックアップの世代数は20が最大
一定時間のログが確実に残る
ログディレクトリのディスク使用量の事前の見積もりが難しい
「startServer.sh <server名> -script」で作成したスクリプトで
WASを起動した場合はプロセスログが残らない
生成されたスクリプトを手動で修正して
「Launch Command」の行の最後にリダイレクトを追加する必要がある
“ >> $LOGDIR/native_stdout.log 2>> $LOGDIR/native_stderr.log “のような内容を追加
サーバーの「Java仮想マシン」の構成を変更した場合には
スクリプトの再作製と再編集が必要
Verbose GC （冗長ガーベッジコレクション）
全てのテスト環境・本番環境で
有効に設定することを推奨
サーバーのヘルスチェックに有用な情報を取得できる
Verbose GCの出力が，解析に必須の問題がある
ログの出力量や出力負荷も常時有効で問題ない
「サーバー名」→「プロセス定義」→「Java仮想マシン」で
「冗長ガーベッジ・コレクション」で有効にする
プロセスログにGCの情報を記録
Allocation Failure（ヒープ割り当て失敗）の情報
GCの開始時刻，実行内容，メモリ開放結果，経過時間
ヒープ，内部バッファのサイズ調整
出力例
<AF[9]:
<AF[9]: Allocation
Allocation Failure.
Failure. need
need 528
528 bytes,
bytes, 969
969 ms
ms since
since last
last AF>
AF>
<AF[9]:
managing
allocation
failure,
action=2
(0/52427264)>
<AF[9]: managing allocation failure, action=2 (0/52427264)>
<GC(9):
<GC(9): GC
GC cycle
cycle started
started Tue
Tue Nov
Nov 22
22 16:53:08
16:53:08 2005
2005
<GC(9):
freed
11104048
bytes,
21%
free
<GC(9): freed 11104048 bytes, 21% free (11104048/52427264),
(11104048/52427264), in
in 166
166 ms>
ms>
<GC(9):
mark:
150
ms,
sweep:
16
ms,
compact:
0
ms>
<GC(9): mark: 150 ms, sweep: 16 ms, compact: 0 ms>
<GC(9):
<GC(9): refs:
refs: soft
soft 00 (age
(age >=
>= 32),
32), weak
weak 0,
0, final
final 62,
62, phantom
phantom 0>
0>
<AF[9]:
managing
allocation
failure,
action=3
(11104048/52427264)>
<AF[9]: managing allocation failure, action=3 (11104048/52427264)>
<GC(9):
<GC(9): need
need to
to expand
expand mark
mark bits
bits for
for 61602304-byte
61602304-byte heap>
heap>
<GC(9):
expanded
mark
bits
by
143360
to
<GC(9): expanded mark bits by 143360 to 962560
962560 bytes>
bytes>
<GC(9):
<GC(9): need
need to
to expand
expand alloc
alloc bits
bits for
for 61602304-byte
61602304-byte heap>
heap>
<GC(9):
expanded
alloc
bits
by
143360
to
<GC(9): expanded alloc bits by 143360 to 962560
962560 bytes>
bytes>
<GC(9):
<GC(9): need
need to
to expand
expand FR
FR bits
bits for
for 61602304-byte
61602304-byte heap>
heap>
<GC(9):
expanded
FR
bits
by
286720
to
<GC(9): expanded FR bits by 286720 to 1925120
1925120 bytes>
bytes>
<GC(9):
<GC(9): expanded
expanded heap
heap by
by 9175040
9175040 to
to 61602304
61602304 bytes,
bytes, 32%
32% free>
free>
<AF[9]:
completed
in
201
ms>
<AF[9]: completed in 201 ms>
<GC[9]:
<GC[9]: Expanded
Expanded System
System Heap
Heap by
by 65536
65536 bytes
bytes
GC Collector
IBM JDKのverbose:gcをグラフ化するGUIベースの問題判別ツール
alphaWorksからダウンロード可能
http://www.alphaworks.ibm.com/tech/gcdiag
以下のような情報をグラフ化可能
GCの所要時間
GCの間隔
フェーズ別時間
（mark/sweep/Compaction)
JavaHeapの推移状況
AllocationFailureのサイズ
ログ詳細レベルの変更（旧トレース仕様の指定）
トレース仕様の指定方法・ログレベルの指定がWAS 5.0/5.1から変更に
例： com.ibm.ws.webcontiner.*=EntryExit=enabled
V6では，12段階のトレース仕様のレベルから選択。トレースとログレベルを同時に指定可能。
例： com.ibm.ws.webcontiner.*=finer
V5までは，Event/EntryExit/Debugごとに有効無効を指定。またトレースとログレベルの指定は別。
fatalからdetailまではメッセージ出力の制御のために使用
offに指定するとJVMログにはWASのメッセージが一切でなくなる！
offからdetailまでの指定によりログに出力されるメッセージのレベルを制御できる
fine/finer/finestがログ出力のために使用
fine以上のトレース仕様に指定されたコンポーネントがあるときにのみトレースの出力が行われる
トレース仕様
off
fatal
severe
warning
audit
info
config
detail
fine
finer
finest
all
日本語
オフ
致命的
重大
警告
監査
情報
構成
詳細 - 低
詳細 - 中
詳細 - 高
詳細 - 最高
すべて
WAS V5までのレベル
off
fatal
error
warning
audit
info
Event
Event + EntryExit
Event + EntryExit + Debug
all
ログ・フォーマット
基本フォーマット（デフォルト）
[05/11/23
[05/11/23 18:36:13:266
18:36:13:266 JST]
JST] 0000000a
0000000a AdminInitiali
AdminInitiali AA
タイムスタンプ
スレッドID
コンポーネント短縮名
ログ・メッセージタイプ
F
E
W
A
I
C
D
O
R
Z
-
ADMN0015I:
ADMN0015I: 管理サービスが初期設定されます。
管理サービスが初期設定されます。
fatalメッセージ
errorメッセージ
warningメッセージ
auditメッセージ
infoメッセージ
configメッセージ
configメッセージ
detailメッセージ
detailメッセージ
アプリケーションのSystem.outへの出力
アプリケーションのSystem.errへの出力
タイプ不明
タイプ不明
メッセージID
メッセージ・テキスト
トレース・タイプ
>
<
1
2
3
Z
-
methodの開始
methodの終了
fine/eventトレース
fine
finerトレース
finerトレース
finest/debug/dumpトレース
finest
タイプ不明
タイプ不明
トレース・テキスト
HTTPサーバーおよびWAS Plug-inのログ
HTTP Serverのログ（Apache/IBM HTTP Serverの場合）
アクセスログ
エラーログ
LogFormat/CustomLogディレクティブによって詳細を指定可能
commonより情報の多いcombinedログ・フォーマットの指定を
経過時間なども追加で記録するようにすると問題発生時の解析の助けに
ErrorLogディレクティブで場所を，LogLevelディレクティブ記録レベルを指定
WAS Plug-inのログ
http_plugin.log
plugin-cfg.xmlのLog要素で詳細を指定可能
Name属性でファイル名，LogLevel属性で記録レベルを指定
Plug-in内の動作が記録される
HTTPサーバーからアプリケーションサーバーの呼び出しに失敗する場合に
最初に確認するログファイル
LogLevel属性をTraceに指定することでPlug-in・WAS間の通信の詳細を取得可能
要求メトリックを使用するとPlug-inのログにサーブレット呼び出しの統計情報を載せることが可能
要求メトリックの出力例
[Fri
[Fri Aug
Aug 12
12 00:57:18
00:57:18 2005]
2005] 000012a0
000012a0 00000a28
00000a28 -- PLUGIN:
PLUGIN: parent:ver=1,ip=10.7.71.52,time=1123773747200,
parent:ver=1,ip=10.7.71.52,time=1123773747200,
pid=4768,reqid=0,event=1
current:ver=1,ip=10.7.71.52,time=1123773747200,pid=4768,reqid=0,event=1
pid=4768,reqid=0,event=1 - current:ver=1,ip=10.7.71.52,time=1123773747200,pid=4768,reqid=0,event=1
type=HTTP
type=HTTP detail=/servlet/perfservlet
detail=/servlet/perfservlet elapsed=4318
elapsed=4318 bytesIn=0
bytesIn=0 bytesOut=1238
bytesOut=1238
パフォーマンスのモニタ
PMI（Performance Monitoring Infrastructure）
WASのパフォーマンス情報を取得するためのInfrastructure
WAS V6.0からデフォルトで有効に
Tivoli Performance Viewer（V6.0から管理コンソールに統合）が利用
要求メトリック
リクエストが処理される各段階での応答時間を計測
SystemOut.logやhttp_plugin.logなどに記録させることが可能
標準技術であるApplication Response Measurement(ARM) APIでも取得可能
TPV
TPV
PMI
Webサーバー
ブラウザー
Webコンテナ
AS
PMI要求メトリック
PMI要求メトリック
EJBコンテナ
AS
ARM
ARM
DB
Tivoli Performance Viewer
WAS V6.0より管理コンソールに統合
管理者が直にモニターする必要があるため
運用時の監視ツールとしては不適切
要求メトリックの使用方法
管理コンソールから指定
「要求メトリックを使用可能にする」をチェック
「要求メトリックのあて先」の
「使用可能にする」にチェック
計測が開始される
アプリケーションサーバーではSystemOut.log
HTTP Serverではhttp_plugin.logに記録される
全てのリクエストについて取得すると，
膨大な出力がたまるので注意
フィルターで適宜制限を行う
送信元 IP アドレス，リクエストURIで
フィルター可能
要求メトリックのSystemOut.logへの出力例
[05/11/24
[05/11/24 7:15:48:094
7:15:48:094 JST]
JST] 00000030
00000030 PmiRmArmWrapp
PmiRmArmWrapp II PMRM0003I:
PMRM0003I: parent:ver=1,i
parent:ver=1,i
p=10.7.17.104,time=1132784056891,pid=1436,reqid=1,event=1
current:ver=1,ip=10.
p=10.7.17.104,time=1132784056891,pid=1436,reqid=1,event=1 - current:ver=1,ip=10.
7.17.104,time=1132784056891,pid=1436,reqid=1,event=1
7.17.104,time=1132784056891,pid=1436,reqid=1,event=1 type=URI
type=URI detail=/ibm/consol
detail=/ibm/consol
e/secure/logon.do
e/secure/logon.do elapsed=3953
elapsed=3953
JavaDump （Javacore）
IBM JVMで出力される問題判別ためのファイル
記録されている内容
環境変数IBM_JAVACOREDIRで指定されたディレクトリ
サーバーのカレントディレクトリ（デフォルトではインストールディレクトリ）
/tmpディレクトリ（UNIX/Linux），%TEMP%ディレクトリ（Windows）
JVMが異常終了したとき
JVMがQUITシグナルを受け取ったとき
ヒープエリアが使い尽くされたとき
com.ibm.jvm.Dump.JavaDump()が実行されたとき
無効化する方法
等
出力されるトリガー
出力された瞬間のJVM内部に関する各種情報
OSの情報，Javaアプリケーションの環境情報，
スレッドのJava stack/Native stack，モニターロック，メモリ
出力される場所（上のものほど優先）
テキスト形式のファイルなのでエディタなどで直接参照可能
javacoreで始まるファイル名で出力（時刻やプロセスIDの情報がファイル名に付加される）
環境変数IBM_JAVACOREDIRに値を設定（すべての場合で無効化）
環境変数IBM_JAVADUMP_OUTOFMEMORYにFALSEを設定（ヒープ枯渇時）
環境変数JAVA_DUMP_OPTSでさらに詳細な制御が可能（詳しくは下記文書）
詳細な解説は以下の文書を参照
IBM developer kits: Diagnosis documentation
http://www.ibm.com/developerworks/java/jdk/diagnosis/
JavaDumpの取得方法
サーバーハングや
極端なスローダウンの際には
強制取得した
JavaDumpが解析に有効
UNIX/Linux系のOSでは，
Javaのプロセスに
QUITシグナルを送る
kill –QUIT <PID>
Windowsでは，左のような
スクリプトを用意して，
wsadminコマンドで取得する
プロファイルのbinの下の
wsadminコマンドを使用する
## getThreadDump.jacl
getThreadDump.jacl
##
## Author:
Author: Bill
Bill Wigger
Wigger
##
## Usage:
Usage: wsadmin
wsadmin -f-f getThreadDump.jacl
getThreadDump.jacl <server
<server name>
name>
## Where:
Where:
## server
server name
name -- application
application server
server name
name
##
ifif {[llength
{[llength $argv]
$argv] << 1}1} {{
puts
""
puts ""
puts
puts "Usage:
"Usage: wsadmin
wsadmin -f-f getThreadDump.jacl
getThreadDump.jacl <server
<server name>"
name>"
puts
puts "" server
server name:
name: the
the server
server where
where the
the listener
listener ports
ports will
will bebe added"
added"
exit
exit
}}
## Passed
Passed inin variables
variables
set
[lindex
set serverName
serverName
[lindex $argv
$argv 0]0]
set
set oStringQuery
oStringQuery "*:type=JVM,process="
"*:type=JVM,process="
append
append oStringQuery
oStringQuery $serverName
$serverName
append
append oStringQuery
oStringQuery ",*"
",*"
set
set oStringObjectName
oStringObjectName [[ $AdminControl
$AdminControl completeObjectName
completeObjectName $oStringQuery
$oStringQuery ]]
set
oDumpThreads
[
$AdminControl
invoke
$oStringObjectName
set oDumpThreads [ $AdminControl invoke $oStringObjectName dumpThreads
dumpThreads ]]
puts
puts "Results
"Results ofof dumpThreads
dumpThreads forfor server:
server: $serverName"
$serverName"
puts
puts "" $oDumpThreads"
$oDumpThreads"
JavaDumpの例：異常終了
アプリケーションサーバーのJVMが異常終了した場合には，OS の生
成するcoreやダンプと並んでJavacoreが基本的な資料になる
基本的にはIBMサポート部門に送付して解析を依頼することになるが，
内容を確認することにより，障害の原因となっているコンポーネントを
推定することが可能なこともある
JIT Compilerコンポーネントによる異常終了の例
0SECTION
XHPI
0SECTION
XHPI subcomponent
subcomponent dump
dump routine
routine
NULL
==============================
NULL
==============================
1XHTIME
Fri
1XHTIME
Fri Jul
Jul 16
16 09:28:32
09:28:32 2005
2005
1XHSIGRECV
SIGSEGV
received
at
0xd3364a58
1XHSIGRECV
SIGSEGV received at 0xd3364a58 in
in
/usr/WebSphere/AppServer/java/jre/bin/libjitc
jitc.a.
Processing
jitc
/usr/WebSphere/AppServer/java/jre/bin/libjitc
jitc.a.
Processing terminated.
terminated.
jitc
（中略）
（中略）
1XHCURRENTTHD
1XHCURRENTTHD Current
Current Thread
Thread Details
Details
NULL
---------------------NULL
---------------------2XHCURRSYSTHD
"Servlet.Engine.Transports
2XHCURRSYSTHD
"Servlet.Engine.Transports :: 4"
4" sys_thread_t:0x55A49DF0
sys_thread_t:0x55A49DF0
3XHNATIVESTACK
Native
3XHNATIVESTACK
Native Stack
Stack
NULL
-----------NULL
-----------3XHSTACKLINE
at
3XHSTACKLINE
at 0xD33FD110
0xD33FD110 in
in rnn
rnn
3XHSTACKLINE
at
3XHSTACKLINE
at 0xD3364A58
0xD3364A58 in
in quadruple_optimization
quadruple_optimization
3XHSTACKLINE
at
0xD3259374
in
JITGenNativeCode
JIT
3XHSTACKLINE
at 0xD3259374 in JITGenNativeCode
JIT
3XHSTACKLINE
at
jit_compile
3XHSTACKLINE
at 0xD327F774
0xD327F774 in
in jit_compile_a_method_locked
jit_compile_a_method_locked
jit_compile
3XHSTACKLINE
at
jit_compiler
3XHSTACKLINE
at 0xD3280D24
0xD3280D24 in
in jit_compiler_entry
jit_compiler_entry
jit_compiler
3XHSTACKLINE
at
0xD3281284
in
_jit
jit_fast_compile
jit
3XHSTACKLINE
at 0xD3281284 in _jit
jit_fast_compile
jit
JIT Compilerの処理中にSIGSEGVが発生している
→ JITの無効化により，一時的な回避が可能かもしれない
JavaDumpの例：サーバーハング
サーブレットの実行スレッドがどのような状態で停止しているかによりハングの原
因が判断できる可能性が高い
DBへのSQL実行の応答待ちで止まっている
モニターのデッドロックが発生している
無限ループに陥っている
等
モニターのデッドロックはJavaDump出力ルーチンによって検出され記録される
デッドロックが検出された場合の例
1LKDEADLOCK
Deadlock
1LKDEADLOCK
Deadlock detected
detected !!!
!!!
NULL
--------------------NULL
--------------------NULL
NULL
2LKDEADLOCKTHR
2LKDEADLOCKTHR Thread
Thread "Thread-16"
"Thread-16" (0x5A378898)
(0x5A378898)
3LKDEADLOCKWTR
is
waiting
3LKDEADLOCKWTR
is waiting for:
for:
4LKDEADLOCKMON
sys_mon_t:0x5A378BB8
4LKDEADLOCKMON
sys_mon_t:0x5A378BB8 infl_mon_t:
infl_mon_t: 0x00000000:
0x00000000:
4LKDEADLOCKOBJ
com.decp.cmct.core.CmctSession@2CCA71E8/2CCA71F0:
4LKDEADLOCKOBJ
com.decp.cmct.core.CmctSession@2CCA71E8/2CCA71F0:
3LKDEADLOCKOWN
which
3LKDEADLOCKOWN
which is
is owned
owned by:
by:
2LKDEADLOCKTHR
Thread
"Servlet.Engine.Transports
2LKDEADLOCKTHR Thread "Servlet.Engine.Transports :: 9"
9" (0x5A360920)
(0x5A360920)
3LKDEADLOCKWTR
which
is
waiting
for:
3LKDEADLOCKWTR
which is waiting for:
4LKDEADLOCKMON
sys_mon_t:0x5A3A6FB8
4LKDEADLOCKMON
sys_mon_t:0x5A3A6FB8 infl_mon_t:
infl_mon_t: 0x00000000:
0x00000000:
4LKDEADLOCKOBJ
com.decp.cmct.core.CmctSession@2CD073C8/2CD073D0:
4LKDEADLOCKOBJ
com.decp.cmct.core.CmctSession@2CD073C8/2CD073D0:
3LKDEADLOCKOWN
which
3LKDEADLOCKOWN
which is
is owned
owned by:
by:
2LKDEADLOCKTHR
Thread
"Servlet.Engine.Transports
2LKDEADLOCKTHR Thread "Servlet.Engine.Transports :: 19"
19" (0x5A362630)
(0x5A362630)
3LKDEADLOCKWTR
which
is
waiting
for:
3LKDEADLOCKWTR
which is waiting for:
4LKDEADLOCKMON
sys_mon_t:0x5A3A70D0
4LKDEADLOCKMON
sys_mon_t:0x5A3A70D0 infl_mon_t:
infl_mon_t: 0x00000000:
0x00000000:
4LKDEADLOCKOBJ
com.decp.cmct.core.CmctSession@3084D560/3084D568:
4LKDEADLOCKOBJ
com.decp.cmct.core.CmctSession@3084D560/3084D568:
3LKDEADLOCKOWN
which
3LKDEADLOCKOWN
which is
is owned
owned by:
by:
HeapDump
Javaヒープ中にある全てのオブジェクトに関する情報をダンプしたもの
OutOｆMemoryErrorの問題判別における強力な解析資料
OutOfMemoryErrorが発生した場合に自動的に出力される
オブジェクトのアドレス・サイズ・種類・参照関係など
出力ディレクトリはJavaDumpと同じディレクトリ
heapdumpで始まるファイル名（時刻やプロセスIDの情報がファイル名に付
加される）
ヒープサイズが大きい場合には巨大なダンプが生成されることも
phd形式でファイルサイズが100Mを超える場合もある
（テキスト形式だと1Gに達することもある）
Disk I/Oのオーバーヘッドもあり，出力にある程度の時間がかかる
OutOfMemoryError発生時に，問題判別の資料収集よりJVM再起動を優先させる場合には，
HeapDumpの出力を無効化しておく必要がある。
Dumpを解析する環境にも，かなりのH/W資源が要求される
無効化する方法
環境変数IBM_HEAPDUMP_OUTOFMEMORYにFALSEを設定する
逆にIBM_HEAPDUMPにTRUEを指定するとQUITシグナルでもHeapDumpが
出力されるようになる
HeapDumpの形式
HeapDumpのフォーマットが， JDK 1.4.2 SR1以降では
バイナリ形式（Portable Heap Dump Format）に変更に
JDK 1.4.2以前
テキスト形式
JDK 1.4.2 SR1
（WAS 6.0 GAレベル）
phd v4 format
JDK 1.4.2 SR2以降 （WAS 6.0.2以降）
phd v5 format
v4フォーマットには，情報が正しく出力されない問題が報告されているので
HeapDumpを使用した問題判別を行う場合にはSR2以上にあげておく
従来のテキストファイル方式に比べ，多くの利点
サイズの減少（1/8程度）
出力時間の短縮
追加情報の記録
compactionで移動した全てのオブジェクトのトラッキング情報
全てのglobal reference情報
等
従来のテキスト形式で出力するには，環境変数を指定する
IBM_JAVA_HEAPDUMP_TEXT=true
テキスト形式で出力される
IBM_JAVA_HEAPDUMP_TEST=true
テキスト形式とphd形式の両方で出力される
HeapDumpの分析ツール
HeapRoots
Jheap
memdumpdiag
heapanalyzer
使い方
難しい
簡単
簡単
簡単
PAテクニカルサポート経由入手可
テクニカルサポート経由入手可
入手方法
Webから
Webから
Webから
から入手可
Webから入手可
から入手可 PAテクニカルサポート
Webから入手可
から入手可
Web
から入手可
（有効な
有効なサポート契約
サポート契約が
契約が必要）
必要）
自動解析
無し
有り（既存APAR
リークオブジェクト指摘
無し
既存APARを
APARを指摘）
指摘）
リークオブジェクト指摘
heapdump,HPROF Dump,SVC dump
解析対象
heapdump
heapdump
heapdump
heapdump比較
無し
無し
有り
無し
heapdump比較
連続領域判定
有り
有り
無し
有り
プラットフォーム
Java2環境
C(AIX/Windows/Linux版提供
Java2環境
環境（
Java2環境
C(AIX/Windows/Linux版提供）
版提供） Java2
環境（現在Win/Linux
現在Win/Linux版
Win/Linux版のみ）
のみ） Java2環境
Java2環境
GUI
無し
無し
有り
有り
推奨K
推奨Kクラスタ
無し
有り
無し
無し
サイズの
サイズの指摘
PHD対応
PHD対応 未（206からの
206からの予定
済み
済み
済み（1.3.4以降
1.3.4以降）
からの予定）
予定）
以降）
HeapRoots
Heap Dumpの調査で使う最も強力なツール
以下のURLから誰でもダウンロード可能（要登録）
http://www.alphaworks.ibm.com/tech/heaproots
CUIベースのツールで，各種コマンドを駆使して解析。使用方法は難解。
豊富な機能
最大連続空きサイズの確認
個数や合計サイズが大きいオブジェクトの検索
リークオブジェクトの参照元を推定
オブジェクトから参照されているオブジェクトのツリーを生成
Javaヒープの連続空き領域をサイズ順にリストしフラグメンテーションを確認
実際のリーク箇所の特定
オブジェクトの被参照経路を追跡
Enter:
Enter: o{a,s,t,d,m,n},
o{a,s,t,d,m,n}, g{c,s},
g{c,s}, t{c,s,n},
t{c,s,n}, i,
i, p,
p, d{t,d,m}
d{t,d,m} or
or help
help for
for more
more info
info
>> tc
tc
Enter
Enter name
name to
to filter
filter on
on or
or '-'
'-' for
for no
no filtering
filtering [-]
[-]
>>[[ Enter
Enter ]]
Enter
Enter range
range of
of lines
lines to
to print
print in
in format
format 'M','L-U','-U'
'M','L-U','-U' or
or 'L-'
'L-' [1-25]
[1-25]
>>[[ Enter
Enter ]]
Constructing
Constructing types
types table
table ...
...
......................................................................
...................................................................... done.
done.
Organising
Organising types
types data
data (8214
(8214 types)
types) ...
...
......................................................................
...................................................................... done.
done.
Sorting
Sorting by
by count
count ...
...
..
done.
done.
Tabulating
all
objects,
sorted
by
count
Tabulating all objects, sorted by count
Count
Total-size
Count
Total-size Type
Type Name
Name
------------------------------------------------------------------------------------------------------------------------------------------------------------1,480,244
1,480,244 47,367,808
47,367,808 java/lang/String
java/lang/String
1,479,953
1,479,953 422,453,776
422,453,776 primitive
primitive array
array
250,157
250,157 8,005,024
8,005,024 java/util/Hashtable$Entry
java/util/Hashtable$Entry
128,441
128,441 5,137,640
5,137,640 jp/co/mycompany/blue/javakit/frame/GVariant
jp/co/mycompany/blue/javakit/frame/GVariant
63,001
3,528,056
63,001
3,528,056 com/ibm/ejs/cm/proxy/PreparedStatementProxy
com/ibm/ejs/cm/proxy/PreparedStatementProxy
62,945
3,021,360
62,945
3,021,360 com/ibm/ejs/cm/proxy/ResultSetProxy
com/ibm/ejs/cm/proxy/ResultSetProxy
Jheap
入手方法
PAサポートセンターから入手（IBMサポート契約のお持ちのお客様のみ）
ユーザーの操作はほとんど不要で，基本的に全自動で解析を行う
#./jheap heapdumpFile > jheap.out
（Linux/AIXの例）
さまざまな自動分析
フラグメンテーション事前調査
クラスごとの参照先・参照元クラスによる参照内訳表示（各パス共通）
クラスごとの統計情報表示（各パス共通）
配列やストリングやハッシュなどの圧縮整理（パス２），全圧縮可能オブジェクトの大規模な圧縮整理（パス３選択）
木構造に変換後累積オブジェクトサイズ表示（パス３選択）
アンファイナライズド・オブジェクトの表示（累積選択時），アンリーチャブル・オブジェクトの表示（累積選択時）
既存ＡＰＡＲや不審パターンとの照合も行う
分析結果のダイジェストをコンソールに表示
***
*** CHECK
CHECK ***
*** initial
initial class
class cluster
cluster too
too small
small (Java2
(Java2 defect
defect 67018)
67018)
please
specify
-Xk8576
or
more
under
latest
service
refresh
please specify -Xk8576 or more under latest service refresh
***
*** ERROR
ERROR ***
*** probable
probable XALAN
XALAN XMLReaderManager
XMLReaderManager leak
leak (APAR
(APAR PQ95238)
PQ95238)
objcount
objbytes
(exclusive
noaccess
leafobj)
objcount objbytes
(exclusive noaccess leafobj) refs-out
refs-out refs-in
refs-in sorted
sorted by
by objbytes
objbytes (out
(out of
of 266119680)
266119680)
2170
954328832358.6%
(
2170
0
0)
46718
2170
|
org/apache/xalan/templates/ElemForEach
2170 954328832358.6% (
2170
0
0)
46718
2170 | org/apache/xalan/templates/ElemForEach ||
403
403
00
0)
5056
403
403 216919448
216919448 81.5%
81.5% ((
403
0)
5056
403 || org/apache/xml/dtm/ref/sax2dtm/SAX2DTM
org/apache/xml/dtm/ref/sax2dtm/SAX2DTM ||
112
209386000
78.7%
(
112
0
0)
555
112
|
org/apache/xerces/parsers/SAXParser
112 209386000 78.7% (
112
0
0)
555
112 | org/apache/xerces/parsers/SAXParser ||
HeapDump中に問題があれば*** CHECK ***，または*** ERROR *** で始まる行でAPARの指摘や
ユーザへのサジェスチョンが出る
MemDumpDiag
GUIベースの視覚的なHeap調査用ツール
以下のURLからダウンロード可能（要登録）
http://www.ibm.com/developerworks/websphere/downloads/memory_dump.html
HeapDumpだけでなく，Sun JDKの出力するHPROF Dumpなども解析可能
メモリーリークをおこしたオブジェクトの自動推測機能
複数回取得したHeapDumpを比較し，差分を検出することが可能
HeapAnalyzer
GUIベースのHeapDump用調査ツール
以下のURLからダウンロード可能（要登録）
http://www.alphaworks.ibm.com/tech/heapanalyzer
さまざまな分析機能
サイズ別・出現数別 objects/classes/arrays のリスト
Childサイズ・オブジェクト数別objects/classes/arrays のリスト
アルファベット順 objects/classes/arrays のリスト
サイズ別、利用可能heapスペースのリスト
利用可能heapスペースのチャート
HeapDumpのツリービュー
Heapリークの可能性のあるエリアの特定
Edge Component
Load Balancerのログ
Load Balancerのログは循環ログ
サイズがオーバーしたら古いログから上書き
ログ・サイズは変更可能
ログの種類
server.log
manager.log
SNMP subagentに関する情報
hamon.log
使用するadvisorに関する情報
subagent.log
managerの活動記録等
使用advisor名_ポート.log
dsserverの活動の記録、発行したコマンド等の情報
high availabilityに関する情報（Primary, Backupの両方）
reach.log
reach advisorがとばしたping情報等
dsserver/cbrserverが起動しない
ポートの競合が発生しているケースが多い
dsserverが使用するポート
ポート
設定ファイル
変数名
用途
10099
dsserver
LB_RMIPORT
dsserverとdscontrolコマンドの通信
10199
dsserver
LB_RMISERVERPORT
dsserver自身の使用するポート
10004
metricserver
LB_RMIPORT
メトリック・サーバーとの通信
競合するアプリケーションの停止を行う
各設定ファイルの変数値を変更することでも対応可能
AIXやLinux、Solarisの場合 ：/usr/binディレクトリに存在
Windowsの場合 ：C:¥WINDOWS¥system32に存在
「エラー: サーバーが応答していません。」
dsserverとdscontrolコマンドの通信ができていない場合に表
示されるメッセージです
dsserverプロセスは起動していますか？
Javaプロセスが起動しているか確認してください。
Dispatcherの場合 ps –ef | grep java | grep SRV_KNDConfigServer
dscontrolコマンドの通信に使われるカギが壊れていませんか？
「lbkeys create force」コマンドで鍵を生成し直してみてください
生成された鍵は/opt/ibm/edge/lb/admin/keysディレクトリにあります
それでも直らない場合は、鍵ファイル名に付加されるIPアドレスをご確認下さい
例）dispatcher-<NFAアドレス>-10099.key、cbr-<NFAアドレス>-11099.key
IPアドレスがNFAアドレスではない場合は、/etc/hostsファイルなどの設定を確認して
下さい
Manager Report
dscontrol manager report コマンド
managerが持っている情報を表示する
問題判別では
問題判別では、
では、このPORT
このPORT値
PORT値をまず確
をまず確かめます
PORT値
PORT値は，advisorを使用してサーバの状態を監視した時の、割り振り先サーバに対するリク
エストのレスポンス時間に依存した値を表しております。レスポンス
レスポンスがない
レスポンスがない場合
がない場合は
場合は、PORT値
PORT値
は－１となります。
となります
manager report 表示例
------------------------------------------------------------------|
9.170.19.100
| WEIGHT | ACTV | NEWC | PORT |
SYS |
|
PORT:
80
|NOW NEW|
49% |
50% |
1% |
0% |
------------------------------------------------------------------|
9.170.19.10 | 9 9 |
13 |
1 |
32 |
0 |
|
9.170.19.20 | 0 0 |
0 |
0 |
-1 |
0 |
-------------------------------------------------------------------
＜参考＞
参考＞
WEIGHT
更新
WEIGHT
更新
２秒
ACTV, NEWC
更新
WEIGHT
更新
WEIGHT
更新
２秒
２秒
ACTV, NEWC
更新
Manager Reportが全サーバー「-1」を返す
クラスター・アドレスはDispatcherに設定しましたか
[MAC]割振り先サーバー側の設定は行いましたか
[Windows/AIX]
[Linux]
TCP/IPフィルタリングを設定していませんか？
Broadcom社製Ethernet Adapterを使用している場合、 Ethernet@Wirespeed機能
を無効にする必要があります
Task/ChecksumのOffload機能を使用していませんか？
Advisorのリクエストは正しく届いていますか？
割振り先サーバーでiptablesの設定をして下さい
[Windows] NICの設定を確認してください
割振り先サーバーのループバック・アダプターにクラスター・アドレスを設定して下さい。
割振り先サーバーのアクセスログを確認してください
[拡張HTTPアドバイザー]監視リクエスト・監視文字列は正し
く設定されていますか？
dscontrol server status ：： で確認
割振りが行われない①
Dispatcherにパケットは届いていますか
誰がクラスター・アドレスに応答しているか確認する
同じネットワークのマシンからPingを発行し、ARPテーブルを確認
割振り先サーバー側の仮想ホストの設定は正しいですか
割振り先サーバー側で仮想ホストを設定したり、ListenするIPアドレ
スを限定する場合、Dispatcherのパケットがどのように変換されてい
るか考える必要があります。
[MAC]仮想ホストはクラスター・アドレスで設定
goActive / goStandbyスクリプトを確認してください。
ネットワークインターフェースに正しく登録されていますか
[AIX] netstat –in
[Windows] ipconfig /all
[Linux] ifconfig -an
割振りが行われない②
ネットワーク・トレースでどこまでパケットが届いているか
確認してください。
以下の2箇所にネットワーク・トレースを仕掛ける
Dispatcherマシン
割振り先サーバー
Dispatcher
IHS
どこでパケットが行方不明になっているのか切り分けて下さい
1.
2.
3.
4.
5.
クラスター・アドレス宛にパケットが届いているか？
割振り先サーバーにパケットは送っているか？
IHSにパケットは届いているか？
IHSからレスポンスは正しく返っているか？
Dispatcherからパケットは正しく返っているか？
HA構成の問題
Takeoverが正常に完了しない
goActive/goStandbyが正しく設定されているかご確認下さい
障害時にdsserverのjavaプロセスは存在しましたか？
[Unix] 各スクリプトに実行権限があることを確認してください
goActive/goStandby各スクリプトの呼出しはjavaプロセスによって行われるため、プロセスもダ
ウンしていた場合はTakeoverが発生しません
意図しないTakeoverが発生する
Dispatcherマシン上でNTPが動いていませんか？
NTP（Network Time Protocol)により時間の調整が行われると、予期せぬTakeoverの原因となることがありま
す。
『Network Time Protocol support with WebSphere Edge Components』
http://www.ibm.com/support/docview.wss?uid= swg21178386
NTPを停止しても問題が解消しない場合
Heartbeatを行っているポートのネットワークトレースを採取します
正しくHeartbeatが行われているか確認してください
Heartbeatは0.5秒間隔で送られているGREというパケットです
Heartbeat間隔を広げ、 Heartbeatの断絶の可能性を減らします
広げすぎると障害発生時の検知が遅くなりますので注意が必要です
dscontrol executor set hatimeout <断絶を許容する秒数（デフォルト２）>
よくある問題
セッションが維持できない
IPStickyを使用している場合
携帯電話や一部プロバイダーからのリクエストはラウンド・ロビン・プロキシーを通
過するため、WASでセッションを維持する必要があります。
割振りが偏る
[IPSticky]Load Balancerの前段にProxyServerが存在する場合など、
特定のIPからしかリクエストが来ない場合には、IPStickyは使用でき
ません。
接続数が異常に多い
通常時と比べ、異常
な数ではないか？
Manager Reportで表示される接続数が異常な値を示す
特定の時間のみ、突然に接続
数が急増したのであれば、 ------------------------------------------------------------------|
clsuter.com
| WEIGHT | ACTV | NEWC | PORT | SYS |
|
PORT:
80
|NOW NEW| 49% | 50% |
1% |
0% |
攻撃されている可能性も
------------------------------------------------------------------|
server1 | 10 10 |
141 |
0 |
-1 |
0 |
あります。
|
server2 | 10 10 |
283 |
0 |
-1 |
0 |
|
sorryServer | 10 10 |
926 |
273 |
-1 |
0 |
------------------------------------------------------------------SYNフラッド攻撃
DoS攻撃の手法の一つで、確立しないTCP接続を大量に試みる攻撃
接続の確立時の３ウェイ・ハンド・シェイクにおいて、SYNを大量に送りつけるが、
サーバー側からのSYN/ACKにはACKを返さず、サーバー側には不完全な接続
が滞留し、新たな接続が受けつけれない状況となる
SYN
SYN/ACK
netstat –anで接続情報を表示
し、”SYNRCVD”のステータス
が異常に多いようであれば、
DoS攻撃の可能性あり
ACK
Dispatcherでは攻撃を止めることはできないが、特定のIPからのみSYN攻撃を
受けているのであれば、IPルールでパケットをDropすることは可能
IPルールを設定し、ルールの割振り先サーバーに何も指定しない
Rational Web Developer
Rational Application Developer
WebSphere Studio & Rational 開発ツール
SOAによるサー
ビス統合開発者
WebSphere Integration
Developer
• プロセス・フロー
(BPEL)
• WPS V6
WebSphere Studio
Development Suite
for HLL/WB
• 日本語仕様書から
日本語仕様書からコード
からコード生成
コード生成
• ソースから
ソースから仕様書
から仕様書へ
仕様書へリバース
• 用語辞書管理
WebSphere Developer for zSeries (WDz)
iSeries App開発者
• COBOLと
とPL/I：
：ロー
カルや
カルやリモートで
リモートで編集、
編集、
コンパイル、
コンパイル、デバッグ
• EJB開発環境
開発環境
のXML活用
活用
• コンポーネント・
コンポーネント・テスト • COBOLの
• EGL（
（COBOL）
）
• ランタイム
ランタイム分析
分析
• HATS ToolKit
• コードレビュー
• CICS Windows
• UML可視化
可視化
• CCアダプター
アダプター
• CCLTサーバー
サーバー(同梱)
同梱)
• Portalテスト
テスト環境
テスト環境
z/OS Appl開発者
Rational Application Developer (RAD)
WebSphere
Development
Rational Web Developer
Studio Client
• Webアプリケーション
アプリケーション開発環境
アプリケーション開発環境
サーブレット)
サーブレット
Advanced Edition (HTML/JSP/サーブレット
• Strutsビルダー
ビルダー
for iSeries
• サイト・
サイト・デザイナー
• RPGと
とCOBOLの
のリ
モート編集
モート編集、
編集、コンパイ
ル、デバッグ
• Web Facing Tool
• HATS Toolkit
Web Appl開発者
• JSF/SDO
• Webサービス
サービス
• XML開発環境
開発環境
• RDB開発環境
開発環境
• EGL (Java)
• WebSphere テスト環境
テスト環境
• Java Visual Editor
Rational Software
Architect
(同梱
同梱)
同梱
• J2EE Connector
(オプションフィーチャー
オプションフィーチャー)
オプションフィーチャー
• UML2.0開発
開発
• C/C++開発
開発
オープンソース、
編集,
オープンソース、Java編集
編集 コンパイル,
コンパイル デバッグ
J2EE開発者
Appl設計者
IBM Rational Software Development Platform (RSDP)
開発チームを統合することが可能なソフトウェア開発の「プラットフォーム」
Eclipse 3.0ベース
各ツールのシナジーにより、コラボレーティブな開発を実現
個人とチーム全体の生産性を向上
http://www.ibm.com/jp/software/rational/products/release/sdp-2004/
前頁の製品は「プラットフォーム」を共有することが出来ます。
共存、共存できない場合もありますので、ドキュメントをご確認ください。
この例では
Rational Application Developer
WebSphere Developer for zSeries
がプラットフォーム上にあります。
Rational Application Developer ディレクトリー構造
RSDP製品のインストールやUpdate時のログ
rad・・・RADのプラグイン
rad_prod・・・RADのドキュメント各種
WASテスト環境(V5.x, V6) →次頁参照
Portalテスト環境 etc.
wdz・・・WDzのプラグイン
wdz_prod・・・WDzのドキュメント各種
RSDP製品のワークスペース
開発時のファイルはここに入ります
＊ワークスペースは複数作成できます
WAS V6 テスト環境 ディレクトリー構造
新規プロファイルを作成することで、ワークスペース上で
どのアプリケーションサーバープロファイルを使用するか
選択することが出来ます。
＊新規プロファイル作成ウィザード
{RAD_install}¥runtimes¥base_v6¥bin¥ProfileCreator¥pctWindows.exe
profiles
導入時にdefaultプロファイル
が自動作成されている
profileごとのlogsディレクトリー
解析の際にはまずここを参照！
解析方法はWASと同様です
ランタイム・WASテスト環境
RADには
にはWASV5.0,V5.1,V6の
のテスト環境
には
テスト環境が
環境が付属
WASV5.xと
とWASV6は
は構造が
構造が変わりました。
わりました。
RAD
WAS V6 サーバー
WAS Express、Base、NDをテスト
可能
WAS Express、Baseは製品CDか
らサイレント・インストール可能
WAS NDは別途購入が必要
SOAP port:8880
WAS V5.x テスト環境
ローカル・デバッグ
ランタイム
WAS
新リモート・デバッグ
H/W
WAS Baseをプラグイン
WAS V5.x サーバー
Rational Agent Controller
旧リモート・デバッグ
Rational Agent Controllerを経由
してリモートのWAS Express、
Baseをテスト可能
RAC port:10002
テスト環境のサーバー設定の違い
WASV6 テスト環境
テスト環境
WASV5.x テスト環境
テスト環境
管理コンソールを立ち上げる
には、ここにチェック！！
WASV6 は、管理コンソールを立ち上げ、
サーバーの設定をします。
（Enhanced EARで設定することもできます）
WASV5.x は、サーバーの設定画面があり、タブを
切り替えて設定が出来ます。（管理コンソールを
立ち上げることもできます）
何かおかしいと思ったら・・・
どこで起こった問題か切り分ける！！
実は一番多い！！
ツールの
ツールの使い方が分からない
WASコンソール
WASコンソール上
コンソール上でエラーメッセージ
WASの問題判別と同様、コンソールやログより解析を行う
解析の際はPAコールも活用
アプリケーションの障害の場合は、デバッグを行い、バグの発見・修正
ウィザード使用
ウィザード使用や
使用やコンパイル時
コンパイル時にエラー
ヘルプ、チュートリアル、Webの記事(WebSphere/Rational Developer Domain etc.)
を参照
まずはツールのFixを当ててみる（次項参照）
org.eclipse.xxxx とトレースで出ていた場合は、ツールの障害である可能性も
再現を確認して、PAコール
ツールの
ツールのパフォーマンスが
パフォーマンスが遅い
IBM Rational Software Development Platform 製品群 パフォーマンスTips
http://www.ibm.com/jp/developerworks/rational/mdd/performance/sdptips.html
上記以外では、
ディスクのデフラグ、ワークスペースの分割も有用
といっても、やはりPCのスペック(CPU/メモリ）を向上させることが一番！！
Fix、オプション・フィーチャーの適用方法
オンライン、オフラインで適用可能
http://www.ibm.com/jp/software/rational/download/ifix/index.html
Rational Product Updaterは便利
ネットワークにつないでいる場合、自動検出可能
V6.0.1より、クリーンアップ機能搭載（以前の累積Fixを削除し、Disk容量の空きを増やす）
最新のFixが表示されるので、以前のものを適用したい場合は、別途ダウンロード
http://www.ibm.com/software/awdtools/developer/application/support/index.html