Comments
Description
Transcript
パフォーマンス設計 WASV6による基幹システム設計Workshop
WASV6による基幹システム設計Workshop
パフォーマンス設計
Agenda
パフォーマンス設計概要
パフォーマンスデータの取得
パフォーマンステストシナリオ
レスポンスタイムの取得
CPUの確認
メモリの確認
アクセス数、TCPコネクション数の確認
WASのモニタリングツールを用いたパフォーマンスデータの取得
問題解析のアプローチ
Webシステムにおけるチューニング項目
OS
クライアント・Webサーバー間
Webサーバー・アプリケーションサーバー間
JVMヒープ
EJBコンテナー
データベース接続
2
パフォーマンス設計概要
3
パフォーマンス設計
パフォーマンス要件を洗い出し、システム設計を実施
パフォーマンステストを実施し、それらの要件が実システムで満たせていることを確認
満たせていない場合は、ボトルネックを発見し、パラメータチューニングを実施
本番稼動後、パフォーマンスの劣化が発生した場合、問題の分析と解決策を実施
要件定義
パフォーマンス要件の洗い出し
パフォーマンス要件を
実際のシステムに落とし込み
設計
開発
システムの開発
テスト
運用
パフォーマンステストを実施
パフォーマンス要件に満たない場合は
チューニングを実施
本番稼動後のパフォーマンス
の劣化による問題分析
4
パフォーマンステストシナリオ
パフォーマンステストには負荷ツールを用いてサーバーにアクセス。
パフォーマンステストの目的
システムがパフォーマンス要件を満たしていることの確認
ボトルネックを発見し、最適なパラメータ値を決定
パフォーマンストラブルの解決
テスト計画・準備
テストの再検討
負荷ツール、テストシナリオ決定
テスト実施
データの取得
結果の検討
2章：パフォーマンスデータの取得
3章：問題解析のアプローチ
チューニング結果の
確認
チューニング
報告書の作成
4章：Webシステムにおける
チューニング項目
5
テスト要件・シナリオの確定
テストの目的の明確化
キャパシティテスト
限界値の確認
動作確認
テスト範囲、対象サーバー
最大使用可能ユーザー数の見極め
パフォーマンスネックの洗い出し
高負荷状態での長時間耐久試験
想定最大ユーザー数でのキャパシティのテスト
レスポンスタイムが判定基準
1サーバーのみ or ネットワーク全体
取得情報と目標値
レスポンスタイム、CPU使用率、メモリ使用量、JVMヒープ、GCの頻
度・・・
6
パフォーマンスデータの取得
7
パフォーマンスデータの取得
パフォーマンスを判断するために、以下のような項目をパフォーマンス
データとして各サーバーで取得します。
1.
レスポンスタイムの取得
CPU使用率の確認
メモリ使用量の確認
アクセス数、TCPコネクションの確認
WASのモニタリングツールを用いたパフォーマンスデータの取得
2.
3.
4.
5.
JVMヒープ
スレッドプール
コネクションプール
セッション
その他、モニタリングツールで取得できる項目
（参考）パケットキャプチャー
8
１．レスポンスタイムの取得
各コンポーネントでレスポンスタイムを取得し、その差に注目。
レスポンスタイムの差から遅延部分を判断
IHSのレスポンスタイム
WASの要求メトリック
Webサーバーでの
遅延部分
プラグインでの
遅延部分
Webコンテナーでの
遅延部分
EJBコンテナーでの
遅延部分
DB処理での
遅延部分
access.log
Web
Server
plugin
Application
Server1
(WebContainer)
Application
Server2
(EJBContainer)
DB
http_plugin.log
SystemOut.log
(Server1)
SystemOut.log
(Server2)
SystemOut.log
(Server2)
9
Webサーバーのレスポンスタイム取得
レスポンスに時間がかかっているリクエストを判断
LogFormatディレクティブ
％D ： レスポンスタイムをマイクロ秒単位で表示（IHS v2.0）
％T ： レスポンスタイムを秒単位で表示（IHS v1.3、2.0）
デフォルトでは記載されないので、手動で追加する必要がある
レスポンスタイムをログに記録させる設定が必要。
httpd.conf
LogFormat “%h %l %u %t ¥”%r¥“ %>s %b [%D] ” common
access.log
9.170.251.57 - - [20/Oct/2005:14:18:31 +0900]
9.170.251.57 - - [20/Oct/2005:14:18:46 +0900]
9.170.251.57 - - [20/Oct/2005:14:18:46 +0900]
[31250]
9.170.251.57 - - [20/Oct/2005:14:18:52 +0900]
[5718750]
"GET /JVM/index.html HTTP/1.1" 404 61 [1234375]
"GET /JVM/input.html HTTP/1.1" 200 1494 [62500]
"GET /JVM/theme/Master.css HTTP/1.1" 200 731
"POST /JVM/TableViewer HTTP/1.1" 200 8924
アクセスログにレスポンスタイムが表記される
表計算ソフトなどを用いて、レスポンスの遅いリクエストを判断
10
WASの要求メトリック
どのコンポーネントの処理で遅延が発生しているかを判断
要求メトリックをONに設定、各コンポーネントのレスポンスタイムをログに出力させる
リクエスト全てに書き込みを行うと、要求メトリックによる出力自体が
パフォーマンスに影響を与える可能性があるので、
フィルターにより対象となるリクエストのみ出力させる
SystemOut.log
[05/10/20 14:19:07:266 JST] 00000030 PmiRmArmWrapp I PMRM0003I:
parent:ver=1,ip=9.170.251.57,time=1129785202984,pid=2720,reqid=1,event=1 current:ver=1,ip=9.170.251.57,time=1129785202984,pid=2720,reqid=2,event=1 type=JDBC
detail=SELECT * from staff elapsed=3125
[05/10/20 14:19:07:469 JST] 00000030 ServletWrappe A SRVE0242I: [JvmHandsOn] [/JVM]
[/output.jsp]: 初期化が正常に行われました。
[05/10/20 14:19:08:172 JST] 00000030 PmiRmArmWrapp I PMRM0003I:
parent:ver=1,ip=9.170.251.57,time=1129785472812,pid=2968,reqid=0,event=1 current:ver=1,ip=9.170.251.57,time=1129785202984,pid=2720,reqid=1,event=1 type=URI
detail=/JVM/TableViewer elapsed=14313
各コンポーネントのレスポンスタイムが記録されるので、その差に注目
差が大きいところに多くの時間を取られていることになる
11
要求メトリックの出力
出力は親（parent：呼び出し元）、子（current：呼び出された側）で構成。
リクエストの流れはリクエストIDを見て判断
elapsedがレスポンスタイムを示す
http_plugin.log
[Sun Aug 28 13:21:20 2005] 00000684 00001284 - PLUGIN:
parent:ver=1,ip=9.170.251.57,time=1125201907343,pid=1668,reqid=0,event=1 –
current:ver=1,ip=9.170.251.57,time=1125201907343,pid=1668,reqid=0,event=1 type=HTTP
detail=/JVM/TableViewer elapsed=23203 bytesIn=14 bytesOut=8871
reqid=0の子とreqid=0の親が結びつく
SystemOut.log
[05/08/28 13:21:06:375 JST] 00000034 PmiRmArmWrapp I PMRM0003I:
parent:ver=1,ip=9.170.251.57,time=1125202727641,pid=6048,reqid=1,event=1 –
current:ver=1,ip=9.170.251.57,time=1125202727641,pid=6048,reqid=2,event=1 type=JDBC
detail=SELECT * from staff elapsed=359
[05/08/28 13:21:19:953 JST] 00000034 PmiRmArmWrapp I PMRM0003I:
parent:ver=1,ip=9.170.251.57,time=1125201907343,pid=1668,reqid=0,event=1 –
current:ver=1,ip=9.170.251.57,time=1125202727641,pid=6048,reqid=1,event=1 type=URI
detail=/JVM/TableViewer elapsed=21765
elapsedがレスポンスタイム。
最も開きの大きいところに注目
同様にreqid=1の子とreqid=1の親が
結びつく
12
（参考）要求メトリックで出力される項目
フィールド
説明
parent
呼び出し側（親）の識別子
current
呼び出された側(子)の識別子
ver
親と子の相関関係のバージョン、親子の両者は同じ数字になります
ip
アプリケーション・サーバーがあるノードのIPアドレス
pid
アプリケーション・サーバーのプロセスID
time
アプリケーション・サーバーのプロセス開始時刻
reqid
要求メトリックがリクエストに割り当てるID
event
実際のトレースを区別するために割り当てられるイベントID
type
リクエストのタイプ
HTTP、URI、EJB、JDBC、JMS、非同期ビーン（COMMONJ_WORK_POOLED、
COMMONJ_TIMER）、Webサービスがサポート
detail
リクエストの詳細データで、URIのフルパス、SQLステートメント、EJBメソッド名など
elapsed
トータルの経過時間（ミリ秒）で、子の経過時間を全て含んだ時間
bytesIn
Webサーバー・プラグインが受け取ったリクエストのバイト数
bytesOut
Webサーバー・プラグインがクライアントに送信されたレスポンスのバイト数
13
要求メトリックの設定
管理コンソール左メニューの[モニターおよびチューニング]→[要求メトリック]
デフォルトはOFF
どのコンポーネントのデータを取得するかを設定
要求メトリックの使用の有無
（デフォルトはOFF）
フィルターの設定
フィルターをONにしたもののみ出力される
対象コンポーネントの指定
結果をログに出力させる
14
要求メトリックのフィルター
特定データのみを出力させる
フィルターを使用可能にしたデータのみをログに出力させることで、要求
メトリックの出力によるパフォーマンスダウンを抑える。
フィルターの種類を選択
/JVM/TableViewerというURIに対してフィルターをかけた例。
他のURIをアクセスしても要求メトリックの結果は出力されない
フィルターの値を入力
使用可能にする、を選択
15
ARM(Application Response Measurement)
レスポンスタイムを取得し、外部のシステム管理ツールに報
告するためのAPIを提供
Tivoli製品との連携
Tivoli Composite Application Manager for Response Time Tracking に要求メトリッ
クで取得した情報を送信
アプリケーションコードに測定の開始点と終了点を記述し、
その間のレスポンスタイムを取得
16
２．CPU使用率の確認
遅延が発生しているマシンに関してCPUの使用率を確認
vmstatコマンド（AIX、Linux）
CPUやメモリの使用状況の変化を一定時間間隔で表示
10秒間隔で利用状況をレポート
-tオプションで時刻を表示
vmstat -t 10 の出力（AIX）
#vmstat -t 10
kthr
memory
page
faults
cpu
------- -------------------- ------------------------ ----------------- --------------- ----------r b avm fre
re pi po fr sr cy in sy cs us sy id wa hr mi se
1 1 115652 95387 0 0 0 0 0 0 159 1693 127 1 3 95 1 14:18:24
1回目は起動時からの平均
0 0 115662 95377 0 0 0 0 0 0 153 1275 107 1 1 98 0 14:18:34
0 0 115660 95379 0 0 0 0 0 0 152 1819 107 1 3 96 0 14:18:44
2 0 115659 95380 0 0 0 0 0 0 162 2779 130 2 5 89 4 14:18:54
1 0 122849 88190 0 0 0 0 0 0 155 3968 104 83 6 10 0 14:19:04
1 0 133614 77425 0 0 0 0 0 0 155 7772 107 92 8 0 0 14:19:14
指定間隔で平均を取る 1 0 143252 67786 0 0 0 0 0 0 156 4619 114 92 7 0 0 14:19:24
1 0 146578 64460 0 0 0 0 0 0 155 2350 102 96 4 0 0 14:19:34
17
vmstatで取得できる内容
AIXとLinuxでは取得できる情報が一部異なる
AIX
-tオプションで時刻を表示。表示間隔と回数を指定
kthr：実行可能(r)、待機待ち（b)のカーネルスレッド数
メモリ：アクティブな仮想ページ（avm）、空きメモリページ(fre)
ページ：ページャーの入出力リスト(re)、ページイン数（pi）、ページアウト数(po)、フリーページ
数（ｆｒ）、ページ置換アルゴリズムによりスキャンされたページ数（sr）、クロックサイクル数(cy)、
フォルト：デバイスの割り込み数（in）、システムコールの数(sy)、コンテキスト切替数(cs)
CPU：ユーザモードのCPU使用率(us)、システムモードのCPU使用率(sy)、アイドル状態の
CPU使用割合(id)、ローカルディスク入出力が保留中のCPUの割合(wa)
Linux
表示間隔と回数を指定
Procs：実行待ち状態のプロセス数（r）、割り込み不可能なスリープ状態にあるプロセス数（b）、
Memory：使用されている仮想メモリ量（swpd）、空きメモリ量（free）、バッファとして使われてい
るメモリ量（buff）、ページキャッシュとして使われているメモリ量（cache）
Swap：ディスクからスワップインされたメモリ量（si）、ディスクにスワップアウトされたメモリ量
（so）
IO：ブロックデバイスに送られたブロック（bi）、ブロックデバイスから受け取ったブロック（bo）
System：毎秒での割り込み数（in）、毎秒のコンテキストスイッチ数（cs）
CPU：ユーザモードのCPU使用率（us）、システムモードのCPU使用率(sy)、アイドル状態の
CPU使用割合(id)、入出力が待機中のCPUの割合(wa)
18
CPUネックの時の挙動
kthr（カーネルスレッド）とCPU（CPU使用率）に注目
r ：実行可能なカーネルスレッド。実行中のスレッド＋CPU 待ちのスレッド
b：待機キュー内のカーネルスレッド。入出力待ちのスレッド。
us：ユーザーモードで使用されたCPU時間の割合。プロセスはそのアプリケー
ションコード内部で実行。
sy：システムモードで使用されたCPU時間の割合。カーネルプロセスおよび
カーネルリソースへのアクセスが必要な他のプロセスによって消費されたCPU。
id：CPUが入出力の保留せずにアイドル状態になっている時間の割合
wa：ローカルディスクおよびNFSマウントのディスクの入出力が保留中で、
CPUがアイドルだった時間の割合
vmstat 2 の出力（AIX）
# vmstat 2
kthr
memory
----- ---------------r b avm fre
1 0 22478 1677
1 0 22506 1609
0 0 22498 1582
2 0 22534 1465
2 0 22534 1445
2 0 22534 1426
3 0 22534 1410
2 1 22557 1365
page
faults
cpu
------------------------- ----------------- --------------re pi po fr sr cy in sy cs us sy id wa
0 0 0 0 0 0 188 1380 157 57 32 0 10
0 0 0 0 0 0 214 1476 186 48 37 0 16
0 0 0 0 0 0 248 1470 226 55 36 0 9
0 0 0 0 0 0 238 903 239 77 23 0 0
0 0 0 0 0 0 209 1142 205 72 28 0 0
0 0 0 0 0 0 189 1220 212 74 26 0 0
0 0 0 0 0 0 255 1704 268 70 30 0 0
0 0 0 0 0 0 383 977 216 72 28 0 0
実行キューの数がCPUの数より多いときは、
CPU待ちのスレッドが存在している。
CPU待ちのスレッドが多くなると、
パフォーマンスへの影響も大きくなる
us+syの割合が100%になっている。
us+syの時間が80%を超えると、
プロセスが実行キューで待っている間に
時間を費やしてしまう可能性がある。
waが25%を超えている場合は、
ディスクの入出力が過多になっている
（ →iostatコマンドなどによる確認）
（参考）AIX InfoCenter：パフォーマンスマネージメントガイド –CPUパフォーマンスモニター
http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/aixbman/prftungd/cpuperf.htm
19
（参考）複数CPUマシンの各CPU使用率の確認
sarコマンドを用いると各CPUごとの使用率を確認できる
sar –P ALL 2 3 の出力（AIX）
# sar -P ALL 2 3
AIX aixsmphost 2 5 00049FDF4D01
17:30:50 cpu
17:30:52 0
1
2
3
17:30:54 0
1
2
3
17:30:56 0
1
2
3
Average
0
1
2
3
-
02/22/04
%usr %sys %wio %idle
8
92
0
0
0
4
0
96
0
1
0
99
0
0
0 100
2
24
0
74
12 88
0
0
0
3
0
97
0
1
0
99
0
0
0 100
3
23
0
74
11 89
0
0
0
3
0
97
0
0
0 100
0
0
0 100
3
23
0
74
10
0
0
0
3
90
4
1
0
24
0
0
0
0
0
0
96
99
100
74
各CPUごとの使用率
上記4CPUの平均
vmstatで表示されるのは4CPUの平均になる
kthr
memory
page
faults
cpu
------- ------------------- -------------------------- --------------------- --------------r b avm fre
re pi po fr sr cy in
sy cs us sy id wa
1 1 255733 15930 0 0 0 0 0 0 476 49437 27 2 24 74 0
1 1 255733 15930 0 0 0 0 0 0 473 48923 31 3 23 74 0
1 1 255733 15930 0 0 0 0 0 0 466 49383 27 3 23 74 0
表示回数を指定すると、
最後に各CPUの平均を表示
20
３．メモリ使用量の確認
vmstatコマンド
メモリネック時の挙動
memory（メモリの使用量）、page（ページング）に注目
avm：vmstatサンプルが収集された時点でアクティブ
であった仮想メモリ・ページ数(1ページ＝4kB)
pi：ページング・スペースからページインされるページの数。ページング・
fre：空きメモリ・ページの平均数
スペースは仮想メモリの一部で、ディスクに常駐している部分。
po：ページング・スペースにページアウトされるページの数
vmstat 2 の出力（AIX）
# vmstat 2
kthr
memory
page
faults
cpu
-------- ----------------- ---------------------------- ------------------ ----------------r b
avm fre re pi po fr sr cy in
sy cs us sy id wa
0 3 113659 135 0 2 2 108 323 0 516 1563 797 25 7 2 66
0 2 113661 122 0 3 2 120 375 0 527 1622 871 13 7 2 79
0 3 113662 128 0 10 3 134 432 0 644 1434 948 22 7 4 67
1 5 113858 238 0 35 1 146 422 0 599 5103 903 40 16 0 44
0 3 113969 127 0 5 10 153 529 0 565 2006 823 19 8 3 70
0 3 113983 125 0 33 5 153 424 0 559 2165 921 25 8 4 63
0 3 113682 121 0 20 9 154 470 0 608 1569 1007 15 8 0 77
0 4 113701 124 0 3 29 228 635 0 674 1730 1086 18 9 0 73
pi、poが常にゼロ以外の場合は、
メモリのボトルネックが存在する可能性
ページインやページアウトが多発すると、
入出力待ちが多くなる
（参考）AIX InfoCenter：パフォーマンスマネージメントガイド –メモリー・パフォーマンス
http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/aixbman/prftungd/memperf.htm
21
メモリ使用量の確認
svmonコマンド（AIX Only）
Pid(プロセスID)、Command（コマンド）、Inuse（実メモリ内のページ数）、Pin
（ページアウトされないページ数）、Pgsp（ページングスペースのページ数）、
Virtual（仮想アドレスのページ数）、64-bit（プロセスが64ビットか否か）、
Mthrd（マルチスレッドか否か）、Lpage(大規模ページがあるか否か)
4KB単位で表記される。
プロセスIDを指定
svmon –P <process id> の出力（AIX）
使用しているメモリの情報
（４KB/ページ）
# svmon -P 22556
------------------------------------------------------------------------------Pid Command
Inuse
Pin Pgsp Virtual 64-bit Mthrd LPage
22556 java
61244 4065
0 50404
N
Y
N
Vsid
21010
3affd
32019
0
3c5de
Esid Type Description
LPage Inuse Pin Pgsp Virtual
4 work working storage
- 19718 0
0 19718
3 work working storage
- 12247 0
0 12247
d work text or shared-lib code seg
- 11985 0
0 11985
0 work kernel seg
- 6052 3998 0 6052
- pers /dev/hd2:315563
- 1389 0
-
22
（参考）Windowsのパフォーマンスモニター
perfmon
システムモニタ
メモリやプロセッサ、ネットワークなどの利用状況のリアルタイムデータを収集
グラフやヒストグラム、レポート形式で表示
パフォーマンスログと警告
データを記録するためのログを構成
閾値による警告の設定
メモリやプロセッサの利用状況を
リアルタイムで表示
「パフォーマンスと警告」のカウンタログ
CSV形式で記録し、表計算ソフトで開くことも可能
23
４．アクセス数の確認
システムの前段にあるWebサーバーのアクセスログを確認
アクセスログからシステムのスループットを算出
IHSのアクセスログの時間表示はリクエストを受けた時間を指す
リクエストを受けた時間
access.log
9.170.251.57 - - [14/Nov/2005:15:19:07 +0900] "GET /Sample/sleep HTTP/1.1" 503 424
9.170.251.98 - - [14/Nov/2005:15:18:57 +0900] "GET /Sample/sleep HTTP/1.1" 200 417
9.188.52.31 - - [14/Nov/2005:15:19:01 +0900] "GET /Sample/sleep HTTP/1.1" 200 417
9.170.251.57 - - [14/Nov/2005:15:19:04 +0900] "GET /Sample/sleep HTTP/1.1" 200 417
9.170.251.98 - - [14/Nov/2005:17:27:17 +0900] "GET /JVM/input.html HTTP/1.1" 200 1494
9.170.251.98 - - [14/Nov/2005:17:27:18 +0900] "GET /JVM/theme/Master.css HTTP/1.1" 200 731
9.170.251.98 - - [14/Nov/2005:17:28:51 +0900] "GET /JVM/input.html HTTP/1.1" 200 1494
9.170.251.98 - - [14/Nov/2005:17:28:51 +0900] "GET /JVM/theme/Master.css HTTP/1.1" 200 731
9.170.251.98 - - [14/Nov/2005:17:30:13 +0900] "GET /JVM/input.html HTTP/1.1" 200 1494
9.170.251.98 - - [14/Nov/2005:17:30:13 +0900] "GET /JVM/theme/Master.css HTTP/1.1" 200 731
9.170.251.98 - - [14/Nov/2005:17:30:46 +0900] "GET /JVM/input.html HTTP/1.1" 304 9.170.251.98 - - [14/Nov/2005:17:30:46 +0900] "GET /JVM/theme/Master.css HTTP/1.1"
IHSのアクセスログから処理したリクエスト数を時間間隔で割ると、
スループット（アクセス件数/秒）が計算できる
24
TCPコネクションの確認
TCPコネクション数や接続ステータスの確認。
netstatコマンド
netstat –an
a：ESTABLISHED以外の接続も表示
n：出力を数字のみに抑制（IPアドレスやサービスの逆引きを行わない）
実際にはgrepコマンドと併用して、注目するポート番号のみを表示させる
netstat -an の出力の一部（AIX）
左からプロトコル、受信バッファで溜まっているバイト数、
送信バッファで溜まっているバイト数,
接続元のアドレスとポート番号、
接続先のアドレスとポート番号、ステータスを示す。
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address
Foreign Address
tcp
0
0
*.80
*.*
tcp4
0
0
*.111
*.*
tcp4
0
0
*.199
*.*
tcp
0
0
*.443
*.*
tcp
0
0
*.512
*.*
・・・・・
tcp
0
0
*.9080
*.*
tcp
0
0
*.9443
*.*
ステータスがLISTEN＝外部からの接続待ち状態。
(state)
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
LISTEN
IHSでListenしているポート番号
WASのアプリケーションサーバーが持つ
HTTPトランスポートがListenされている
（管理コンソールからアプリケーション
サーバーを選択し、 [Webコンテナー]→
[Webコンテナー・トランスポート・チェー
ン] ）
25
（参考）接続のステータス
接続を
受け入れられる状態
クライアントが接続要求を出す。
ステータスSYN_SENTに
SYN_SENT
SYN
SYN｜ACK
ACK
ESTABLISHED
リクエストのやり
リクエストのやり取
のやり取り
FIN | ACK
ACK
LAST_ACK
接続要求に対して返事。
ステータスがSYN_RCVDに
SYN_RCVD
ESTABLISHED
接続の切断要求を出す。
ステータスがFIN_WAIT1に
FIN_WAIT1
切断要求受信確認。
相手からのFINを待つ。
ステータスがFIN_WAIT2に
CLOSE_WAIT
接続の切断要求を出す。
ステータスLAST_ACKに
LISTEN
FIN | ACK
FIN_WAIT2
ACK
TIME_WAIT
26
TCPコネクションの確認
指定したポートに対しESTABLISHEDになってるものが、現在クライアントとサー
バー間で生成された接続の数
ポートに対して有効な接続数を表示させるコマンドの例
netstat –an | grep “¥.<Port番号>” | grep ESTABLISHED | wc –l
クライアント－Webサーバー間の接続数
netstat –an の出力（AIX）
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address
Foreign Address
tcp
0
0
*.80
*.*
tcp4
0
0 9.188.52.38.80
9.170.251.98.3034
tcp4
0
0 9.188.52.38.80
9.170.251.98.3035
tcp4
0
0 9.188.52.38.80
9.170.251.98.3036
tcp4
0
0 9.188.52.38.80
9.170.251.98.3037
tcp4
0
0 9.188.52.38.80
9.170.251.98.3038
(state)
LISTEN
ESTABLISHED
ESTABLISHED
ESTABLISHED
ESTABLISHED
ESTABLISHED
Webサーバー－アプリケーションサーバー間の接続数
netstat -anの出力（AIX）
Active Internet connections (including servers)
Proto Recv-Q Send-Q
Local Address
Foreign Address
tcp
0
0
*.9080
*.*
tcp4
0
0 9.188.52.71.9080
9.188.52.38.37780
tcp4
0
0 9.188.52.71.9080
9.188.52.38.37781
IPアドレス9.170.251.98から
IHSの80番ポートに対し
5本のリクエストを処理中。
IPアドレス9.188.52.38（IHS）から
9080番(HTTPトランスポート)に対し
2本のリクエストを処理中。
(state)
LISTEN
ESTABLISHED
ESTABLISHED
27
５．TivoliPerformanceViewerを用いたモニタリング
JVMヒープ
スレッドプール
コネクションプール
セッション
TPVで取得可能な情報の一覧
28
Tivoli Performance Viewer
WASのモニタリングツール
リアルタイムでデータを表示。ログの取得、再生も可能
V6からは管理コンソールに統合
[モニターおよびチューニング]→[Performance Viewer]
右側に取得値がグラフで表示
（表にすることも可能）
対象サーバーを選択して、
[モニターの開始]を押す
モニターする項目を選んで
[モジュールの表示]
29
PMI (Performance Monitoring Infrastructure)
WASのコンポーネントのデータをモニターするインターフェイス
TPVはPMIを介してパフォーマンスデータを取得、表示
JVMヒープ使用率、JDBC接続プール内
のオブジェクト数、スレッドプール内のスレッド数、
セッション作成数・・・・などの情報
WebServer
WebServer
TPV
PMIを介してデータを取得、表示
PMI
Application
Application
Server
Server
(WebContainer)
(WebContainer)
Application
Application
Server
Server
(EJBContainer)
(EJBContainer)
DB
V6からデフォルトで使用可能に
PMIで取得する情報のレベル
（統計セット）を「基本」、「拡張」、
「すべて」、「カスタム」から選択
「＋」をクリックすると、そのレベルで
取得できる情報の一覧が表示される
30
JVMヒープのモニタリング
「JVMランタイム」カテゴリ
JVMについてのデータを取得
4つのサブカテゴリの表示には、JVM始動時にJVMPIをONにしておく必要
汎用JVM関数に –XrunpmiJvmpiProfiler を指定
カウンター
レベル
説明
FreeMemory
拡張
JVMランタイムの空きメモリ（kB）
HeapSize
基本
JVMランタイムの合計メモリ（kB）
UpTime
基本
JVMの実行時間（秒）
UsedMemory
基本
JVMランタイムの使用メモリ（kB）
GCCount
全て
GCの呼び出し回数
GCIntervalTime
全て
2つのGC呼び出し間の平均時間（ミリ秒）
GCTime
全て
GCの平均所要時間（ミリ秒）
ObjectAllocateCount
全て
ヒープに割り振られたオブジェクトの数
ObjectFreedCount
全て
ヒープ内から開放されたオブジェクトの数
ObjectMovedCount
全て
ヒープ内で移動されたオブジェクトの数
ThreadEndedCount
全て
終了したスレッドの数
ThreadStartedCount
全て
開始したスレッドの数
WaitForLockTime
全て
スレッドがロック待ちする平均時間
WaitsForLockCount
全て
スレッドがロック待ちする回数
JVMランタイム
ガーベッジコレクション
オブジェクト
スレッド
モニター
31
JVMヒープの分析
JVMランタイム
使用メモリ、空きメモリ、合
計メモリを確認
GCによりメモリが大きく開放
される場合は最大ヒープサ
イズを小さくする
GCの開放量は85％以内が望
ましい。
ガーベッジコレクション
GCの回数、呼び出し間隔、
所要時間を確認
GCの平均所要時間％＝
(GC平均所要時間)/(GCの
平均所要時間＋GC呼び出
し平均間隔)×100が15％未
満になるのが望ましい
TPVでの確認にはJVMPIの
設定が必要
合計メモリは一定
使用メモリが大きく減っている点がGCの発生。
例では1回のGCにより、約50%程度空きを確保し、
時間間隔もほぼ一定。
GC呼び出し間隔は増加し、GC所要時間は減少傾向。
GC平均所要時間％は減少にある。例では1.31％。
JVMPIの使用はパフォーマンスに影響を与える可能性がある
GC発生
32
verbose:gc
ガーベッジコレクションの実行状況を記録
native_stderr.logに出力
GCの頻度、GCによるオブジェクトのCompaction、ヒープの拡張、収縮などの情報を取得
汎用JVM引数に -Xverbosegclog:<path>/<filename> を指定して変更
デフォルトではOFF。管理コンソール上で設定の必要
冗長ガーベッジ・コレクションにチェック or –verbose:gc
verbose:GCを解析するためのツールも存在
（ → 4章「Webシステムにおけるチューニング項目」の「JVMヒープのチューニング」 p.92）
GC発生時のverbose:gc
native_stderr.log
GCの発生回数
前回のGCからの所要時間
<AF[7]: Allocation Failure. need 720 bytes, 5087 ms since last AF>
<AF[7]: managing allocation failure, action=1 (0/50330176) (2097088/2097088) >
<GC(7): GC cycle started Wed Aug 24 18:35:02 2005
<GC(7): 18641632 bytes, 39% free (20738720/52427264), in 219 ms >
<GC(7): mark: 195 ms, sweep: 24 ms, compact: 0 ms >
<GC(7): refs: soft 0 (age >= 32), weak 10, final 224, phantom 1 >
<AF[7]: completed in 232 ms>
GCの所要時間
オブジェクトのCompactionが発生すると、以下のメッセージが書き込まれる
<GC(22): moved 336139 objects, 19365984 bytes, reason=14, used 11592 more bytes>
さらにヒープの拡張が発生すると、以下のメッセージが書き込まれる
<GC(32): expanded heap by 17563648 to 117635584 bytes, 33% free>
33
（参考）verbose:gcの出力
GC発生時のverbose:gcの出力内容
Compaction発生時に追加される内容
1行目 ：AFがAllocation Failureの発生、[ ]内の数字がJVM起動後にAFが発生した回数を示して
います。need 720byteがAllocationに必要な容量、5087ms since last AFが前回のAllocation
Failureからの経過時間を示しています。上記の例では、5087ms後に今回（7回目）のAllocation
Failureが発生したことを示しています。
2行目 ：action=0は実行されたアクションを0から6までの数字で示したものです。上記の例の１は
Wilderness（巨大オブジェクト用の保管領域）の使用を避けるためにGCを実行したことを示していま
す。（）内の数字は（空き容量/Heap領域） を示しています。
3行目 ：GCが開始した時刻を示しています。
4行目 ：GCの結果、開放された容量とその割合、所要時間を示しています。例では18641632byte
が開放され、空き領域は全体の39％、20738720/52427264byteになったことを示し、その作業に
219msかかったことになります。
5行目 ：このGCのmarkフェーズ（オブジェクトのマーキング）、sweepフェーズ（不要オブジェクトの
開放）、compact（空き領域の整理）の所要時間を示しています。上記の例ではcompactの作業は
行っていません。
6行目 ：GCの間に見つかったオブジェクトの数を示しています。
7行目 ：Allocation Failure発生後からの経過時間を示しています。
Compactionによって移動したオブジェクトの数とサイズ、Compactionの理由、増加された容量を示
しています。以上の例では、336139個、計19365984byteのオブジェクトを移動させた結果、さらに
11592byteの領域が確保できたことを示しています。
ヒープが拡張した時に追加される内容
17563648byteの領域が拡張され、全体として領域が117635584byte（空き領域は33％）になったこ
とを示しています。
34
HeapDump
テストを実施したときに、アプリケーションサーバーのJVMヒープが圧迫されてい
ることが判断できた際に、JVMヒープ上の全てのオブジェクトの情報を見るために
出力する
JVMの作業ディレクトリ（変数で出力先の指定があればそのディレクトリ）にPHD
形式で以下のファイル名で出力
heapdump.YYYYMMDD.HHMMSS.<process_ id>.phd （Windows）
heapdump<process id>.<CPU_TIME>.phd （AIX、Linux）
テキストファイルで出力させるには環境変数IBM_JAVA_HEAPDUMP_TEXTの設定が必
要
ヒープを使い切ったとき以外で取得するには、環境変数IBM_HEAPDUMPをtrue
に設定。
wsadminを用いた手動によるHeapDumpの出力
wsadmin> set obj [$AdminControl queryNames WebSphere:type=JVM,process=server1,*]
wsadmin> $AdminControl invoke $obj generateHeapDump
オブジェクトのアドレス、サイズ、名前と参照されているオブジェクトアドレスをリス
トで表示
HeapDumpの解析には解析ツールが必要
（ → 4章「Webシステムにおけるチューニング項目」の「JVMヒープのチューニン
グ」 p.93）
35
JVMヒープのチューニング
GCから適切なJVMヒープサイズを判断
ヒープ領域が拡張と収縮を繰り返すことなく、定常
GC終了後に30％以上の空き領域を常に確保
チューニングの例
ヒープ領域が定常状態になるまでにGCが頻発
ヒープ領域がすぐに最大ヒープサイズとなり、GC終了後の空きが
30％確保できていない
最大ヒープサイズが小さいので、GC終了後に空き領域が30％確保できるように
大きくする
GCの平均所要時間％が15％以上と、発生頻度が高い
初期ヒープサイズが小さいので、定常となった値を初期ヒープサイズと設定
GC実施後、空き領域が-Xminf（デフォルト0.3）で指定された領域を確保できない
と、ヒープは拡張される
GC後に大きい空き領域を確保するため、-Xminfを大きくする
1回のGCの開放量が85％と大きく、所要時間が長い
初期ヒープサイズが大きいので、ヒープサイズを小さくする
36
スレッドプールのモニタリング
「スレッドプール」カテゴリ
WASの各スレッドプールのデータを取得
カウンター
レベル
説明
ActiveCount
拡張
同時にアクティブなスレッド数
ActiveTime
全て
スレッドがアクティブ状態の平均時間（ミリ秒）
CleardThreadHangCount
全て
クリアされたハングスレッドの数
ConcurrentHungThreadCount
全て
停止されたハングスレッドの数
CreateCount
全て
作成されたスレッドの総数
DeclaredThreadHungCount
全て
停止宣言されたハングスレッドの数
DestoryCount
全て
破棄されたスレッドの総数
PercentMaxed
全て
全てのスレッドが使用中である時間の平均比率
PoolSize
基本
プール内の平均スレッド数
スレッド・プール
37
Webコンテナースレッドの分析
すべてのスレッドが使用中である状態が続くようであれば、スレッドの最
大サイズの増加かスレッド数の制御を検討
プールサイズ、アクティブスレッド数、全てのスレッドが使用中である時間の
比率を確認
全てのスレッドが使用中
プールサイズが最大スレッド数に達しており、
その全てがアクティブになっている
38
コネクションプールのモニタリング
「JDBC接続プール」カテゴリ
コネクションプールの情報を取得
カウンター
レベル
説明
AllocateCount
全て
割り振られた接続の総数
CloseCount
基本
プールから破棄された接続の総数
ConnectionHandleCount
全て
特定の接続プールで使用されている接続オブジェクト（接続
ハンドル）の総数（v5.0データソースのみ）
CreateCount
基本
作成された接続の総数
FaultCount
拡張
プールにある接続タイムアウトの数
FreePoolSize
基本
プールにある空き接続の数
JDBCTime
拡張
JDBC呼び出しの実行にかかる平均時間（ミリ秒・v5.0デー
タソースのみ）
ManagedConnectionCount
全て
特定の接続プールで使用されているManagedConnectionオ
ブジェクト（物理接続）の数（v5.0データソースのみ）
PercentMaxed
全て
全ての接続が使用中である時間の平均比率
PercentUsed
基本
使用中のプールの平均比率
PoolSize
基本
接続プールのサイズ
PrepStmtCacheDiscardCount
拡張
破棄されたPrepaerdStatementの数
ReturnCount
全て
プールに戻された接続の総数
UseTime
基本
接続が割り振られてから戻されるまでの平均時間（ミリ秒）
WaitTime
基本
接続が割り振られるまでの平均待ち時間（ミリ秒）
WaitingThreadCount
基本
同時に接続待ちをするスレッドの平均数
JDBC接続プール
39
コネクションプールのチューニング
チューニングの例
「PercentMaxed」が100％の状態が続き、「WaitThreadCount」が多い
「FaultCount」の値が多い
接続タイムアウトによってエラーとなったリクエスト数が多く、接続タイムアウト値を
大きくするか、コネクションプールの最大接続数を大きくする
「ManagedConnectionCount」の変動が多い
コネクションプール内のコネクションオブジェクトが不足し、接続待ちが多いので、
最大接続数を大きくする
物理接続の作成と破棄が繰り返されており、未使用タイムアウト値、または最小
接続数を大きくする
「PrepStmtCacheDiscardCount」が多い
PreparedStatementキャッシュが廃棄されており、ステートメント・キャッシュ・サイ
ズが不足しているので大きくする
40
セッションのモニタリング
「サーブレット・セッション・マネージャー」カテゴリ
セッションの情報を取得
カウンター
レベル
説明
ActivateNonExistSessionCount
全て
セッションタイムアウトとなり存在しないセッションに対す
るリクエスト数
ActiveCount
全て
リクエストにより現在アクセスしているセッションの総数
AffinityBreakCount
全て
中段されたセッションアフィニティの数
CacheDiscardCount
全て
分散セッションでキャッシュから破棄されたセッションの数
CreateCount
全て
作成されたセッションの数
ExternalReadSize
拡張
外部から読み取られたセッションのサイズ
ExternalReadTime
拡張
外部からのセッションの読み取りにかかる時間（ミリ秒）
ExternalWriteSize
拡張
外部に書き込んだセッションのサイズ
ExternalWriteTime
拡張
外部へのセッションの書き込みにかかる時間（ミリ秒）
InvalidateCount
全て
無効化されたセッションの数
LifeTime
全て
平均セッション持続時間（ミリ秒）
LiveCount
基本
現在活動中のセッションの数
NoRoomForNewSessionCount
全て
「オーバーフローの許可」にチェックされていない時に適用。
最大セッション数を越えたため、新規セッションリクエスト
を処理できない数
SessionObjectSize
全て
セッションオブジェクトのサイズ
TimeSinceLastActicvated
全て
直前のアクセス時刻と現在の時刻の差（ミリ秒）
TimeoutInvalidationCount
全て
タイムアウトで無効になったセッションの数
サーブレット・セッション・マネージャー
41
セッションのチューニング
チューニングの例
「LiveCount」が非常に大きく、長時間と
どまっている場合は、セッションオブジェ
クトがヒープに残り続けているので、
「ActiveCount」との差が大きいのであれ
ば、セッションタイムアウト値を小さくす
る
「NoRoomForNewSessionCount」がカウ
ントされている場合、無効なセッションが
作成されている。メモリ内の最大セッショ
ンカウント値を大きくする
分散セッションで、
「CacheDiscardCount」がカウントされて
いる場合、セッションのスペース不足に
より、セッションオブジェクトが破棄が発
生。最大セッションカウント値を大きくす
る
「ActivateNonExistSessionCount」がカ
ウントされている場合、タイムアウトによ
り無効化されたセッションへのアクセス
が起こっているので、セッションタイムア
ウト値を大きくする
ActiveCountに比べ、
LiveCountの差が大きい例。
（アクセスのないセッションが多く残る）
セッションオブジェクトの
破棄が発生した例
42
TPVで取得可能な情報の一覧
「カスタム」画面から取得可能なデータの説明を見ることが可能
カテゴリ
取得情報
EnterpriseBean
応答時間やライフサイクルのアクティビティ、Enterprise BeanメソッドおよびEnterprise Beanによって使用される
リモートインターフェースの情報
JDBC接続プール
新規に作成された接続数など、データソースの接続プールについての使用情報
JＣＡ接続プール
JＣＡについての使用情報
JVMランタイム
使用メモリなどJVMに関する情報
サーブレットセッションマネージャ
アクティブなセッションの平均数など、HTTP セッションの使用状況
スレッドプール
オブジェクトリクエストブローカー (ORB) スレッドのスレッドプール、HTTP要求を処理するWebコンテナープール
についての情報
トランザクションマネージャー
アクティブ・トランザクションの平均数など、トランザクションマネージャーのパフォーマンス情報
Webアプリケーション
ロードされたサーブレットの数、サーブレット要求の応答時間など、選択されたサーバーの情報
ORB
オブジェクト参照ルックアップ時間などORBに関する情報
ワークロード管理
ＩＩＯＰ要求の数など、クライアントとサーバーのワークロード管理に間する情報
動的キャッシング
メモリ内のキャッシュサイズなど、動的キャッシュサービスに関する情報
Webサービス
ロードされたWebサービスの数など、Webサービスに関する情報
Webサービスゲートウェイ
同期要求の数など、Webサービスゲートウェイに関する情報
システムデータ
CPU使用率など、マシン(ノード)に関する情報（複数のサーバー・バージョンのノード・エージェントでのみ使用可
能）
Alarm マネージャー
アラームに関する情報
オブジェクトプール
オブジェクトプールに関する情報
スケジューラー
スケジューラーサービスに関する情報
HA マネージャー
HAマネージャーに関する情報
DCS統計
DCSスタックを使用した送信メッセージ数など、DCSに関する情報
SIBサービス
SIBサービスに関する情報
43
（参考）基本レベルで取得できる情報一覧
Enterprise Bean.MethodReadyCount
Enterprise Bean.PassiveCount
Enterprise Bean.ReadyCount
Enterprise Bean.CreateCount
Enterprise Bean.MessageCount
Enterprise Bean.MethodCallCount
Enterprise Bean.MethodResponseTime
Enterprise Bean.RemoveCount
Enterprise Bean.PooledCount
JDBC 接続プール.WaitingThreadCount
JDBC 接続プール.UseTime
JDBC 接続プール.CloseCount
JDBC 接続プール.WaitTime
JDBC 接続プール.PercentUsed
JDBC 接続プール.FreePoolSize
JDBC 接続プール.CreateCount
JDBC 接続プール.PoolSize
JVM ランタイム.UpTime
JVM ランタイム.HeapSize
JVM ランタイム.UsedMemory
JCA 接続プール.WaitingThreadCount
JCA 接続プール.UseTime
JCA 接続プール.CloseCount
JCA 接続プール.WaitTime
JCA 接続プール.FreePoolSize
JCA 接続プール.CreateCount
JCA 接続プール.PoolSize
サーブレット・セッション・マネージャー.LiveCount
システム・データ.CPUUsageSinceLastMeasurement
スレッド・プール.PoolSize
トランザクション・マネージャー.ActiveCount
トランザクション・マネージャー.RolledbackCount
トランザクション・マネージャー.CommittedCount
Web アプリケーション.ServiceTime
Web アプリケーション.RequestCount
44
（参考）拡張レベルで取得できる情報一覧
Enterprise Bean.MethodReadyCount
Enterprise Bean.ReturnsDiscardCount
Enterprise Bean.PassiveCount
Enterprise Bean.ReadyCount
Enterprise Bean.ReturnsToPoolCount
Enterprise Bean.CreateCount
Enterprise Bean.MessageCount
Enterprise Bean.MethodCallCount
Enterprise Bean.MethodResponseTime
Enterprise Bean.RemoveCount
Enterprise Bean.PooledCount
Enterprise Bean.LiveCount
テンプレート.HitsInMemoryCount
テンプレート.MissCount
JDBC 接続プール.FaultCount
JDBC 接続プール.WaitingThreadCount
JDBC 接続プール.UseTime
JDBC 接続プール.JDBCTime
JDBC 接続プール.CloseCount
JDBC 接続プール.WaitTime
JDBC 接続プール.PercentUsed
JDBC 接続プール.PrepStmtCacheDiscardCount
JDBC 接続プール.FreePoolSize
JDBC 接続プール.CreateCount
JDBC 接続プール.PoolSize
JVM ランタイム.FreeMemory
JVM ランタイム.UpTime
JVM ランタイム.HeapSize
JVM ランタイム.UsedMemory
JCA 接続プール.WaitingThreadCount
JCA 接続プール.UseTime
JCA 接続プール.CloseCount
JCA 接続プール.WaitTime
JCA 接続プール.FreePoolSize
JCA 接続プール.CreateCount
JCA 接続プール.PoolSize
サーブレット・セッション・マネージャー.LifeTime
サーブレット・セッション・マネー
ジャー.NoRoomForNewSessionCount
サーブレット・セッション・マネージャー.ExternalReadSize
サーブレット・セッション・マネージャー.LiveCount
サーブレット・セッション・マネージャー.ExternalWriteTime
サーブレット・セッション・マネージャー.ExternalWriteSize
サーブレット・セッション・マネージャー.ExternalReadTime
システム・データ.CPUUsageSinceServerStarted
システム・データ.CPUUsageSinceLastMeasurement
スレッド・プール.PoolSize
スレッド・プール.ActiveCount
トランザクション・マネージャー.ActiveCount
トランザクション・マネージャー.LocalTimeoutCount
トランザクション・マネージャー.RolledbackCount
トランザクション・マネージャー.GlobalTimeoutCount
トランザクション・マネージャー.LocalBegunCount
トランザクション・マネージャー.LocalTranTime
トランザクション・マネージャー.GlobalTranTime
トランザクション・マネージャー.GlobalBegunCount
トランザクション・マネージャー.CommittedCount
Web アプリケーション.ServiceTime
Web アプリケーション.RequestCount
Web アプリケーション.ErrorCount
Web アプリケーション.ConcurrentRequests
サーバー.ServerResponseTime
サーバー.IIOPRequestCount
サーバー.ConcurrentRequestCount
45
（参考）パケットキャプチャー
パケットキャプチャーが必要なとき
HTTPヘッダーの確認
KeepAlive接続の確認
TCP/IPチューニングの実施後の確認
iptraceコマンド（AIX Only）
ネットワークを流れるパケットをキャプチャーするコマンド
iptraceコマンドでキャプチャを開始し、killコマンドで停止
ipreportコマンドによりフォーマット
iptraceの一例
ipreportの一例
-a : ARPパケットを除く
-b : 双方向のパケットを記録
-d : パケット送信先を指定
-s : パケット受信元を指定
-p : ポート番号を指定
-n : パケット出力の先頭にパケット番号を記載
-s : 各行先頭にプロトコルを記載
AIX以外では、ethereal（フリーソフト）などを用いてキャプチャーを実施
46
（参考）iptrace
（iptraceコマンド実行）
#iptrace -ab -d 9.188.52.71 -s 9.170.251.98 -p 80 /tmp/trace/itrace
（プロセス番号確認）
#ps -ef | grep iptrace
root 38242 1 0 18:28:43
- 0:00 iptrace -ab -d 9.188.52.71 -s 9.170.251.98 -p 80 /tmp/trace/itrace
root 43666 42878 0 18:28:59 pts/4 0:00 grep iptrace
（キャプチャ終了したら、iptraceのプロセス番号をkill）
ipreportの内容
#kill -9 38242
Packet Number 4
ETH: ====( 406 bytes received on interface en0 )====18:29:26.547582540
（ipreportでフォーマット）
ETH: [ 00:0e:38:91:a2:41 -> 00:09:6b:2e:93:5d ] type 800 (IP)
#ipreport -ns /tmp/trace/itrace > /tmp/trace/ireport
IP: < SRC = 9.170.251.98 >
パケットの受信元と送信先
受信元と送信先のポート番号
IP: < DST = 9.188.52.71 > (silver2)
IP: ip_v=4, ip_hl=20, ip_tos=0, ip_len=392, ip_id=58485, ip_off=0 DF
IP: ip_ttl=124, ip_sum=d5ea, ip_p = 6 (TCP)
TCP: <source port=4614, destination port=80(http) >
TCP: th_seq=9219e724, th_ack=698ffbb7
TCP: th_off=5, flags<PUSH | ACK>
TCP: th_win=32120, th_sum=9545, th_urp=0
TCP: 00000000 47455420 2f204854 54502f31 2e310d0a |GET / HTTP/1.1..|
TCP: 00000010 41636365 70743a20 696d6167 652f6769 |Accept: image/gi|
TCP: 00000020 662c2069 6d616765 2f782d78 6269746d |f, image/x-xbitm|
TCP: 00000030 61702c20 696d6167 652f6a70 65672c20 |ap, image/jpeg, |
TCP: 00000040 696d6167 652f706a 7065672c 20617070 |image/pjpeg, app|
TCP: 00000050 6c696361 74696f6e 2f766e64 2e6d732d |lication/vnd.ms-|
TCP: 00000060 65786365 6c2c2061 70706c69 63617469 |excel, applicati|
TCP: 00000070 6f6e2f76 6e642e6d 732d706f 77657270 |on/vnd.ms-powerp|
TCP: 00000080 6f696e74 2c206170 706c6963 6174696f |oint, applicatio|
TCP: 00000090 6e2f6d73 776f7264 2c206170 706c6963 |n/msword, applic|
TCP: 000000a0 6174696f 6e2f782d 73686f63 6b776176 |ation/x-shockwav|
TCP: 000000b0 652d666c 6173682c 202a2f2a 0d0a4163 |e-flash, */*..Ac|
TCP: 000000c0 63657074 2d4c616e 67756167 653a206a |cept-Language: j|
TCP: 000000d0 610d0a41 63636570 742d456e 636f6469 |a..Accept-Encodi|
TCP: 000000e0 6e673a20 677a6970 2c206465 666c6174 |ng: gzip, deflat|
TCP: 000000f0 650d0a55 7365722d 4167656e 743a204d |e..User-Agent: M|
TCP: 00000100 6f7a696c 6c612f34 2e302028 636f6d70 |ozilla/4.0 (comp|
TCP: 00000110 61746962 6c653b20 4d534945 20362e30 |atible; MSIE 6.0|
HTTPリクエストヘッダーの内容
TCP: 00000120 3b205769
6e646f77 73204e54 20352e31 |; Windows NT 5.1|
TCP: 00000130 290d0a48 6f73743a 20392e31 38382e35 |)..Host: 9.188.5|
TCP: 00000140 322e3731 0d0a436f 6e6e6563 74696f6e |2.71..Connection|
TCP: 00000150 3a204b65 65702d41 6c697665 0d0a0d0a |: Keep-Alive....|
47
<blank page>
48
問題解析のアプローチ
49
パフォーマンスとボトルネック
パフォーマンスが良いシステム
パフォーマンスの指標はレスポンスタイム(秒)とスループット(処理件数/秒)
「飽和点における最大同時ユーザー数が高く、スループットが高く、レスポンスタイムが
短い」
その際、各サーバーのCPUが100％であればシステムが最大の処理能力を発揮してい
ることになる。
ボトルネックが発生したときに起こる現象
飽和点に達してもCPUが使われていない
レスポンスが遅い、またはスループットが出し切れていない。
飽和点に達してから、スループットが急激に悪化する
スループットは同時アクセス数と同時に増加。
やがて一定になり、さらに増加すると徐々に低下
レスポンスタイムは同時アクセス数が増加してもほぼ一定。
やがて増加し始める
スループットが一定になり、レスポンスタイムが
上がり始める点が飽和点（saturation point）。
このときCPUが100％であれば、そのシステムは
最大の処理能力を発揮。
50
ボトルネックの要因
ハードウェア
ミドルウェア
CPU、メモリ、I/O
EdgeやIHS、WAS、DBのチューニングパラメータ
ネットワーク
アプリケーション
ボトルネックの特定が重要
ボトルネックの特定が重要
51
ボトルネック発見のアプローチ（１）
現象
飽和点に達しても
CPUが使われていない場合 1/4
飽和点に達してもCPUが使われていない
予測
各サーバーの処理能力に余裕があるにも関わらず、スループットやレスポンスタイム
が頭打ち
どこかでリクエストが滞留しているのでは？
検証
まずは滞留している場所を突き止める
取得項目
IHSのアクセスログ、プラグインのログ、WASのSystemOutログ（要求メトリックを設定）
IHSのアクセスログからレスポンスタイムを取得
要求メトリックを取得し、各コンポーネントのレスポンスタイム取得
それぞれのレスポンスタイムの差から各コンポーネントでの処理時間を計算
著しく処理時間の長いところに注目！
52
ボトルネック発見のアプローチ（１）
飽和点に達しても
CPUが使われていない場合 2/4
著しく処理時間の長いところに注目！
Webサーバーで遅い
Webサーバー内で待ちが発生している可能性
プラグインからWebコンテナー間で遅い
WebコンテナーからEJBコンテナー間で
遅い
Webコンテナー前で待ちが発生している可能性
プラグインとWebコンテナー間のネットワーク遅延の可能性
EJBコンテナーの前で待ちが発生している可能性
Webコンテナー、EJBコンテナー間のネットワーク遅延の可能性
Webコンテナー内のアプリケーションの処理が問題の可能性
EJBコンテナーで遅い
EJBコンテナー内のアプリケーションの処理が問題の可能性
EJBコンテナーからデータベース間で
遅い
クライアントのレスポンスタイムと
Webサーバーとの差が大きい
DBの前で待ちが発生している可能性
EJBコンテナー、DB間のネットワーク遅延の可能性
DB自体の処理で遅延している可能性
負荷ツールからWebサーバーの間のネットワーク遅延の可能性
Webサーバーの前で待ちが発生している可能性
53
ボトルネック発見のアプローチ（１）
飽和点に達しても
CPUが使われていない場合 3/4
以下の順番で遅延の原因を特定
1．待ちが発生している場合の確認方法
TPVでスレッドプールを確認、Webサーバーはログを確認
Webサーバーの前で待ちが発生している場合
同時リクエスト数を超えると、超えたことを示す警告がWebサーバーのエラーログに出力され
る
Webサーバーの最大アクセス数を大きくする
Webコンテナー、EJBコンテナーの前で待ちが発生している場合
TPVで各々のスレッドプールを確認し、使用率が100％のまま維持され続けていることを確認
Webコンテナ、EJBコンテナの最大サイズを大きくする
データベースの前で待ちが発生している場合
TPVでコネクションプールを確認し、使用率が100％のまま維持されていることを確認
コネクションプールの最大接続数を上げる。DBのMAXAPPLSパラメータを上げる
2．ネットワーク遅延の確認方法
各々のネットワーク機器、サーバーで帯域での使用率やパケット量を確
認
ネットワーク機器のパラメータ調整、ネットワークカードやケーブルを変える
3．アプリケーション処理の遅延の確認方法
アプリケーションのコードを確認、必要があればプロファイラーを使用
アプリケーションの変更
54
ボトルネック発見のアプローチ（１）
飽和点に達しても
CPUが使われていない場合 4/4
アプリケーション分析
レスポンスの悪いロジックの特定
レスポンスの悪いロジックがある程度特定できている場合
IHSのアクセスログから、時間がかかっているリクエストURLを判断し、レスポンス
の悪いロジックに目星を付ける
関連するコードを追う
処理が複雑なときはプロファイラーを使用し、ボトルネックを探し出す
プロファイラー
アプリケーションのボトルネックやメモリリークを発見するためのツール
各クラス、メソッド単位の実行時間
オブジェクトのサイズ、参照関係
ヒープの使用状況、ガーベッジ情報
ボトルネックと判断された箇所についてロジックの見直しを行う
55
ボトルネック発見のアプローチ（２）
現象
レスポンス、スループットが
出し切れていない場合 1/5
飽和点に達するまでにレスポンスが悪い
飽和点に達するまでにスループットが悪い
予測
レスポンスタイムはいいが、スループットが悪い
負荷がかけきれていないのでは？
レスポンスタイムもスループットも悪い
どこかでマシンの処理能力が限界に達してるのでは？
検証
負荷が正しくかけられているか、マシンのハードウェアスペックに異
常はないかを突き止める
56
レスポンス、スループットが
出し切れていない場合 2/5
ボトルネック発見のアプローチ（２）
取得項目
負荷ツールのログ、各マシンのハードウェアスペック確認
負荷ツールのログを見る
負荷は想定よりも低い
負荷ツールマシン（クライアントマシン）のスペック確認
CPUなどが非常に高い
クライアントが負荷をかけきれていない可能性
負荷クライアントの増加
スペックに問題はない
負荷ツールの設定の確認
負荷は正しくかけられている
各サーバーマシンのスペック確認
CPUなどが非常に高いマシンがある
ハードウェアスペックがネックになって
処理がそこで遅くなっている！
CPUなどが高いマシンはない
リクエストの滞留によるスループット、
レスポンスタイム低下の可能性。
ボトルネック発見のアプローチ（１）の手順に。
57
レスポンス、スループットが
出し切れていない場合 3/5
ボトルネック発見のアプローチ（２）
取得項目（アプリケーションサーバー）
TPV（JVMヒープ確認）、verbose:gc(native_stderr.log)
ハードウェアスペックがネックになって
処理がそこで遅くなっている
WebサーバーのCPUなどが高い
マシンの処理能力の限界の可能性
アプリケーションサーバーのCPUなどが高い
アプリケーションサーバーのJVMヒープ、GCを確認
GCの発生頻度が低く、1度のGCで
全体の85%以上が開放される
JVMの初期ヒープサイズが高すぎることで
GCにかかる時間が多いことによる
パフォーマンスダウンの可能性
JVMのヒープサイズを下げる
GCの発生頻度が高く、1度のGCで
30％しか開放されない。
ヒープの拡張も頻繁に起こる
ヒープを圧迫している
オブジェクトの調査
（可能なら）JVMのヒープサイズを上げる
データベースのCPUなどが高い
データの書き込み頻度が高すぎる可能性
不適切なSQL文によるデータベースに過大な
負荷をかけている可能性
マシンの処理能力の限界の可能性
58
レスポンス、スループットが
出し切れていない場合 4/5
ボトルネック発見のアプローチ（２）
取得項目
TPV（セッション確認）、HeapDump
（可能なら）JVMのヒープサイズを上げる
ヒープを圧迫している
オブジェクトの調査
アプリケーションサーバーのセッションオブジェクトを確認
活動中のセッションに比べ、アクセス中のセッションが少ない
かつ、セッションサイズが非常に大きい
セッションオブジェクトがヒープを圧迫している可能性
セッションオブジェクトの数、
サイズともに問題はない
セッションオブジェクトの数、タイムアウトを減らす
アプリケーションの再検討
HeapDumpを取得し、ヒープ内のオブジェクトを確認
数が多いオブジェクト、巨大オブジェクトの発見
アプリケーションを再検討
59
ボトルネック発見のアプローチ（２）
レスポンス、スループットが
出し切れていない場合 5/5
データベースがネックとなる場合
書き込み頻度
DiｓｋへのI/Oでネック
書き込み頻度を検討。セッションDBの場合はWASの管理コンソールから指定可能
また、以下に示すようにSQL文を改善することで効果が得られる可能性も大
DBのデッドロック
スナップショットを取得し、デッドロックの確認
SQL文の調査
最適なSQL文は、もっとも少ないリソースを使用し、もっとも早く抽出可能な文
アクセスパス
INDEX
JOIN処理
発行されるSQL文を再検討
60
ボトルネック発見のアプローチ（３）
現象
飽和点に達した後、
スループットの急激な悪化 1/2
飽和点に達した後、スループットが急激に悪化する
予測
システムの処理能力が限界値を大きく超えた
どこかでマシンの処理能力が限界に達し、ダウン（もしくはハング）しているのでは？
検証
マシンのハードウェアに異常はないかを突き止める
61
ボトルネック発見のアプローチ（３）
飽和点に達した後、
スループットの急激な悪化 2/2
取得項目
各マシンのハードウェアスペックを確認
システムのアプリケーションにアクセス
全て正常
各サーバーマシンのスペック確認
ハードウェアスペックがネックになって、
処理が遅くなっている可能性。
ボトルネック発見のアプローチ（２）の手順に。
CPUなどが非常に高い
マシンがある
CPUなどが高い
マシンはない
リクエストの滞留によるスループット、
レスポンスタイム低下の可能性。
ボトルネック発見のアプローチ（１）の手順に。
レスポンスがないリクエストが存在
ハングしてるマシンを確認、そのマシンに対して問題判別を行う
アプリケーションサーバーの
OutOfMemory
HeapDumpを取得し、ヒープ内のオブジェクトを確認
数が多いオブジェクト、巨大オブジェクトの発見
62
アプリケーションを再検討
Webシステムにおけるチューニング項目
63
キューイングネットワーク
各コンポーネントでアクセス数を徐々に絞り込む
キューの最大数に達したとき、システムのCPUが適正使用率になるように設定
アプリケーションの構成も考慮に入れる
静的コンテンツが大半ならWebコンテナーのアクセス数に比べ、Webサーバーのアクセ
ス数が多くなるように設定
データソースにアクセスするアプリケーションが大半であれば、Webコンテナーへのア
クセス数とデータソースのアクセス数はあまり差をつけすぎないように設定
Clients
WebServer
WebContainer
150
待ち行列:50
スレッドプール
50
（TCPインバウンドチャネル）
待ち行列:100
Remote
EJBClient
EJBContainer
70
DataSource
最大接続プール
サイズ 30
ORBスレッドプール 待ち行列:40
最大サイズ:20
30
最大クライアント数
150
50
20
20
0
DB
64
キューイングネットワークのチューニング項目
Webサーバー
最大クライアント数
待ち行列
スレッドプール（WebContainer）の最大サイズ、最小サイズ
ORBスレッドプール
ListenBackLog
Webコンテナー
MaxClients、ThreadsPerChild
スレッドプールの最大サイズ、最小サイズ
データソース
最大接続数、最小接続数
接続タイムアウト（最大接続数を超えたリクエストの待ち時間）
65
Webシステムのチューニング
1.OSのチューニング
2.クライアントとWebサーバー間のチューニング
WebServer
WebServer
plugin
3.Webサーバーとアプリケーションサーバー間のチューニング
Application
Application
Server
Server
4.JVMヒープのチューニング
(WebContainer)
(WebContainer)
5.EJBコンテナーのチューニング
Application
Application
Server
Server
(EJBContainer)
(EJBContainer)
6.データベース接続に関するチューニング
DB
66
１．OSのチューニング
TCP/IP接続のタイムアウトはOSが所有するパラメータに依存
SYNを投げてから
どれくらい待つか？
SYN
SYN_SENT
アイドル状態の接続を
いつまでアクティブにし
ておくか？
ESTABLISHED
再送のためのパケットを
どれくらいの間隔で投げ
るか？
LISTEN
SYN｜ACK
ACK
リクエストのやり取り
SYN_RCVD
ESTABLISHED
FIN | ACK
ACK
FIN_WAIT2状態で
FIN_WAIT1 どれくらい待つか？
CLOSE_WAIT
FIN | ACK
LAST_ACK
ACK
FIN_WAIT2
TIME_WAIT状態で
どれくらい待つか？
TIME_WAIT
67
TCP/IP接続に関するタイムアウト値
AIX V5.3の例
tcp_keepinit （デフォルト150 /0.5秒単位）
TCPコネクション初期タイムアウト値
ネットワーク障害などでSYNに対する返事がないとき、この値に従って接続が破棄される
tcp_keepidle （デフォルト14400 /0.5秒単位）
tcp_keepintvl （デフォルト150 /0.5秒単位）
通信を行っていないTCPコネクションを確認する時間
tcp_keepidle時に送信したパケットに返事がない際に、
再度確認のために送るパケットの送信間隔
tcp_keepcnt (デフォルト8)
tcp_keepidle時に送信したパケットに返事がない際に
再度確認のために送るパケットの数
(tcp_keepidle)+(tcp_keepintvl)×(tcp_keepcnt)=2時間10分。
デフォルトでは2時間10分経てば接続はOSが切断する
tcp_finwait2 （デフォルト1200 /0.5秒単位）
FIN_WAIT2状態で待つ時間
tcp_timewait （デフォルト1 /15秒単位）
TIME_WAIT状態で待つ時間
接続を終了するまえにサーバー側は「TIME_WAIT」状態で15秒は待つ
68
２．クライアントとWebサーバー間のチューニング
チューニングポイント
クライアント数、バックログ、KeepAlive接続、SSL通信、ファイル圧縮
ファイル圧縮
KeepAlive接続
スレ
ッド
スレ
ッド
スレ
ッド
WebServer
WebServer
親プロセス
Application
Application
Server
Server
(WebContainer)
(WebContainer)
子プロセス
plugin
SSL通信設定
処理待ち
クライアント数、
バックログ
access_log
69
クライアント数のチューニング - worker
AIX、HPUX、Soralis、Linuxはworkerモジュールをサポート
複数の子プロセスが各々複数のスレッドでリクエスト処理
<IfModule worker.c>内で定義
ThreadLimit 25
ServerLimit 64
スレッド
スレッド
スレッド
子プロセス
子プロセス
スレッド
スレッド
スレッド
スレッド
スレッド
スレッド
待機状態にあるスレッドの最大値
ThreadPerChild 25
待機状態にあるスレッドの最小値
子プロセス
MaxSpareThreads 75
同時に処理できるリクエストの最大数
MinSpereThreads 25
親プロセス
起動時のプロセス数の初期値
MaxClients 600
設定可能なサーバープロセスの上限値
StartServers 2
ThreadsPerChildに設定可能な上限値
各プロセスが生成するスレッド数
MaxRequestsPerChild 0
各プロセスが処理できるリクエスト数の最大値
70
クライアント数のチューニング – mpm_winnt
Windoｗｓはmpm_winntモジュールをサポート
子プロセスは1つのみ。子プロセスが複数のスレッドでリクエスト処理
<IfModule mpm_winnt.c>内で定義
ThreadLimit 2048
ThreadsPerChild 250
MaxRequestsPerChild 0
親プロセス
同時に処理できるリクエストの最大数は
ThreadsPerChildで設定
子プロセス
スレッド
スレッド
スレッド
スレッド
スレッド
スレッド
スレッド
スレッド
スレッド
71
クライアントチューニング時の注意
ServerLimit × ThreadsPerChild ≧ MaxClients
親プロセスが生成する子プロセスの数と子プロセスの生成する数の積が実
際にリクエストを処理する上限になる
満たさないとき、error_logに以下のWarningが出力される
MaxClinets150に対し、ThreadsPerChild25、ServerLimit1に設定すると、結局最大で25のリク
エストしか扱えない。
WARNING: MaxClients of 150 would require 6 servers,
and would exceed the ServerLimit value of 1.
Automatically lowering MaxClients to 1. To increase,
please see the ServerLimit directive.
処理可能な最大リクエスト数を超えたときのerror_log
使用率に余裕がある場合は、Webサーバーのボトルネックが考えられるので、
増加を検討
[Fri Aug 26 13:13:04 2005] [error] server reached MaxClients setting,
consider raising the MaxClients setting
[Mon Sep 19 16:01:14 2005] [warn] Server ran out of threads to serve requests.
Consider raising the ThreadsPerChild setting
72
バックログのチューニング
同時に処理可能な数を越えるリクエストが来た場合、あふれたリクエストは処理
待ちの状態で待たされる
OSのパラメータでも設定
ListenBackLog
AIXではsomaxconn (デフォルト1024)
処理待ちのキューの数を指定
httpd.confには記載がないが、デフォルトは511
処理を待たせてもエラーを返さないようにする場合は、ListenBackLogを増加させ、処
理待ちのリクエスト数を多くする
処理待ち可能なキューを確認する方法（AIX only）
（ポート番号におけるTCP番号を確認）
host1@root[/usr/IBMIHS2047/conf]netstat -aAn | grep LISTEN | grep 80
73686200 tcp
0
0 *.80
*.*
LISTEN
（kdbコマンド実行し、以下のコマンドを入力）
host1@root[/usr/IBMIHS2047/conf]kdb
(0)> sockinfo 73686200 tcpcb
---- SOCKET INFO ----(@ 73686200)---type........ 0001 (STREAM)
opts........ 000E (ACCEPTCONN|REUSEADDR|KEEPALIVE)
linger...... 0000 state....... 0180 (PRIV|NBIO)
pcb..............@73686154 proto............@024C8CE8
lock.............@736CF280 head.............@00000000
q0...............@00000000 q................@00000000
q0len....... 0000 qlen........ 0000 qlimit...... 01FF
timeo....... 0000 error....... 0000 special..... 0A08
pgid............. 00000000 oobmark.......... 00000000
qlimitが処理待ち可能なキューの最大数
（16進数）を示す。デフォルトでは1FF＝511。
73
KeepAlive接続のチューニング
TCPコネクションを再利用し、毎回ハンドシェイクを繰り返す
ことによるオーバーヘッドを抑える。
複数の画像、フレームを含むコンテンツに有効
KeepAlive On
MaxKeepAliveRequests 100
KeepAlive接続の有無
1つのKeepAlive接続で受け付けるリクエスト数
一画面のフレーム、画像などの合計数程度
KeepAliveTimeout 15
次のリクエストまでに接続を保持する時間（秒）
リクエストが来るまで接続を確保するため、1-2秒程度の短い値が推奨される
74
SSL通信に関する設定
SSLコネクションの流れ
Server Hello
使用する暗号化アルゴリズムを指定
セッションIDがここで渡される
Client Hello
SSLアクセスを要求
暗号化方式のリストを渡す
サーバー証明書を送信
サーバー証明書がない場合に
メッセージを送信
クライアント証明を行う場合に
クライアント証明書の提示を要求
クライアント証明書を送信
Server Hello Done
一連の Server Hello 終了
セッションキーを生成する元と
なるデータを送信
サーバー側がクライアントと認
証を行うためのデータを送信
決定された
暗号化アルゴリズムを宣言
決定された
暗号化アルゴリズムを宣言
Finished
データの送信終了
（セッション確立）
Finished
データの送信終了
75
SSLハンドシェイクのキャッシュ
SSLハンドシェイクは接続に負担がかかるので、二回目からはセッション
IDをキャッシュする
ErrorLogのレベルをInfo以上にするとハンドシェイクのキャッシュが確認可能
1はSSLの新規接続
error.log （LogLevel info）
[Wed Sep 21 13:44:00 2005] [info] Session ID: AABjqsqzy6X02W9ygvVu4Sg9/CpYWFhYQzDlEAAAAAA=
[Wed Sep 21 13:44:00 2005] [info] New Session ID: 1
[Wed Sep 21 13:44:02 2005] [info] Session ID: AABjqsqzy6X02W9ygvVu4Sg9/CpYWFhYQzDlEAAAAAA=
[Wed Sep 21 13:44:02 2005] [info] New Session ID: 0
[Wed Sep 21 13:45:16 2005] [info] Session ID: AABjqsqzy6X02W9ygvVu4Sg9/CpYWFhYQzDlEAAAAAA=
[Wed Sep 21 13:45:16 2005] [info] New Session ID: 0
0はSSLセッションを再利用
SSLV3Timeout、SSLV2Timeoutを設定すると、SSLセッションIDのキャッシュ
にタイムアウトを設定できる
SSLV3はデフォルト120秒、SSLV2はデフォルト40秒
error.log （LogLevel info）
[Sun Nov 13 19:37:08 2005]
[Sun Nov 13 19:37:08 2005]
[Sun Nov 13 19:37:10 2005]
[Sun Nov 13 19:37:10 2005]
[Sun Nov 13 19:38:16 2005]
[Sun Nov 13 19:38:16 2005]
[Sun Nov 13 19:38:39 2005]
[Sun Nov 13 19:38:39 2005]
[Sun Nov 13 19:39:23 2005]
[Sun Nov 13 19:39:23 2005]
[info] Session ID: AABcXpR4hkJDp2yf9Jln0jQV7sVYWFhYQ3cXVAAAAAA=
[info] New Session ID: 1
[info] Session ID: AABcXpR4hkJDp2yf9Jln0jQV7sVYWFhYQ3cXVAAAAAA=
[info] New Session ID: 0
タイムアウトが来るとSSLハンドシェイクをやり直し、
[info] Session ID: AABcXpR4hkJDp2yf9Jln0jQV7sVYWFhYQ3cXVAAAAAA=
新しいセッションIDになる。
[info] New Session ID: 0
[info] Session ID: AABcXpR4hkJDp2yf9Jln0jQV7sVYWFhYQ3cXVAAAAAA=
[info] New Session ID: 0
[info] Session ID: AABcXsIqf40cfw2DV9ILA8lf+dRYWFhYQ3cX2wAAAAE=
[info] New Session ID: 1
76
SSLCipherSpec
SSLCipherSpecによる暗号化方式の指定
Client Helloでクライアントが対応している暗号化方式リストを渡す
Server Helloで暗号化を指定
SSL_RCA_WITH_RC4_128_MD5
SSL_RCA_WITH_RC4_128_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL2_RC4_128＿WITH_MD5
SSL_RSA_EXPORT_WITH_RC4_40_MD5
・・・・・・
IHSのSSLCipherSpecディレクティブで暗号化方式を指定
SSL_RC4_WITH_RC4_128_MD5
複数指定も可能
指定されたものに対応していない
ブラウザからの接続は拒否される
IHSv6.0、SSLv3で対応している
暗号化方式
77
ファイル圧縮の設定
ファイルを圧縮することにより、通信帯域の負荷を軽減し、通信時間を短縮
サーバー側には圧縮する分だけ負荷となるので、圧縮すべきものを見極める必
要がある
対応しているWebブラウザには制限がある
httpd.conf
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
pdfファイルやPOSTメソッドのリクエストは圧縮しない
SetEnvIfNoCase Request_URI "¥.pdf$" no-gzip
SetEnvIfNoCase Request_Method POST no-gzip
DeflateFilterNote ratio
圧縮比率をログに出力させる
</IfModule>
LogFormat '"%r" %b (%{ratio}n) "%{User-agent}i" %s' deflate
CustomLog logs/deflate_log deflate
deflate_log
"GET
"GET
"GET
"GET
/index.html HTTP/1.1" 793 (47) "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 200
/httpTech.main.gif HTTP/1.1" 110163 (99) "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 200
/httpTech.view1.gif HTTP/1.1" 1001 (94) "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 200
/sample.pdf HTTP/1.1" 848303 (-) "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 200
圧縮比率がログの（）内に表示される
圧縮しないときより、送信バイト数が47％に減少
pdfファイルは圧縮されない
“GET /index.html HTTP/1.1" 1617 (-) "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" 200
78
３．Webサーバーとアプリケーションサーバー間の
チューニング
チューニングポイント
Webコンテナースレッドプール、KeepAlive接続
プラグインの最大割り振り数、プラグイン構成ファイルの再ロード間
隔
Webコンテナーの
スレッドプール
プラグインの
最大割り振り数
WebServer
WebServer
Application
Application
Server1
Server1
(WebContainer)
(WebContainer)
plugin
設定ファイル
pluin-cfg.xml
KeepAlive接続
プラグイン構成ファイルの
再ロード間隔
http_plugin.log
Application
Application
Server2
Server2
(WebContainer)
(WebContainer)
Application
Application
Server3
Server3
(WebContainer)
(WebContainer)
79
チャネルフレームワーク
チャネル・フレームワーク
WAS共通のネットワークサービスをトランスポートチェーンとして定義
トランスポートチェーンは各プロトコルごとのチャネルを持ち、各々のチャネル
階層ごとに設定を行う。
Webコンテナーのスレッドプール
9080番などのポート番号をもつトランスポートチェーンのTCPインバウンド
チャネルに結びつけられて用いられる
Web Container
Webコンテナ・トランスポート・チェーン
トランスポート
チェーン
WCInboundDefault
Webコンテナー
インバウンド・チャネル
WCC_2
HTTP
インバウンド・チャネル
HTTP_2
TCP
インバウンド・チャネル
TCP_2
Port
:9080
ユーザーパーシスタント（キープアライブ）接続の有無
パーシスタントタイムアウトの設定
アクセスロギング設定（HTTPトランスポートログ）
スレッド・プールの指定
（複数チャネルで共通のスレッドプールを
指定可能）
80
Webコンテナー・トランスポートチェーン
トランスポートチェーン
3つのインバウンドチャネル階層を持つ
TCPインバウンドチャネルでは、
ポート、スレッドプールの選択、
最大のオープン接続数、タイムアウト、
アクセス制御を設定
Webコンテナーインバウンドチャネルでは、
判断ウェイト、書き込みバッファサイズを設定
HTTPインバウンドチャネルでは、
判断ウェイト、最大パーシスタント要求数、
ユーザーパーシスタント（キープアライブ）
接続の有無、タイムアウト、アクセスロギング、
エラーロギングの有無を設定
81
Webコンテナー・スレッドプールのチューニング
トランスポートチェーンはWebContainerというスレッドプールに結びつけられてい
る
スレッドプール内の設定
最大サイズ
最小サイズ
スレッド非活動タイムアウト
最大スレッド数を超えた割り振りの許可の有無
WebContainerスレッドプールの
最小、最大スレッド数を指定
プラグインからのリクエストは
TCPトランスポートチャネル内のキューが受け
取る
コンテナーのスレッドはクライアントから独立
プラグインからのリクエストを
TCPインバウンドチャネルの
キューで受ける
TCPインバウンドチャネルのキューから
スレッドプール（WebContainer）に
処理を送る
WebContainer
WebContainer
WebServer
WebServer
plugin
キューの最大接続数は20000
82
最小/ 最大スレッド数は30/50
KeepAlive接続のチューニング
Webサーバー、アプリケーションサーバー間のKeepAlive接続
各サーバーのトランスポートごとに設定
最大パーシスタント要求数
ユーザ・パーシスタント（キープアライブ接続）
1つの接続を流れるリクエストの数
0 or 1に設定すると、KeepAlive接続は行わない。
デフォルト100
アプリケーションサーバー選択し、
トランスポートを選択。
[HTTPインバウンド・チャネル]画面から設定
デフォルトON
チェックを外すとKeepAlive接続は行わない。
パーシスタントタイムアウト
KeepAlive接続が有効なときのタイムアウト
次のリクエストまでに接続を保持する時間
デフォルト30秒
83
V5でのKeepAlive接続
V5ではKeepAliveが有効になってる時間内は、スレッドはクライアントから
のリクエストに占有される
MaxKeepAliveConnection
ConnectionKeepAliveTimeout
同時にKeepAlive接続を行うコネクションの最大数（デフォルト：全スレッドの90%）
KeepAlive接続の要求待ち時間（デフォルト：5秒）
リクエストが増大し、KeepAliveスレッドが特定のクライアントに占有されて
しまうと、それ以外は残りで処理することになる
KeepAliveスレッドに時間がかかる場合、
残りのリクエストはこちらで処理
WebContainer
WebContainer
10%
NON-KeepAlive
WebServer
WebServer
plugin
KeepAlive
90%
KeepAlive
レスポンスが終了しても
タイムアウトが来るまで占有
84
V6でのKeepAlive接続
V6からはWebコンテナースレッドとクライアントが独立
KeepAliveのTimeoutによる切断を待たずに次のリクエストの処理
を実行可能。
V6ではデフォルトで全てのスレッドがKeepAlive対応
非KeepAlive接続の確保やタイムアウトの短縮が必要ない
処理待ちのリクエストはTCPのキューに残り、
１リクエストの処理終了後、スレッドが渡され
処理を実行。
WebContainer
WebContainer
WebServer
WebServer
plugin
KeepAlive
KeepAlive
KeepAlive
KeepAlive接続の切断を待たずに
次のリクエストの処理が実行される
85
プラグイン割り振り数のチューニング
MaxConnections
プラグインが各サーバーに処理を委ねる最大数
デフォルトは「-1」（無制限）
割り振られるものがなくなれば、503（Service Temponary Unavailable）がクライアントに
返される。
待ちには入らず、即時にクライアントに返される
WASの管理コンソールからも設定可能
プラグインの生成時に
プラグイン構成ファイルに反映される。
<Server ConnectTimeout="10" ExtendedHandshake="false" MaxConnections="10"
Name="mercuryNode01_server1" ServerIOTimeout="0" WaitForContinue="false">
<Transport Hostname="mercury" Port="9080" Protocol="http"/>
<Transport Hostname="mercury" Port="9443" Protocol="https">
<Property Name="keyring" Value="C:¥IBM¥WebSphere¥Plugins6¥etc¥pluginkey.kdb"/>
<Property Name="stashfile" Value="C:¥IBM¥WebSphere¥Plugins6¥etc¥pluginkey.sth"/>
</Transport>
アプリケーションサーバー選択し、[追加プロパティ]→
</Server>
[Webサーバープラグインプロパティ]を選択。
アプリケーションサーバーが処理できる接続の最大数
WebServer
WebServer
全て埋まった時にプラグインが
クライアントに503を返す。
Application
Application
Server1
Server1
maxConnections=10
Application
Application
Server2
Server2
maxConnections=5
plugin
この場合はTCPインバウンドチャネルにはストックされず、
即時にクライアントにエラーが返る。
86
構成ファイルの再ロード間隔
RefreshInterval
構成ファイルplugin-cfg.xmlの情報が読み込まれる間隔
デフォルト60秒
情報の更新から反映までの遅延として許容できる値に設定
Webサーバー選択し、[追加プロパティー]から
[プラグイン・プロパティー]選択
plugin-cfg.xml
<Config ASDisableNagle="false" AcceptAllContent="false" AppServerPortPreference="HostHeader"
ChunkedResponse="false" FIPSEnable="false" IISDisableNagle="false" IISPluginPriority="High"
IgnoreDNSFailures="false" RefreshInterval="60" ResponseChunkSize="64" VHostMatchingCompat="false">
87
４．JVMヒープのチューニング
チューニングポイント
JVMの初期ヒープサイズ・最大ヒープサイズ
ガーベッジコレクション（GC)
Javaでは不要になったオブジェクトをメモリ領域から開放する作業をJVMが実施
GCはパフォーマンスに影響するので、適切にGCを実施するように調整
Application
Application
Server
Server
物理メモリ領域
アプリケーションサーバーが
用いるメモリ領域
JVMの初期ヒープサイズ、
最大ヒープサイズ
-Xmx （JVMヒープの最大サイズ）
-Xms （JVMヒープの初期サイズ）
GC：JVMが行うメモリ管理
この処理が他のスレッドを停止し、
CPUに負荷をかける
88
JVMヒープサイズのチューニング
アプリケーションサーバーを選択、[Javaおよびプロセス管理]→[プロセス定
義]→[Java仮想マシン]
初期ヒープサイズ、最大ヒープサイズを指定
その他引数が必要な際は、汎用JVM引数の欄に指定
verbose:gcの出力 → 冗長ガーベッジコレクションの設定をON
GC頻度確認のために
verbose:gcをnative_stderr.logに出力
ヒープサイズの設定
89
JVMヒープサイズの設定
初期設定値
パフォーマンステストにて設定値を調整
起動時の早い段階からGCが頻発
すぐに最大ヒープサイズまで上昇し、その後もGCにより領域が確保できて
いない（目安は30％以下）
ヒープサイズが大きいとき
TPVによる使用メモリ、空きメモリ、合計メモリの確認
verbose:gcにてGC発生頻度の確認
ヒープサイズが小さいとき
初期ヒープサイズ：50MB
最大ヒープサイズ：256MB
1回のGCの開放量が大きくなる（目安は85％以上）
通常時は初期ヒープサイズで対応し、ピークに備えて最大ヒープサイズ
まで確保
初期ヒープサイズと最大ヒープサイズを同じに設定すると、通常時にGCの
開放量やGCにかかる時間が大きくなる
90
verbose:gc
GC発生状況の把握
ヒープサイズが大きいときの例
native_stderr.log
1回のGCの開放量が高く（85%以上）、
時間も多く取られている（長いと判断する目安は3秒）
<AF[2]: Allocation Failure. need 524 bytes, 555510 ms since last AF>
<AF[2]: managing allocation failure, action=1 (524328096/536869376)>
<GC(2): GC cycle started Sat Nov 19 16:43:40 2005
<GC(2): freed 1358776 bytes, 97% free (525686872/536869376), in 1067 ms>
<GC(2): mark: 41 ms, sweep: 1726 ms, compact: 0 ms>
<GC(2): refs: soft 0 (age >= 32), weak 0, final 412, phantom 0>
<AF[2]: completed in 1767 ms>
<GC(3): freed 0 bytes, 96% free (520100792/536869376), in 1169 ms>
<GC(4): freed 0 bytes, 91% free (489700016/536869376), in 1409 ms>
ヒープサイズが小さいときの例
native_stderr.log
<AF[60]: Allocation Failure. need 800016 bytes, 48 ms since last AF>
<AF[60]: managing allocation failure, action=2 (26827152/88865280)>
<GC(60): GC cycle started Fri Aug 12 14:30:23 2005
<GC(60): freed 320080 bytes, 30% free (27147232/88865280), in 237 ms>
<GC(60): mark: 219 ms, sweep: 18 ms, compact: 0 ms>
<GC(60): refs: soft 74 (age >= 1), weak 1, final 20, phantom 0>
<AF[60]: completed in 242 ms>
1回のGCの開放量が小さく（30％以下）、
短期間でGCが頻発している
<GC(61): freed 38120 bytes, 29% free (26383920/88865280), in 283 ms>
<GC(62): freed 17760 bytes, 30% free (27162144/90438144), in 143 ms>
91
verbose:gcの解析ツール
GCCollector (v1.2)
GUIベースでverbose:gc出力をグラフ化して解析可能
JDK 1.2.2以上のJavaランタイム環境で動作
以下から自由にダウンロード可能
http://www.alphaworks.ibm.com/tech/gcdiag/
jfreechart-0.9.21.jarとjcommon-0.9.6.jarをダウンロードし、インストールディレクトリのlib以下に配置
する必要
http://sourceforge.net/projects/jfreechart
GCCollectorコマンドを実行
verbose:gcのサマリー、
生データ、一覧表を表示
GC間隔、GC所要時間、
GC後のヒープ領域、AllocFailureを、
時系列にグラフ化表示
各GCを整形して表示
92
HeapDumpの解析ツール(Heaproots)
Heaproots
CUIベースのHeapDump解析ツール
JDK1.3.1 SR3 (excluding z/OS) 、 1.4.1 SR1 以上を推奨
以下から自由にダウンロード可能
http://www.alphaworks.ibm.com/tech/heaproots
HeapDumpファイル（テキスト）をheaprootsに読み込ませて実行
ｊava –jar HR205.jar <heapdump.txt>
ｊava –jar <HR_root>¥HR205.jar <heapdump.txt>実行時の出力
>java -jar C:¥IBM¥WebSphere¥AppServer6¥HeapRoots205¥HR205.jar
C:¥IBM¥WebSphere¥AppServer6¥profiles¥Custom01¥hea
pdump.20050925.170523.4032.txt
・・・・・（中略）・・・・
Successfully opened 'C:¥IBM¥WebSphere¥AppServer6¥profiles¥Custom01¥heapdump.2005
0925.170523.4032.txt'. This filename was derived from 'C:¥IBM¥WebSphere¥AppServe
r6¥profiles¥Custom01¥heapdump.20050925.170523.4032'.
Dump comments
: // Version: J2RE 1.4.2 IBM Windows 32 build
cn142-20050609
// Breakdown - Classes: 9721, Objects: 248968,
ObjectArrays: 52899, PrimitiveArrays: 71720
// EOF: Total 'Objects',Refs(null) :
383308,914835(244817)
Dump has flags
: false
# Objects
: 383,308
# Refs
: 914,835
# Unresolved refs : 0
Heap usage
: 22,953,760
Total object range : 669,388,960
Extra stats
: unavailable before processing
HR Memory Usage
: 12/35 mb
Enter: o{a,s,t,d,m,n}, g{c,s}, t{c,s,n}, i, p, d{t,d,m} or help for more info
>
93
HeapDumpの解析ツール(Heaproots)
オブジェクトのサイズ順ソートの例
どのオブジェクトがヒープを占めているのかの判断
tsコマンド実行
tsコマンド実行時の出力
Enter: o{a,s,t,d,m,n}, g{c,s}, t{c,s,n}, i, p, d{t,d,m} or help for more info
> ts
Heaprootのプロンプトからts入力
Enter name to filter on or '-' for no filtering [-]
>
Enter range of lines to print in format 'M','L-U','-U' or 'L-' [1-10]
>1-5
サイズ順で1位から5位までを表示させる
Tabulating all objects, sorted by total-size
Count Total-size Type Name
------------------------------------------------------------------------------58,293 6,328,592 char[]
ヒープ内のオブジェクトをサイズ順に表示
61,649 1,972,768 java/lang/String
(Countはオブジェクト数を示す)
31,760 1,016,320 java/util/HashMap$Entry
ヒープ上をどのオブジェクトが占めているのかがわかる
1,423 746,176 byte[]
9,810 587,360 array of java/lang/Object
Displayed results : 1-5
Matched types : 12,915 / 12,915
Usage count
: 324,767 / 324,767
Total size
: 20,420,672 / 20,420,672
94
HeapDumpの解析ツール(HeapAnalyser)
HeapAnalyser (V1.3.5)
GUIベースのHeapDump解析ツール
JDK1.4.1以上のJavaランタイム環境で動作
以下から自由にダウンロード可能
http://www.alphaworks.ibm.com/tech/heapanalyzer
ha135.jarを実行
ｊava –jar ha135.jar
ヒープ内のオブジェクトの
階層構造を表示
ヒープ内のオブジェクトを
サイズ順にソート
HeapDumpのサマリー
95
セッションオブジェクトの設定
管理コンソールからアプリケーションサーバーを選択し、[Webコンテナー
設定]→[セッション管理]
メモリー内の最大セッションカウント、セッションタイムアウトを設定。
デフォルトは1000セッション、タイムアウトは30分。
「オーバーフローの許可」は非分散環境のみ有効
メモリー内のセッション数と
オーバーフローの許可
セッション・タイムアウト
96
５．EJBコンテナーのチューニング
チューニングポイント
ORBスレッドプール
Application
Application
Server
Server
(EJBClient)
(EJBClient)
Application
Application
Server
Server
(EJBContainer1)
(EJBContainer1)
ORBスレッドプールサイズ
DB
Application
Application
Server
Server
(EJBContainer2)
(EJBContainer2)
97
ORBスレッドプールのチューニング
EJBクライアントとEJBコンテナーが同一アプリケーションサーバー上に配置した
場合、同一アプリケーションサーバー上で処理
リモートのEJBクライアントからのアクセスに対する最大・最小スレッド数の設定
デフォルトは最大50スレッド、最小10スレッド
アプリケーションサーバー選択し、[コンテナーサービス]→[ORBサービス]→[ス
レッド・プール]
同一アプリケーションサーバー上にあれば
ローカルで処理
Application
Application Server
Server
EJB Client
EJB Container
ORBスレッドプールの
最小、最大スレッド数を指定
リモートのEJBクライアントからのアクセス
Application
Application
Server
Server
EJB Client
Application
Application
Server
Server
EJB Container
98
EJB WLMのパラメータ
アプリケーションサーバー選択し、[サーバー・インフラストラク
チャー]→[プロセス定義]→[Java仮想マシン]の汎用JVM引数で定義
com.ibm.CORBA.requestTimeout
メソッドコール中のネットワーク障害、処理滞留によりタイムアウト
（org.omg.CORBA.NO_RESPONSE）とみなすまでの時間
デフォルト180秒
com.ibm.websphere.wlm.unusable.interval
ダウンとみなされたサーバーに対し、再度リクエストを割り振るまでの間隔
デフォルト300秒
99
６．データベース接続に関するチューニング
チューニングポイント
コネクションプール、PreparedStatementキャッシュサイズ
セッションデータベースの設定、書き込み頻度
Application
Application
ConnectionPool
Server
Server
セッションDBの設定、
書き込み頻度
DB
コネクションプールの
最大・最小接続数
Collection object
PreparedStatement
キャッシュサイズ
100
コネクションプールのチューニング
データソースの接続数の設定
JDBCプロバイダーとデータソースを選択し[接続プール・プロパティー]。一般プロパ
ティーの最大接続数、最小接続数で指定
通常時は最小接続数で対応し、ピーク時に最大接続数で対応するように設定
プール内のコネクションオブジェクトの使用率が100％の状態が続き、接続待ちや、
接続タイムアウトによるエラーとなったリクエストが多い場合は、コネクションプール
の最大接続数の増加を検討
接続タイムアウトの設定
接続要求が待機する時間。
タイムアウトになるとConnection
WaitTimeoutExceptionが返される
デフォルト180秒
101
PreparedStatementキャッシュサイズ
1コネクションあたりにPreparedStatementをキャッシュ
JDBCプロバイダーとデータソースを選択し、[WebSphere Application
Server データ・ソース・プロパティー]。一般プロパティーの「ステートメント・
キャッシュ・サイズ」で設定
PreparedStatementの破棄数が多いようであれば、増加を検討
デフォルトでは10ステートメント
ConnectionPool
DB
Collection object
SELECT A from Table where id = ?
SELECT B from Table where id = ?
INSERT into Table (A,B) value (?,?)
102
セッションデータベースの設定
セッションをデータベースに保管する際の設定
アプリケーションサーバーを選択し、[Webコンテナー設定]→[セッション管
理]→[分散環境設定]から、分散セッションにデータベースを選択
複数行スキーマの使用
デフォルトでは1セッションにつき、単一行にデータが書き込まれる
チェックをONにすると、複数行に分けてデータを書き込む
セッションデータが大きい場合に用いる（2MB以上は必須）
DB2行サイズ（DB2 UDB Only）
DB2はページ単位で読み込み、
書き込みを行う
デフォルトのページサイズは4kB
セッションオブジェクトサイズ≦
ページサイズとすることで
パフォーマンスの向上が見込める
DB2行サイズ
8kB
DB
Buffer
セッションオブジェクトの
サイズが8kBであれば、
ページサイズも4KBより8KBの
ほうがパフォーマンスは上がる
複数行スキーマの使用
Table
103
セッションオブジェクトの書き込み頻度
セッションオブジェクトが書き込まれる頻度の設定
アプリケーションサーバーを選択し、[Webコンテナー設定]→[セッション管理]→[分散
環境設定]から[カスタム・チューニング・パラメーター]
書き込み頻度（serviceメソッド終了、手動、時間基準）
書き込みの内容（更新された属性のみ、全てのセッション属性）
セッションクリーンアップのスケジュール（時間基準でセッションをクリーンアップ）
チューニングレベルを上げると、パフォーマンスは良くなるが、書き込み頻度が抑えら
れるため、可用性は下がる
デフォルトでは書き込み頻度10秒、内容は更新された属性のみ、セッションクリーン
アップはしない。
チューニングレベル（非常に高）
パフォーマンスの最適化
「カスタム」を選択すると、
書き込み頻度、書き込みの内容、
セッション・クリーンアップのスケジュールが
設定可能。
チューニングレベル（低）
フェイルオーバーの最適化
104
参考文献
105
参考文献
Information Center
WebSphere Application Server V6.0
pSeriesおよびAIX （AIX 5L™ バージョン 5.3 パフォーマンス・マネージメント・ガイド）
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp
http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/aixbman/prftungd/prftungd.
htm
WorkShop
WebSphere Application Server V6 Announcement Workshop（2004.12）
WebSphere Update ワークショップ 2004.06（2004.6）
WebSphere V5.1 問題判別の心得（2004.6）
WAS 5.1 インフラ構成の心得（2004.4）
WebSphere パフォーマンス・チューニングと問題判別（2003.9）
RedBook
WebSphere Application Server V6 Scalability and Performance Handbook
WebSphere Application Server V6 System Management and Configuration Handbook
106