狠狠撸

２０１６年５月２４日
富士通株式会社
数村憲治
[1-E]
Versatile Java チューニング
- 多様な环境での性能考察
Copyright 2016 FUJITSU LIMITED0
Java Day Tokyo 201６

アジェンダ
Copyright 2016 FUJITSU LIMITED
多様な並列?並行環境
SPECjbbベンチマークから学ぶチューニング
クラウド環境でのJavaチューニング
ＧＣ概論
1

アジェンダ
ＧＣ概論
2

CPUレベル
メニーコア
VMレベル
サーバーグリッド
DCレベル
インタークラウド
コアコアコア
コアコア
???
VM VMVM
VMVM
???
DC DCDC
DCDC
???
コアを使い切る
並列?並行プログラミング
クラウド
マイクロサービス
オートスケール
対災
為替変動
昼夜?季節変動
3

アジェンダ
ＧＣ概論
4

メモリ解放処理時間
アプリ処理
メモリ解放処理C/C++
Java
実行時間分布
メモリ解放処理にかかるトータル時間は変わらなそう
マルチコア環境では総ポーズ時間に加えスループットも問題
C/C++
Java シリアルGC
5

マルチコア環境で２系統のＧＣ
アプリ処理
メモリ解放処理C/C++
Java
マルチコアでGCを集中処理
GC専用コアでバックグランド処理
Java
パラレルGC
コンカレントGC/G1GC
6

GC比較
Serial Parallel
(デフォルト)
Concurrent G1
アプリ停止時間
(NEW世代)
長い短い短い
(NewGCの設
定次第)
短い
アプリ停止時間
(OLD世代)
長い短いかなり短いかなり短い
GC実行時間
(アプリ処理への
影響)
長い短い長い長い
7

Versatil Javaチューニング

GC時間の要因
Q: ヒープサイズを大きくすると、
ＧＣ時間が長くなるか？
9

GC時間の要因
Q: ヒープサイズを大きくすると、
ＧＣ時間が長くなるか？
GC時間に与える影響
ヒープサイズ小
参照関係の複雑度大
残存オブジェクトの量大
A: アプリ次第
11

アジェンダ
ＧＣ概論
12

SPECベンチマーク
Java EE ベンチマーク
Java SE ベンチマーク
SPECjvm2008
SPECjbb2000 SPECjbb2005
SPECjbb2013 SPECjbb2015
SPECjEnterprise2010
SPEC JVM98
SPECjAppServer2001 SPECjAppServer2002
SPECjAppServer2004
13

jbb2005レポート
卸売り業者向け注文処理
スループット評価
「ピーク」～「ピーク」×２の平均
14

32bit or 64bit
Q: 64bit JVMの方が32bit JVMより速い？
A: アプリ次第
32bit JVM 64bit JVM 64bit JVM
(OOP圧縮)
ヒープサイズ小さい
(~4GB)
大きいやや小さい
(~32GB)
命令数ほぼ同じ
primitive型長同じ(言語仕様)
ポインタ長
(Java参照)
4バイト 8バイト 4バイト
15

GC - SPECjbb2005
[GC 1792923K->220155K(3506176K), 0.0316045 secs]
[GC 1793019K->220123K(3506176K), 0.0315059 secs]
[GC 1792987K->220059K(3506176K), 0.0321024 secs]
[GC 1792923K->220043K(3506176K), 0.0329549 secs]
[GC 1792907K->219931K(3506176K), 0.0320998 secs]
[GC 1792795K->220043K(3506176K), 0.0311437 secs]
[GC 1792907K->220123K(3506176K), 0.0313754 secs]
[GC 1792987K->219995K(3506176K), 0.0311706 secs]
[GC 1792859K->219963K(3506176K), 0.0312448 secs]
[GC 1792827K->220011K(3506176K), 0.0314368 secs]
[GC 1792875K->220011K(3506176K), 0.0330202 secs]
[GC 1792875K->220027K(3506176K), 0.0313459 secs]
[GC 1792891K->220091K(3506176K), 0.0330893 secs]
Full GCなし (New GCで刈り取り)
滞留オブジェクト少ない
Newサイズを大きくする
64bit JVMに
しても効果なし
16

PA
CPUの性能統計情報
Solarisではcpustatやcputrack、Linuxではperfなど
load命令の実行回数とか分岐ミスの回数など
採取ツール
CPU使用率の高い時の分析に有効
Solaris Studio
JIT翻訳コードとjavaメソッドの対応
Excl. Excl. Excl. Excl. Excl. 0endop Excl. Excl. Name
User CPU cse_window_empty eu_comp_wait branch_comp_wait Events cycle_counts op_stv_wait
sec. Events Events Events Events Events
19447.683 2446788972169 831739465388 1151213425115 25369085369433 30327263342999 17754591600950 <Total>
6363.191 246092332593 19279985397 213890691078 9355996722211 9934059335873 8472978908934 spec.jbb.DeliveryTransaction.preprocess
1546.146 124011089605 15999988117 138560945006 2094182003395 2414382727385 1643119207870 spec.jbb.CustomerReportTransaction.pr
915.627 77330713189 24389985602 27780111008 1341280331407 1476400759646 1115608730888 spec.jbb.Order.processLines(spec.jbb.W
792.724 70700650561 14579989105 32330093755 1130840057024 1252120374688 933448798162 spec.jbb.Orderline.process(spec.jbb.Item
673.720 140651119062 49029963171 93500191456 659391413457 1044861662829 143719969069 com.sun.org.apache.xerces.internal.dom.
614.218 72760691278 20349983928 63590169932 740703049687 925783290757 460241947420 spec.jbb.infra.Util.TransactionLogBuffer
609.818 98000889315 12749990185 81580106051 607821402665 945031625893 227210234572 spec.jbb.infra.Util.XMLTransactionLog.p
557.217 67780653234 6409995062 64420209949 625512396476 875332630833 347721323893 spec.jbb.infra.Util.XMLTransactionLog.c
17

jbb2005 PA

HashMap
Table
Entry
java.lang.Long
value
next
key
index
value
next
key
value
java.util.HashMap<Long, Object>
Entry
prefetchの使いにくい構造
19

NUMA
CPU
メモリ
バス
ローカルメモリへ
のアクセスは速い
他ノードメモリへ
のアクセスは遅い
CPU
メモリ
CPU
メモリ
プロセスとCPUのバインド
Solaris: psrset
Linux: numactl
Windows: affinity
20

バインド
プロセスバインド
コア
L1$
プロセス
L2$
コア
L1$
メモリ
CPU
バインド
コア
L1$
プロセス
L2$
コア
L1$
メモリ
CPU
プロセス
バインド
21

SPECjbb2015(2013)
指標が２つ
max-jOPS
スループット性能
https://www.spec.org/jbb2015/
crtical-jOPS
レスポンス性能
スーパーマーケットをモデル化
jbb2013はバグあり
jbb2015に置き換え
22

jbb2015 レポート

jbb2015(rt-curve)

jOPS
10ms/25ms/50ms/75ms/100ms SLAの幾何平均
投入したIR(=Injection Rate)が
バックエンドでクリアできた最大値
max-jOPS
critical-jOPS
25

ボトルネック分析
Excl. Excl. Excl. Excl. Excl. 0endop Excl. Name
cycle_counts op_stv_wait_sxmiss op_stv_wait cse_window_empty Events branch_comp_wait
Events Events Events Events Events
1101786180658 215898420218 562551014714 129773898641 905313151956 44741113230 <Total>
47513336612 25831710869 38658728456 1193164498 43462211662 959013031 org.spec.jbb.core.collections.AbstractMultiSet.add(
37773292448 10397498263 20721554808 2549326410 29871102339 1392063840 java.util.HashMap.put(java.lang.Object, java.lang.O
35066582270 16407274641 31636245962 560060456 33868474709 469015625 org.spec.jbb.sm.tx.AbstractSMTransaction.resolveP
30841304203 12274706439 24482893293 707079428 27895179232 511009954 org.spec.jbb.sm.inventory.LockedRandomBarcodeI
24040938576 11253588585 17231602545 836148036 20426863809 724023547 org.spec.jbb.hq.tx.SupermarketAudit.summarizeRe
23376769859 108015020 10810362793 2522152071 18709671302 1384020024 JVM_LatestUserDefinedLoader
23370793423 10967519584 16106448871 1057101107 20471687331 629033539 java.util.TimSort.sort(java.lang.Object[], int, int, java
23318294403 14002962323 19129937512 804114371 21574201477 500028295 java.util.AbstractCollection.toArray()
21468518561 8878253023 16511222511 682082486 18891388302 26003819 org.spec.jbb.sm.advertisement.Advertisements.get
20344601419 10585512003 16335417309 343033874 18676540575 469003763 org.spec.jbb.hq.db.Storage.adjustSupermarketInve
17430644924 294041499 7053270328 4100173753 14886578432 935021061 java.io.ObjectInputStream.readClassDesc()
17082604077 10886514241 14985374817 424075597 16064517988 128002283 org.spec.jbb.core.collections.CollectionUtils.map()
16613622038 9256435708 432006507 13272524637 454002229 408001825 ParNewGeneration::copy_to_survivor_space_avoidin
顕著にコストの高いメソッドはなし
一番コストの高いメソッドでも全体の4%程度
26

jbb2015 PA

CMS戦略
CMS: Concurrent Mark & Sweep
OLD領域が対象
NEW領域はコピーイングGC
戦略１(CMS重視)
戦略２(NewGC重視)
NewGCで生存オブジェクトは即OLD領域へ
積極的にCMSを発動しOLD領域を回収
できるだけNewGCで回収
CMSの発動は最小限に
目的はFullGCを発生させないこと
28

jbb2013でのCMS選択
戦略１(CMS重視)
ただし、ヒープサイズを小さくする必要あり
(大きくすると、OLD領域に溜まる速度が速くなる)
ヒープサイズが小さいなら、64bit JVMの選択価値なし
NewGC停止時間がかなり短く、
SLA10-100msに適している
29

GC選択 - CMS
[GC [ParNew: 204416K->0K(204608K), 0.1215322 secs] 2467796K->2286847K(3379008K),
0.1217741 secs] [Times: user=0.64 sys=0.01, real=0.12 secs]
[GC [1 CMS-initial-mark: 2286847K(3174400K)] 2286858K(3379008K), 0.0030925 secs]
[Times: user=0.01 sys=0.00,real=0.00 secs]
...
[CMS-concurrent-sweep: 7.847/10.021 secs] [Times: user=48.04 sys=0.90, real=10.02 secs]
[CMS-concurrent-reset: 0.010/0.010 secs] [Times: user=0.04 sys=0.00, real=0.01 secs]
-Xmx3300m –Xmn200m
CMS自体は機能している
IRが増えるにつれてNewGCの回数が増加(50秒で100回)
max-jOPSが出ない
30

GC選択 - Parallel
[GC [PSYoungGen: 71695069K->871243K(82575360K)] 72866327K->2043228K(93061120K
0.2142886 secs] [Times: user=6.67 sys=0.00b, real=0.21 secs]
-Xmx100g –Xmn90g
IR=20738でのGC発生ログ
31

富豪チューニング
[GC [PSYoungGen: 299734259K->926754K(348651520K)] 300756630K->1951997K(3696230
[GC [PSYoungGen: 299770914K->936145K(348651520K)] 300796157K->1964044K(3696230
-Xmx400g –Xmn360g
IR=21215でのGC発生ログ
ヒープ
サイズ
max-
jOPS
critical-
jOPS
GC回数
(IR=21000付近)
GC時間
(１回あたり)
100GB 41000 16590 6 210ms
400GB 42431 22573 2 220ms
32

Parallel v.s. G1
Parallel G1
SLA
[ms]
10 50 100 200 500 幾何
平均
jOPS 2940 2940 3976 6636 11943 4864
SLA
[ms]
10 50 100 200 500 幾何
平均
jOPS 1176 1568 2145 5719 10278 2974
GC有無に関係なく、G1ではライトバリアがレスポンスに影響
33

GCパラメタ設定
パラメタがたくさんあり、何をどう設定すればいいのか分からない
GCの仕組みを
とことん理解する
GCログから内部で
何が起きているか理解する
GCパラメタを設定
アプリ修正?環境?負荷変更
でやりなおし
GCの自動設定にお任せ
アプリ修正?環境?負荷変更
でも、自動的に再設定
34

GC選択まとめ
スループット重視かレスポンス重視か
レスポンス重視の場合はSLAを決める
SLAはレスポンス時間と許容範囲
１００％死守か、８０％クリアできればよいのか
レスポンス == G1 or CMS という先入観を捨てる
G1はデフォルト設定で効果なければあきらめる
35

アジェンダ
ＧＣ概論
36

クラウドとは
docker 仮想化
IaaS サービス
PaaSパブリック
ハイブリッド
AWSAzure
IoT
SoE
CloudFoundryCloudFoundry
本日はここ
37

Cloud Foundry
etc...
Node.js用
Java用
etc...
リレーショナル
データベース
配備バインド
アプリケーション
開発者
サービスビルドパック
エンドユーザ
CF
公開
クラウドネイティブアプリの実行基盤(PaaS)
ビルドパック(各種言語のフレームワーク)を提供
サービスとの組み合わせで短期に柔軟なシステム構築
38

クラウドネイティブアプリ
The Twelve-Factor App
VIII. Concurrency
http://12factor.net
プロセスが第一級市民
プロセスでスケールさせる
39

アーキテクチャ
Cloud Foundry
Router Cloud
Controller(CC)
DEA Health
Manager
NATS
開発者
DEA
の配備
配備を指示
へのアクセス
エンドユーザアプリケーション
への死活監視
40

オンプレからの移行
向き不向きを理解する
ローカルファイルは使えない(揮発性)
スケールアップではなく、スケールアウト型へ
アクセスログ等の扱いに注意が必要(後から見れない)
モノリシックからマイクロサービスへ
IOPSが要求されるバッチは向かない
サイズも注意(すぐにパンクする)
41

テスト
ビルド
単体テスト
結合テスト
システムテスト
ローカル
Cloud
Foundry
ローカル
Cloud
Foundry
ローカル
Cloud
Foundry
運用テスト
ローカル
Cloud
Foundry
42

リモートデバッグ - 対象の特定
ルーター
デバッグ対象
？
？
？
特定のコンテナを指定してアクセスできない
デバッグ時は１インスタンスだけ立ち上げる
43

リモートデバッグ – ファイアウォール
ファイア
ウォール
http/https以外のポートをアクセスできない
Cloud Foundry
開発者側のポートをあける
ポート
80/443
デバッグ
ポート
44

リモートデバッグ – ファイアウォール
ファイア
ウォール
開発者環境にファイアウォールがあるとダメ
Cloud Foundry
ファイア
ウォール
開発者環境
-agentlib:jdwp=transport=dt_socket,address={IP}:{PORT}
javaオプションに以下を指定
デバッグ
ポート
デバッガ
ポート
45

リモートデバッグ – JDWP on http
ファイア
ウォール
デバッガはエージェントにデバッグ命令をhttpで指示
エージェントは、通常のJPDAでデバッグ
Cloud Foundry
ファイア
ウォール
開発者環境
デバッグ対象
エージェント
デバッグ
ポートJDWP
on
http/https
46

JavaVM と DEA(コンテナVM)
JavaVMの細かなチューニングはしない
クラウドネイティブアプリは変更が頻繁
変更するたびにチューニングしていられない
性能がでなければ、DEAでスケールアウト
スケールアウトすれば性能が出るようにしておく
ハード?ＯＳを意識したチューニングはできない
ステートレス、マイクロサービス
47

メモリチューニング
manifest.ymlに指定する「memory」属性
DEA(OS)に対するメモリ割り当て量
(ビルドパックによっては)
Javaヒープはこの範囲内で自動的に割り当て
(ビルドパックによっては)
Javaヒープは任意の値に設定できる
すべて、Javaヒープとして使えるわけではない
48

メモリ割り当て
Java Buildpack/Fujitsu Java Buildpack
-Xms/-Xmx/-Xss/-XX:MetaspaceSize/-XX:MaxMetaSpaceSize
ただし、「memory」属性値との整合性は、利用者責任
Javaヒープ 75% -Xmx/-Xms
メタスペース 10% -XX:MaxMetaspaceSize/–XX:MetaspaceSize
その他 15%
Fujitsu Java Builpackでは以下のオプションを
環境変数JAVA_OPTSに指定可能
49

スケールアウト時の注意
スケールアウト
RDSDEA
(Java)
RDS
キャパシティオーバー
DEA
(Java)
フロントのスケールアウト時は、バックエンドのキャパシティに注意
最大、Javaのコネクションプール数 x スケールアウト数
50

ブルーグリーンディプロイ
RDS
DEA
(Java)
ブルー
DEA
(Java)
ブルー＋グリーン分のバックエンドのキャパシティが必要
グリーン
51

まとめ
並行?並列環境に応じたチューニングが必要
クラウドではこれまでのチューニングが使えない
オンプレでは、ハード?ＯＳを意識
クラウドでは、コンテナ?連携サービスを意識
52

Q&A

Javaは、Oracle Corporationおよびその子会社、関連会社の米国および
その他の国おける登録商標です。
本ドキュメントに記載されている、社名、商品名等は各社の商標または
登録商標である場合があります。
その他の記載されている、商標および登録商標については、
一般に各社の商標または登録商標です。
54

狠狠撸

Versatil Javaチューニング

More Related Content

Versatil Javaチューニング