コンテナ環境でのJavaトラブルシューティング

by Kenji Kazumura

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

9 コンテナ起動時間 https://niravshah2705.medium.com/kubernetes-image-pull-optimisation-part-i-exploring-options-f79d79c3fe45 大半は、イメージのpull pullは、fetchと uncompressに分解できるイメージサイズが大きくなるほど、 uncompressに時間がかかる © 2023 Fujitsu Limited

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

gcr.io/distrolessで公開 ⚫ Java版もあり: `gcr.io/distroless/java17-debian12` など Microsoft 版もあり ⚫ mcr.microsoft.com/openjdk/jdk:17-distroless トラブルシューティングに使えそうなものは、ほぼ入っていない ⚫ ls や ps もなし 14 distroless © 2023 Fujitsu Limited OS標準機能に関する調査はできない

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

iノードで管理 8個のnamespaceでプロセスを分離 ⚫ cgroup/net/ipc/uts/user/pid/time/mnt ⚫ それぞれを共有する・しないことで、コンテナの柔軟な独立性を実現 namespace 関連コマンド例 ⚫ lsns ⚫ nsenter ⚫ ・・・ `docker exec` コマンドは、namespaceの変更 ⚫ `nsenter --target ${PID} --all` と同等 22 Linux の namespace © 2023 Fujitsu Limited

Slide 23

Slide 23 text

Slide 24

Slide 24 text

24 ノードからコンテナにアクセス © 2023 Fujitsu Limited コンテナ内のプロセスは、ホスト・ノードのプロセスとしても見える。ただし、PIDは違うどのプロセスがどのコンテナのものかは一見では分からないホスト・ノードにアクセス可能なら、この方法でもよいが。。。コンテナ視点 (ネットワーク設定など)でのトラシューは難しいかもホスト・ノードコンテナ JDK jstackなど Java アプリ

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

29 サイドカー © 2023 Fujitsu Limited Pod内にトラシュー用のイメージをサイドカーとして実行しておく ⚫ pod定義で、以下を指定 spec.shareProcessNamespace:true アプリのコンテナイメージにトラシューツールが入れる必要はなくなるが、トラブルがなくても常に起動されるのでリソースの無駄 ⚫ 開発時など、最初からトラブルが発生することが分かっていれば有用

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

32 コピー © 2023 Fujitsu Limited トラブル時に、アプリコンテナをコピーして、デバッガ用コンテナを追加サイドカーより、リソースを節約できるが・・・ライブマイグレーションするわけではない kubectl debug -it debuggee-pod ＼ --copy-to debugger-pod ＼ –share-processes debuggee-pod ＼ --image JDK-image -- bash

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

35 エフェメラルコンテナ © 2023 Fujitsu Limited トラシュー対象コンテナと、namespaceが共通なコンテナを既存Podに追加 dockerの場合 Kubernetesの場合 docker run ＼ -it --name=debugger --pid=container:jre ＼ jdk-image bash kubectl debug -it -c debugger --target debuggee ＼ --image=jdk-image debuggee -- bash

Slide 36

Slide 36 text

36 トラブルシューティング方法比較 © 2023 Fujitsu Limited 長所短所ノードからコンテナにアクセス N/A ホスト権限が必要コンテナ視点の欠如 docker exec 手軽トラシューツールが使えない場合ありサイドカートラシューツール用コンテナとアプリ用コンテナが分離リソースの無駄コピートラブル時にのみコピー可能トラブルコンテナそのものを対象にできないエフェメラルコンテナトラブルコンテナにトラブル時にのみ、アクセス可能一度作ったエフェメラルコンテナを削除できない

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

39 OpenJDKのperf対応 © 2023 Fujitsu Limited JDK-8080650: Enable stubs to use frame pointers correctly JDK-8254723: Add diagnostic command to write Linux perf map file JDK-8316286: Add diagnostic command to write Linux perf jit dump file JDK-8314029: Add file name parameter to Compiler.perfmap JDK-8314027: Add code heap list parameter to Compiler.perfmap Fix:9 HotSpot VMのhsperfdata(UsePefData)とは関係ない Fix:16 open open open

Slide 40

Slide 40 text

40 perf使用手順 © 2023 Fujitsu Limited perfとJDKの入ったイメージを作成するオプションでFrameGraphを入れてもよい https://github.com/brendangregg/FlameGraph 1 対象Javaアプリケーションは、 “-XX:+PreserveFramePointer”を指定しPodを起動しておく 2 Step1で作成したイメージを、Step2のPodに、エフェメラルコンテナ化し追加する 3 perfコマンドで、性能情報を収集する 4 jcmdで、perf.mapを作成する 5 perfコマンドで、データ解析・表示する 6

Slide 41

Slide 41 text

JVMのワークロードベンチマーク手軽に起動可能複数のテストスイート 41 ルネサンスベンチマーク © 2023 Fujitsu Limited ⚫ https://renaissance.dev/ ⚫ https://github.com/renaissance-benchmarks/renaissance/ $ java -jar 'renaissance-gpl-0.15.0.jar' ⚫ apache-spark / concurrency / database / functional /scala / web