GraalVMでのFlight Recorderを使ったパフォーマンス解析（JJUG CCC 2023 Spring）

©2023 NTT DATA Corporation
GraalVMでのFlight Recorderを使ったパフォーマンス解析
2023年6月4日
株式会社NTTデータテレコム・ユーティリティ事業本部
古賀和久

2
はじめに

3
自己紹介
 株式会社 NTTデータ所属
古賀和久
 好きなこと
 バーベキュー
 川遊び
 ソースコードを読むこと
 普段の仕事
 通信業界のシステム開発(C/C++メイン)
 ITアーキテクト

4
本日の内容

5
このセッション内容
Javaの
アプリケーション
JDK Mission Control
FlightRecord
ファイル
Native化した
アプリケーション
FlightRecord
ファイル
同じように解析できるのか？
JDK Mission Control

6
検証内容
# JDK公式ドキュメント検証ケース
1
ガベージ・コレクション
のパフォーマンス
2 同期(ロック競合)
3 IOパフォーマンス
4 コード実行パフォーマンス
実際の運用でよくあるだろうケースを想定
※検証目的に特化した単純なコードで実施（実サービスのものではありません）
無駄なオブジェクトで徐々にヒープを圧迫
GCが原因で性能劣化
マルチスレッド処理で排他制御がボトルネックになる
File/NWなど外部資源とのIOがボトルネックになる
アルゴリズムの選択ミスなどによって
特定のメソッドがボトルネックになる

7
■発表を聞いて得られること
- どこまで組み込みイベントで解析できるようになっているか
- 今はまだ何ができないか
■発表を聞いても得られないこと
- ユーザ独自のEventを実装してチューニングする方法
GraalVMの公式ドキュメントに
載っています

8
本セッションで話さないこと
• そもそもGraalVMとは
• GraalVMのNative化とは
• Native化の仕方
• FlightRecordの取得方法
→OCHaCafe6 #2 GraalVM 最新事情
わかりやすいです

9
検証環境
Windows11 x64
Core(TM) i5-11400H / RAM32GB
WSL2
Ubuntu 20.04.5 LTS
GraalVM CE
java11-22.3.0
検証用アプリケーション
(Java版)
ケースごとに実装
検証用アプリケーション
(Native版)
GraalVMの
native-imageコマンドで
変換

10
検証結果サマリ
1
無駄なオブジェクトで徐々にヒープサイズを圧迫
GCが原因で性能劣化
マルチスレッド処理で排他制御がボトルネックになる
File/NWなど外部資源とのIOボトルネックになる
アルゴリズムの選択ミスによって、
特定のメソッドがボトルネックになる

11
ケースごとの説明の流れ
• 検証アプリケーションの概要
• Javaでの実行例
• Native化したアプリでの結果
• 原因調査/代替手段など

12
検証(1/4) ガベージ・コレクションのパフォーマンス

13
ガベージ・コレクションのパフォーマンス(1/8)
検証アプリケーション
• 解放されないオブジェクトを徐々に増加
※ループ内で100Byteのオブジェクトをリストに追加
• GCのアルゴリズムは”Serial GC※”
※GraalVM CE版ではSerial GCしか使えないので条件を合わせるため

14
Javaでの実行結果

15
自動分析レポート(Javaの場合)
最長休止時間
アプリケーション実行時間に対する
休止時間の比率
GCで止まっている時間が
自動分析レポートで分析されている

16
ガベージコレクションページ（Javaの場合）
ヒープ使用状況の
グラフ
GCイベントごとの
詳細情報
停止時間の
グラフ

17
Native化したアプリでの結果

18
自動分析レポート(Native化したアプリケーションの場合）
アプリケーション実行時間
に対する休止時間の比率
最長休止時間
GCで止まっている時間が
Javaと同じように分析されました

19
ガベージコレクションページ(Native化したアプリケーションの場合）
ヒープの使用状況の
グラフは確認できない
GCイベントの情報
停止時間のグラフ
停止時間のグラフは
同様に見れる

20
なぜグラフが出ないのか？

21
Q. そもそも何をもとに
グラフは出ているのか

22
A. 「jdk.GCHeapSummary」

23
jdk.GCHeapSummary {
startTime = 22:03:30.764
gcId = 11
when = "Before GC"
heapSpace = {
start = 0xE7000000
committedEnd = 0xFF2B0000
committedSize = 386.7 MB
reservedEnd = 0x100000000
reservedSize = 400.0 MB
}
heapUsed = 294.2 MB
}
jdk.GCHeapSummary {
startTime = 22:03:30.776
gcId = 11
when = "After GC"
heapSpace = {
start = 0xE7000000
committedEnd = 0xFF2B0000
committedSize = 386.7 MB
reservedEnd = 0x100000000
reservedSize = 400.0 MB
}
heapUsed = 65.5 MB
}
Javaのヒープグラフ
実際のグラフとの対応です

24
Native化したアプリケーションでヒープのグラフが出ない原因
jfr コマンドで確認したイベントの集計結果
該当イベントが出力されていない。
https://github.com/oracle/graal/issues/5410
GraalVMのイベント対応状況のIssue抜粋
そもそも実装されていない

25
代替手段は？
GC Logで代替可能

26
GC Logのサンプル
[
[36555093917095 GC: before epoch: 7 cause: CollectOnAllocation]
[Full GC (CollectOnAllocation) 222900K->20067K, 0.0056789 secs]
[36555099612242 GC: after epoch: 7 cause: CollectOnAllocation policy: adaptive type: complete collection time: 5678909 nanoSeconds]
]
[
[36555359491355 GC: before epoch: 8 cause: CollectOnAllocation]
[Incremental GC (CollectOnAllocation) 123681K->122657K, 0.0002136 secs]
[36555359717573 GC: after epoch: 8 cause: CollectOnAllocation policy: adaptive type: incremental collection time: 213647 nanoSeconds]
]
GCのタイプ（実施理由） GC前のヒープ、GC後のヒープ、休止時間

27
考察
# ページ差異運用
1
レポート
ページ
チューニング要否はJMCを利用できる。
(休止時間については分析されるため）
2
ガベージコ
レクション
のページ
ヒープサイズの使用状況の分析は
当面はGCログで分析する必要あり。
ヒープグラフが出ない
チューニング要否の判断（休止時間の分析）はJMCでもできる。

28
検証(2/4) ロックに関する分析

29
ロックに関する分析(1/8)
■検証アプリケーション
• マルチスレッド(3つ)
• Counter(共有オブジェクト)を排他取得
• ロック時間は長め
■期待
競合状況や競合原因などを見られること

30

31
自動分析レポート(Javaの場合)
ブロッキングの発生状況が分析結果として出てきています

32
スレッドの情報(Javaの場合)
凡例
アクティブ
非アクティブ
ロック開放待ちで順次スレッドが実行されている
※下図は説明用に該当する子スレッド以外はグレーアウト表示に加工しています

33
ロックインスタンスの詳細ビュー（Javaの場合）
競合原因やスレッドごとのブロック時間を見ることができる
競合が発生した原因
スレッドごとのブロック時間

34

35
自動分析の結果(Nativeでの場合)
Javaと同様にブロッキング発生をレポートされる

36
スレッドのページ(Native化したアプリでの実行例)
凡例
アクティブ
非アクティブ
Javaと同様にスレッドの競合状況をグラフで確認できる
※下図は説明用に該当する子スレッド以外はグレーアウト表示に加工している

37
ロックインスタンスのページ(Native化したアプリケーションでの例)
Javaと同様に競合原因やブロック時間を見ることができる
競合が発生した原因
スレッドごとのブロック時間

38
ロックに関する分析のまとめ

39
考察
# ページ差異結果
1
レポート
ページ
レポートでチェックポイントとして報告される
2
スレッドの
詳細分析
ビュー
スレッド情報を可視化して確認できる
3
ロックイン
スタンスの
詳細ビュー
原因となったクラスの情報
スレッドごとのブロック時間の集計結果
を見ることできた
Javaと同様のレベルで解析可能

40
検証(3/4) IOパフォーマンス

41
IOパフォーマンス
調査結果
• GraalVMの22.03ではイベント※出力未実装
jdk.FileRead、jdk.FileWrite、jdk.SocketRead、jdk.SocketWrite
• PullRequestが出ていたがマージされていない。
https://github.com/oracle/graal/pull/5497

42
検証(4/4) コード実行パフォーマンス

43
コード実行パフォーマンス(1/10)
■検証アプリケーション
bubble_sort メソッドが処理時間の大半を占めるように実行
■期待
bubble_sort メソッドが改善対象としてレポートされること

44

45
自動分析の結果(Javaの場合)
bubble_sort が実行時間の大半を占めることがレポートされた

46
メソッド・プロファイリング(Javaの場合)
対象メソッドやスタックトレースの情報を確認できる

47

48
自動分析の結果(Nativeの場合)
Nativeの場合はbubble_sort が改善対象として出てこなかった

49
メソッド・プロファイリング(Nativeでの例)
Nativeの実行例では何の情報も出ていない

50
出力されない原因を調べてみた

51
Javaでの実行例から､何のイベントを元にしているかを調べてみた
jdk.ExecutionSampleが出力されていないから
$jfr print --events jdk.ExecutionSample app-startup.jfr で見た例
jdk.ExecutionSample {
startTime = 22:17:35.853
sampledThread = "main" (javaThreadId = 1)
state = "STATE_RUNNABLE"
stackTrace = [
com.example.App.bubble_sort(int[]) line: 14
com.example.App.main(String[]) line: 50
]
}
■Javaでの実行例

52
Nativeでメソッドプロファイリングに引っかからない原因
3つ目のケースと違ってイベント出力は実装されていた
jfr コマンドで確認したイベントの集計結果(抜粋)
$ jfr summary native-start.jfr
Version: 2.0
Chunks: 1
Start: 2023-02-16 13:18:33 (UTC)
Duration: 126 s
Event Type CountSize (bytes)
========================================
jdk.JavaMonitorWait 6407171229
：
jdk.ExecutionSample 0 0
jdk.NativeMethodSample 0 0
：
該当イベントが出力されていない。
実際に、関連するPull-Requestはmergeされていことも確認済み
※https://github.com/oracle/graal/issues/5410
GraalVMのイベント対応状況のIssue※抜粋
実装済みにはなっている

53
追加検証
23年３月のGraalVMのmasterで実施
※JDKは17になっています

54
自動分析の結果（追加検証）
レポートは出るがメソッド名が異なる
期待 bubble_sort
結果 invokeCallback

55
メソッド・プロファイリング(追加検証)
レポートに表示されたメソッド名と同様に期待値と異なる
invokeCallback

56
考察
何かしらの不具合があるようだが、
現時点では不明
JavaでチューニングしてからNative化

57
まとめ

58
検証結果サマリ -再掲-
対応状況はケースによってまちまちだった
1
無駄なオブジェクトで徐々にヒープサイズを圧迫
マルチスレッドで実行していて、
排他制御箇所がボトルネックになっている
File/NWなど外部資源とのIOボトルネックで
性能が出ない
アルゴリズムの選択ミスによって、
特定のメソッドがボトルネックになっている

59
まちまち悪いこと

60
イベント出力対象が増えれば
Javaの解析手法を活用できる

61
拡充に期待！！

62
JJUG発表後追加スライド

63
jdk.GCHeapSummaryの出力機能の拡張について
こんな感じで見れるようになります！
(Serial GC限定です)
提出したPull-Requestが採用されました！

64
参考資料

65
参考資料
# タイトル記載者概要 URL
1 OpenJDK での JDK Flight Recorder の使用 Redhat（公式） Flight RecorderやJMCの使い方の概要など
https://access.redhat.com/documentation/
ja-jp/openjdk/11/html/using_jdk_flight_rec
order_with_openjdk/index
2 JFR Events SAP（公式） JDKバージョンごとの取得可能なイベントの一覧（サンプル付き)
https://sap.github.io/SapMachine/jfre
vents/
3 JDK Flight Recorder Javaコミュニティ
Flight Recorder関連のアーキテクチャや、トラブルシュートの例な
ど
https://foojay.io/today/category/tools
/jdk-flight-recorder/
4 OpenJDK（GitHub） OpenJDK(公式) JDKのソースコード https://github.com/openjdk/jdk
5
GraalVM(ドキュメント) Oracle(公式)
GraalVMの公式サイト https://www.graalvm.org/
6
Flight Recorderを有効にしてビルドする方法などが記載されてい
ます
https://www.graalvm.org/latest/refer
ence-manual/native-image/debugging
-and-diagnostics/JFR/
7 ユーザ独自のイベントを発行して記録する方法
https://www.graalvm.org/latest/refer
ence-manual/native-image/guides/bui
ld-and-run-native-executable-with-jfr/
8
GraalVM（GitHub） Oracle(公式)
トップページ https://github.com/oracle/graal/
9 JFRに関するディスカッション
https://github.com/oracle/graal/discussion
s?discussions_q=jfr
10 Native-Imageの変更履歴
https://github.com/oracle/graal/blob/
master/substratevm/CHANGELOG.md
11 Flight RecorderのEvent対応状況
https://github.com/oracle/graal/issue
s/5410
12 GraalVM 最新事情
Oracle Cloud
Hang out Cafe
GraalVMとは？やNativeimgeコマンドとは？といった概要を知り
たい場合はこちらから読まれるとわかりやすいと思います。
https://ochacafe.connpass.com/event
/259128/presentation/

66
本資料に記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。

GraalVMでのFlight Recorderを使ったパフォーマンス解析（JJUG CCC 2023 Spring）

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a GraalVMでのFlight Recorderを使ったパフォーマンス解析（JJUG CCC 2023 Spring）

Semelhante a GraalVMでのFlight Recorderを使ったパフォーマンス解析（JJUG CCC 2023 Spring） (20)

Mais de NTT DATA Technology & Innovation

Mais de NTT DATA Technology & Innovation (20)

Último

Último (7)

GraalVMでのFlight Recorderを使ったパフォーマンス解析（JJUG CCC 2023 Spring）