JJavaプログラム実行の仕組みと、高速・安定動作に向けた取り組み

© Hitachi, Ltd. 2013. All rights reserved.
株式会社日立製作所情報・通信システム社
ITプラットフォーム事業本部開発統括本部
小幡元樹
2013年5月11日（土）
JJUG Cross Community Conference 2013 Spring
Javaプログラム実行の仕組みと、
高速・安定動作に向けた取り組み

他社所有名称に対する表示
 AIXおよびPOWERは，米国およびその他の国における
International Business Machines Corporationの商標です。
 Androidは，Google Inc. の登録商標です。
 ARMは，ARM Ltd.の登録商標です。
 HP-UXは，Hewlett-Packard Development Company, L.P.の
オペレーティングシステムの名称です。
 Intelは，アメリカ合衆国およびその他の国におけるIntel Corporationの商標です。
 Linuxは，Linus Torvalds氏の日本およびその他の国における登録商標または
商標です。
 Windowsは，米国Microsoft Corporationの米国およびその他の国における
登録商標または商標です。
 OracleとJavaは，Oracle Corporation 及びその子会社，関連会社の米国及び
その他の国における登録商標です。
 その他記載されている会社名、製品名などは該当する
各社の商標または登録商標です。
他社所有名称

Contents
1. Java＋日立
2. Javaプログラム実行の仕組み
3. Cosminexus V9の紹介
4. Javaシステム安定動作にむけた取り組み
5. まとめ
2

Contents
1. Java＋日立
5. まとめ
3

1-1. Javaの広まり
4
 Javaは1990年代後半から普及し始め、
2000年代にはC言語に並ぶメジャーな言語になりました
 ポータビリティ … Write Once, Run Anywhere
 スケーラビリティ … （それなりに）高性能
 プログラミング容易 … GC搭載でメモリを気にしないプログラミング
Java
Linux(R) Windows(R) AIX HP-UX
Intel/x86 PowerIntel/IPF ARM
Android
産業
公共金融組み込み
住民基本台帳カード

1-2. エンタープラ゗ズシステムの変遷 1/2
5
 「エンタープライズシステム」＝企業で使用される業務システム全般
 企業内で必要とされる要件をより高いレベルで実現するため、
登場以来、進化し続けてきました
1970年代 1980年代 1990年代 2000年代 2010年～
メインフレーム
クライアント
サーバ
Webシステム
ITシステムに掛かる
コスト削減
業務効率の
劇的な改善
メインフレームダム端末
全ての処理を
実行
表示のみ
サーバー
プログラム
ロジックを実行
クライアントPC
情報共有のスピードアップ、
新規ビジネス開拓の容易化

1990年代 2000年代 2010年～
クライアント
サーバ
Webシステム
1-2. エンタープラ゗ズシステムの変遷 2/2
6
サーバークライアントPC
従来のエンタープライズシステムこれからのエンタープライズシステム
クラウド型システム
高速大量
データ処理
従来業務の
クラウド化
システムのクラウド化の促進
C/S の IaaS による単純なシステム置き換えから PaaS/SaaS の
積極利用ポイント
ハードウェア発展に伴う利用可能リソースの増大
大量のデータ(＝ビッグデータ)を高速に処理可能へ

1-3. エンタープラ゗ズシステムでの必要要件
7
利用技術が変わっても、本質的な要件は不変
エンタープラ゗ズシステムに求められる性質 :
 サービス提供を停止させない可用性
 処理を確実に実行する信頼性
 利用者やデータ量の増加に対応できるスケーラビリティ
 企業の経営改善に結びつくコストメリット
 日立製作所では、Cosminexusをはじめとする
ミドルウェゕ群の提供を通じて、高速・安定な
エンタープラ゗ズゕプリケーション実行環境を
提供してきました。

OS
ハードウェゕ
Javaゕプリケーション
ハ゗パーバ゗ザー
8
 日立での取り組みのうち、以下の内容をご紹介致します
 Java仮想マシンでのJavaプログラム実行
 Full GCレス機能、稼動情報取得による対応力強化
クラスラ゗ブラリ
(JavaEE/JavaSE)
Javaアプリケーション開発保守支援への取組み
性能向上に役立つJava VM内の仕組み
アプリケーション実行状況の可視化
ゕプリケーション開発の標準化
構築ノウハウの活用
…
Javaプログラム実行の様子
■ JITコンパイルによる高速化
■ 最適化状況の確認と落とし穴
ガベージコレクション
■ Full GCレス機能
動
作
状
況
の
可
視
化
機
構
本発表で
ご紹介
Java仮想マシン
(Java VM)
ゕプリケーション
実行基盤
本発表で
ご紹介
1-4. 本日の発表内容

Contents
1. Java＋日立
5. まとめ
9

 Javaプログラムは書きやすい、使いやすい
 どんなマシンでも（それなりに）高い性能
 Just-In-Time(JIT)コンパ゗ラのおかげ
 メモリを意識しないプログラミングスタ゗ル
 ガベージコレクション(GC)のおかげ
2-1. Java VMとJavaプログラムの関係
10
プログラムとJVM内挙動を
意識すると解決できること
が多い
動いているがなぜか遅い、
メモリをたくさん使う…
といった事例が多数
bytecode JIT compiler native code
JITによって
実行PF最適化
GCで不要な
データを削除

インタプリタ
 Javaプログラムの実行にはJava仮想マシンを使う
 最初は゗ンタプリタで実行
 バ゗トコードを1つ1つ解釈して実行
 プログラム実行の様子をプロフゔ゗ル
2-2. Javaプログラムの実行 (゗ンタプリタ)
11
class A {
void gyomu() {
......;
}
}
getstatic #2;
ldc #3;
new 20
invokespecial;
iconst 5;
invokevirtual;
ldc 対応処理
invokevirtual 対応
iconst 対応
new 対応
1命令
読み込む
Javaプログラム Java Bytecode
対応する処理
に従って実行
Java VM Profileしながら実行
・メソッド実行回数
・分岐方向
・仮想メソッド呼び出し
起動は早いけど、
性能がよくない？

 ゗ンタプリタ実行はどうしても遅いので、
動的にバ゗トコードをコンパ゗ルして
ネ゗テゖブコードで高速実行 (Just-In-Timeコンパ゗ル)
 「よく実行するメソッド」(hotspot)をコンパ゗ル
 ゗ンタプリタでのプロフゔ゗ル情報で最適化
2-3. Javaプログラムの実行 (゗ンタプリタ→JIT)
12
bytecode
native code
Java VM
゗ンタプリタ
JIT Compiler
Profile情報
よく実行されるメソッド
あまり実行されないメソッド
オプションCompileThreshold を
超えて実行されたメソッドを
ネ゗テゖブコードにコンパイル
・インライン展開、脱仮想化と
いった最適化を適用
bytecode 両Codeを
併存させた
実行になる
両Codeを
併存させた
形で高速に
実行可能

2-4. コンパ゗ル有無のチェック
13
オプション -XX:+PrintCompilation を使う
 JITコンパ゗ラでのコンパ゗ルの様子が分かります。
＝希望のメソッドがコンパ゗ルされているかが分かります
1566 83 b java.util.HashMap$Entry::<init> (26 bytes)
1567 84 b java.util.HashMap::addEntry (58 bytes)
出力例:
メソッド名（実メソッド名が出るので、
interfaceの実装の場合は注意）
○ よくある（失敗かもしれない）パターン
 ”made not entrant”、”made zombie”
→コンパ゗ルされたコードが使われなくなった場合に出ます。
あまり気にしないでよいことが多いです。
 ”COMPILE SKIPPED”
→コンパ゗ル失敗で、゗ンタプリタ実行のままです。
→Oracle、OpenJDKのバグデータベースで確認。

hoge() {
foo();
}
foo() {
bar();
bar();
}
bar() {
}
2-5-1. ゗ンラ゗ン展開とは？
14
メソッド呼出しに関する最適化で、
呼出し先を呼出し元に展開する技術
 実行性能を向上させるメジャーなコンパ゗ル技術で
ネ゗テゖブコードの実行性能がよくなります
 Getter/Setterなどに見られる「比較的」
コード規模の小さいメソッド呼出しで効果大
hoge() {
}
foo, barを
hogeに展開
すると…
実行順
hoge->foo
foo->bar
foo->bar
実行順
hogeのみ
foo,barは
hogeの実行に
内包されて、
見えなくなる
メソッド
呼出しは
重い処理

2-5-2. ゗ンラ゗ン展開の確認
15
オプション –XX:+PrintInlining を使う
 JITコンパ゗ラでの゗ンラ゗ン展開の様子がわかります
1567 84 b java.util.HashMap::addEntry (58 bytes)
@ 24 java.util.HashMap$Entry::<init> inline (hot)
@ 1 java.lang.Object::<init> inline (hot)
@ 54 java.util.HashMap::resize too big
出力例:
○ よくある成功/失敗パターン
 "inline (hot)" 成功！
 "too big" 失敗。展開対象メソッドのbytecodeが長すぎた
 "already compiled into a big method" 失敗
"already compiled into a medium method" 失敗
展開対象メソッドを単体でコンパ゗ルしたら
そのコードサ゗ズが大きすぎた
 "executed < MinInliningThreshold times" 失敗
実行回数が少なすぎた
メソッド名理由など

2-5-3. ゗ンラ゗ン展開の調整
16
オプション –XX:MaxInlineSize=n を使う
 展開するメソッドの最大bytecodeサ゗ズを指定
 “too big” が出ている場合に有効です。
 デフォルト値35は保守的なので80程度まで上げると
性能が良くなることが多い※です。
オプション–XX:InlineSmallCode=nを使う
 展開するメソッドの最大JITコードサ゗ズを指定…
なのですが、そもそもコードサ゗ズが不明なことが多い…
 一応、“already compiled into a big/medium
method” への対策で有効です。
 デフォルト値1000(x86)はかなり保守的なので10000
弱程度まで上げると性能が良くなることが多い※です。
※必ず性能が良くなるというわけではありません。利用には注意が必要です。

2-6-1. ポリモーフゖズム
17
ポリモーフィズムを乱用するべからず
 ポリモーフゖズム(多態性)は、
オブジェクト指向言語における三種の神器の１つ。
 でも、性能上は使わない方が速い。
 意味のない最適化例:
× オーバーラ゗ドしていないメソッド全てに
明示的に final 修飾子を付ける
(オーバーラ゗ドされたかどうかは、
Java VM が実行時に全部把握しています）
 実際に多態性が必要にならない限り、
Java VM が勝手に最適化してくれます。
ただし、不必要に恐れる必要はない

2-6-2. ポリモーフゖズムと性能の関係
18
 内部的には、以下のようなヒエラルキーが存在
 メソッドの呼び出し箇所ごとに
Java VM が履歴を取って最適に管理
 １になるのが一番いいが、２でもまぁまぁ速い。
 要は、実行時に多態性が使われなければ、速い
…
hoge.non_overridden_method();
…
hoge.overridden_method();
…
fuga.overridden_method();
…
メソッドが、サブクラスで
オーバーライドされていない
オーバーラ゗ドされているが
その呼び出し箇所では
特定のクラスのインスタンス
しか使われたことがない
実際に、メソッドの呼び分けが
必要になったことがある
1
最高
2
高
3
低

2-7. JITの落とし穴：最適化されない処理
19
 Java VM の処理の中には、
JIT の最適化対象になっていないものがある
✖ JIT 生成コード中でそういう操作が行われると、
強制的にインタープリタ実行に戻ってしまう。
× クラスのロード × クラスの初期化
× 例外ハンドリング(Server Compilerの場合)
JIT で最適化されない処理の例
性能上重要なメソッド/ループの中で
例外が発生していたら要注意

2-8. JITの落とし穴：例外ハンドリング
20
 例外の処理は難しいので、゗ンタプリタで実行
 （JIT側の視点）めったに発生しないのでOK…だと思う
（ユーザ視点）複雑な構造からの脱出で便利なのでは？
例外を乱用するべからず
・サンプルプログラム
for (i = 0; i < n; i++) {
for (j = 0; j < m; j++) {
if (…) {
// 最外まで脱出したい！
// breakを2回実行するため
// フラグセットして脱出。
flag = true;
break;
}
}
// flag==trueならすぐに脱出
if (flag) break;
}
・駄目パターンのプログラム
try {
for (i = 0; i < n; i++) {
for (j = 0; j < m; j++) {
if (…) {
// 例外で最外のcatchまで飛べる…
throw new Exception();
}
}
}
}
catch (Exception e) { … }
…;
JITコンパ゗ラ：
例外が発生したので
゗ンタプリタに戻す
ここを抜けても
゗ンタプリタ実行
ここを抜けても
゗ンタプリタ実行

2-8. JITの落とし穴：例外ハンドリング
21
 例外の処理は難しいので、゗ンタプリタで実行
 （JIT側の視点）めったに発生しないのでOK…だと思う
◎（ユーザ視点）通常パスに例外は使わない
例外を乱用するべからず
・サンプルプログラム
for (i = 0; i < n; i++) {
for (j = 0; j < m; j++) {
if (…) {
// 最外まで脱出したい！
// breakを2回実行するため
// フラグセットして脱出。
flag = true;
break;
}
}
// flag==trueならすぐに脱出
if (flag) break;
}
・駄目パターンのプログラム
try {
for (i = 0; i < n; i++) {
for (j = 0; j < m; j++) {
if (…) {
// 例外で最外のcatchまで飛べる…
throw new Exception();
}
}
}
catch (Exception e) { … }
…;

 Javaプログラムでは「メモリ解放」を意識しなくてよい
 Java VMのGarbage Collection機能でメモリを管理
 空き領域が減少すると、不要なデータを自動解放
2-9. Java仮想マシンでのメモリ管理
22
多くのJava VMでは「世代別GC」と呼ばれる管理方式を採用
ほとんどのオブジェクトはすぐに不要（ゴミ）になる点に注目
New領域 Old領域
短寿命オブジェクト中寿命オブジェクト長寿命オブジェクト
●New領域の解放 → Minor GC
●全領域の解放 → Full GC
処理時間が長い

2-10. Javaプログラム実行とGCの関係
23
 Javaプログラム実行とGC処理のタ゗ミングで分類
Java VMオプション実行への影響実行イメージ
-XX:+UseSerialGC
並列GC
-XX:+UseParNewGC
-XX:+UseParallelGC
-XX:+UseParallelOldGC
平行GC
-XX:+UseConcMarkSweepGC
-Xconcgc
GC GC
GC GC GC
Java Java
Java Java Java
Java Java+GC Java+GCJava
利用可能メモリサ゗ズの増大ペースが
非常に速くて、Full GC処理時間が
大きな問題になってきました。
止まってる？
○スループット
×レスポンス
○スループット
△レスポンス
×スループット
○レスポンス

2-11. JavaシステムのFull GCレス化（日立独自機能）
24
ゕプリケーション実行基盤が管理するユーザー情報と
Java VMのメモリ管理を連携させることで
Full GCレスを実現しました
OS
アプリケーション実行基盤
Javaプログラム
Java VM
ユーザーの
セッション情
報等
Full GC
レス
応答性能の
低下なく快適♪
待ち時間と利用を中止するユーザ割合
出展：Forrester (2009)
1秒未満
1秒
2秒
3秒
1%
3%
13% 40%
 数秒単位で待ち時間が生じるとユーザーを失ってしまう恐れ
 例えばWebのショッピングサ゗トなどで影響が大きい
連携
そこで
日立では

2-12. Full GCレス機能（日立独自機能）
25
 プログラムから明示的に確保/解放可能な領域(Eheap)を実装
Java Heap(Jheap)
New Old
Explicit Heap(Eheap)
New Old
ユーザーのログ゗ン時に
セッションオブジェクトを生成
空き容量が枯渇すると
Full GC発生
ログ゗ン時に
セッションを生成
FullGC
発生
ログアウト時に
セッションを削除
空き容量が枯渇しない
ログイン
商品注文
ログアウト
ログイン
商品注文
ログアウト
従来
Full GCレス機能あり

Contents
1. 日立＋Java
5. まとめ
26

3-1. クラウドサービスプラットフォーム Cosminexus V9
27
業務
システム
業務
システム
プライベート
／パブリック
クラウド
ＰａａＳ環境管理
ＣｏｓｍｉｎｅｘｕｓＶ９
リソースプール
uCosminexus Service Director
高品質な業務システム環境の
スピード構築を実現
メモリ空間
共有メモリ空間
ＥＪＢコンテナＷｅｂコンテナ
ＥＪＢ
HTTP
Server
ＥＪＢ
DB
ＪＳＰ/サーブレット
F/W UAP
uCosminexus Application Server
AP・F/Wを含む一貫した性能分析によって、
システムの「見える化」を実現
「見えるクラウド」を実現するCosminexus V9は
クラウドの特性を活かした業務システムの構築を支援しますポイント
uCosminexus Elastic Application Data store
クラウドを支えるデータ管理基盤として、
高スケーラビリティを実現
AP:アプリケーション
F/W:フレームワーク

3-2.「見えるクラウド」を実現するCosminexus V9
28
• uCosminexus Service Director
•サービスレベルに応じたシステムのスケール変更の簡略化を支援
•業務システム環境（ミドルウェア含む）の短期構築を支援
•業務システムを用途別に管理し、再利用性を高めた上で構築作業の高効率化を支援
高品質な業務システム環境のスピード構築を実現
• uCosminexus Elastic Application Data store
• データをメモリに配置することにより高速なアクセス性能を実現
• サーバー間統合仮想メモリーを共通Ｉ／Ｆで透過的にアクセス
• 多重化により可用性を向上、柔軟な構成変更により高いスケーラビリティを確保
クラウドを支えるデータ管理基盤として、高スケーラビリティを実現
• uCosminexus Application Server
• AP・F/Wにおける任意のポイントのトレースを取得可能
• Full GCレス機能で、大容量メモリ環境でも安定動作
AP・F/Wの一貫した性能分析で、システムの「見える化」を実現
AP:アプリケーション、F/W:フレームワーク、I/F:インタフェース

Contents
1. 日立＋Java
・uCosminexus Service Director
・uCosminexus Elastic Application Data store
・uCosminexus Application Server
5. まとめ
29

IT部門のニーズ
サプライチェーンの見直し - 生産拠点の分散化 …
成長市場での市場創造 - 新興国市場への進出 …
コスト競争力の強化 - 業務改善によるコスト低減 …
3-3. 環境変化に対する素早い対応へのニーズ
30
環境変化に、素早く対応したい！
信頼性スピード＆
環境変化に、ＩＴも素早い対応が求められる
システム開発のスピードアップ
システム変更への素早い対応とシステムの安定稼働
クラウドへの期待

テンプレート
3-4. システム開発容易化・高速化への取り組み
◇日立ミドルウェア
 ＡＰ実行基盤
 ＤＢ基盤
 運用管理基盤
リソース活用の全体最適
ＩＴリソース
管理者
業務システム
管理者
物理リソース
サービスの安定稼働
業務サービス業務サービス
仮想サーバ仮想サーバ
各種ミドルウェア各種ミドルウェア
業務サービスの簡単構築
JP1/IT Service Level
Management
JP1
JP1/IT Resource
Management
JP1
uCosminexus
Service Director
31
ＩＴリソース提供サービス
◇業務ＡＰ
業務ＡＰ業務ＡＰ

3-5. uCosminexus Service Directorの概要
32
業務システム管理者の初期基盤設計構築、再構築、構成変更作業を容易化
仮想サーバ
開発用環境
仮想サーバ
検証用環境
ＩＴリソース
管理者
業務システム
管理者
運用管理基盤
ＡＰ実行基盤
ＤＢ基盤
仮想サーバ
本番用環境
① 初期
基盤設計構築
② 開発・検証環境再構築
サービス提供環境の
スピード構築
物理リソース
③ 本番環境スケール変更
サービス別・用途別
の管理と再構築
負荷変動に対する
構成変更の柔軟性
uCosminexus
Service Director
テンプレート
◇日立ミドルウェア
 ＡＰ実行基盤
 ＤＢ基盤
 運用管理基盤
◇業務ＡＰ
業務ＡＰ

3-6. 初期基盤設計構築のスピードゕップ
33
Ｂｅｆｏｒｅ（ＩａａＳ利用）Ａｆｔｅｒ(ＰａａＳ利用)
パターン品質ﾚﾍﾞﾙ
Web+ DB AA
DB AA
・システム構築を手作業で実施・テンプレートを適用し、構築を自動化
人手で設計テンプレートに基づく構築
テンプレート選択
スケール情報入力
解決
課題ミドルウェアも含めた業務サービス基盤の構築に時間と手間が掛かる。
テンプレートを利用し、ミドルウェアも含めた高品質な業務サービス
基盤を短期間で構築できる。
設計書
設計書
設計書
…
OS
ＡＰ基盤
OS
ＡＰ基盤
OS
DB基盤
手動で設定
Ｎ台分
仮想サーバ
OS
ＡＰ基盤
OS
ＡＰ基盤
OS
DB基盤
仮想サーバ
一括で設定
マスター
イメージ化

仮想サーバ
3-7. 環境再構築のスピードゕップ
マスター
イメージ
業務用途構成
受注本番用 Web1,Web2,・・・
開発用 Web1,DB1
検証用 Web1,DB1
※ APｻｰﾊﾞ×3、DBｻｰﾊﾞ×1、Virtage環境の場合の弊社試算値 34
業務システム台帳
・人手でシステム構成を台帳管理
・手動で環境を再構築
・マスタイメージでシステム構成を管理
・一括で環境を再構築
マスタイメージで構成管理
業務用途状態構成
受注本番配備・・・
開発未配備・・・
検証未配備・・・
一括で再構築
システム一覧
解決
アプリ改修のたびに、テスト環境や検証環境の再構築に時間が掛かる。
業務システムの構成がマスタイメージとして、用途別に管理されている。
必要なマスタイメージを選択し、一括で環境を再構築。
課題
人手で構成管理
OS
ＡＰ基盤
仮想サーバ
OS
ＡＰ基盤
OS
DB基盤
手動で回復
OS
ＡＰ基盤
OS
ＡＰ基盤
OS
DB基盤
構成確認と回復指示
300分が90分に！
70%時間短縮※

仮想サーバ
3-8. 性能要件変化への対応のスピードゕップ
35
・マスタイメージでシステム構成を管理
・一括で変更
性能要件の変化へ対応に時間と手間が掛かる。
手作業でするため、人為的ミスを引き起こす可能性がある。
業務システム基盤の構成確認、スケール変更の指示が可能。
マスタイメージで構成確認して変更指示できるため、ミス防止が可能。
課題
・人手でシステム構成を台帳管理
・手動で変更
解決
業務用途構成
受注本番用 Web1,Web2,・・・
開発用 Web1,DB1
検証用 Web1,DB1
業務システム台帳
人手で構成管理
OS
ＡＰ基盤
仮想サーバ
OS
ＡＰ基盤
OS
DB基盤
手動で変更
OS
ＡＰ基盤
マスター
イメージ
マスタイメージで構成管理
受注システムの構成情報
サーバ名称リソース
受注Web1 2コア、4G
受注Web2 2コア、4G
受注DB 4コア、8G
一括で変更
OS
ＡＰ基盤
OS
ＡＰ基盤
OS
DB基盤
OS
ＡＰ基盤
追加
構成確認と変更指示

Contents
1. 日立＋Java
5. まとめ
36

3-9. 背景
37
Ｗｅｂ
メール
セキュリティ
所在地
会議
オフィス文書買い物モバイル
エネルギー
ＩＣカード気象
センサー
交通
データデータデータデータデータデータデータデータ
ＰＣ・サーバー
 あらゆる情報がＩＴ化
 偏在する大量のデータが発生（ビッグデータ）
 分散環境での高速データ処理が必要
インメモリー型分散ＫＶＳ
ネットワーク
NOSQL複雑性排除 ←
シンプルインターフェイスインメモリー分散ＤＢ
開発の容易性高効率メモリー使用高信頼性
NOSQL：Not Only SQL KVS : Key Value Store

3-10. 分散KVS製品uCosminexus Elastic Application Data storeの概要
38
物理メモリ
物理メモリを仮想的に統合
ＫｅｙＶａｌｕｅ
②メモリ間レプリケーション(多重化)
③データ分散配置(ハッシュ/指定)
ＣＥＰＲＤＢファイル
リードライト
既存/他システム
証券取引為替取引チケット予約メール配信稼働収集
ｐｕｔｇｅｔ
①ＫＶＳＩ/Ｆ
②ノード増減容易
(高スケーラブル)
③透過的アクセス
クラウド時代の超大量・高速データ処理を支える分散ＫＶＳ製品
特
長
① 容易なアプリケーション開発
② 高速・高信頼データ処理
④ 同期更新のサポート
③ 高いスケーラビリティ
⑤ ＣＥＰ・ＲＤＢとの連携
データアクセスが容易でシンプルなＫＶＳＩ/Ｆ
メモリ間でのデータ多重化，障害時の高速切換によるシステム無停止化
物理メモリの仮想的統合，データの動的配置による柔軟なスケールアウト・イン
値更新時の排他，複数の値に対するトランザクショナルな制御
イベント処理，データベースへのライト/リードスルー，ライトビハインド
※ 上図は一部開発中・計画中の機能も含んでいます KVS : Key Value Store、I/F : Interface
uCosminexus
Elastic Application
Data store

3-11. 技術概要
39
 平準化処理
 サーバごとの格納データ量(使用メモリ量)に偏りが生じた時に、
格納データ量を平準化して解消
 閾値超過処理
 サーバのデータ格納領域(空きメモリ量)が少なくなった場合は、
ＬＲＵによる外部保管でデータ格納領域を確保
 サーバ障害時対応処理
 クラスタ内のサーバ同士で状態監視，自身の障害通報または
周囲の障害検知でクラスタから切り離し、残りのサーバ群で継続
Ｓ４Ｓ１
Ｓ２Ｓ３
Ｓ４Ｓ１
Ｓ２Ｓ３
空いている
サーバに移動
HDD
全サーバのメモリが
Fullの場合HDDに退避
閾値超過

Contents
1. 日立＋Java
5. まとめ
40

3-12. クラウドを支えるFull GCレス機能
41
集約
物理サーバ
物理サーバ
物理サーバ
物理サーバ
仮想サーバ
仮想サーバ
仮想サーバ
仮想サーバ
販売管理
生産管理
販売管理
生産管理
販売管理
生産管理
販売管理
生産管理ＦｕｌｌＧＣレスなので心配なし。
全ての業務が安定稼働。
Point
サーバメモリが大容量だと、
Ｆｕｌl ＧＣの停止時間が長すぎ
て、同じ物理サーバ上にある
他の業務システムまで
スループットが低下する
メリット
ＦｕｌｌＧＣの発生を抑止し、
突然の無応答を解消
大容量のメモリでもレスポンス低下の心配なしで、安定稼働を実現
従来方式
Ｎｅｗ領域
Ｏｌｄ領域
使用済みの情報が残存。
Full GCで解放。
Ｊａｖａヒープ
Ｎｅｗ領域
新方式
サービスの応答時間
5秒
10秒
15秒
時間
改善
時間時間
5秒
10秒
15秒
セッション情報及びユーザ
指定の情報を自動的に別
領域に配置しＦｕｌｌＧＣの発
生を抑止。
ＦｕｌｌＧＣ
発生
Ｏｌｄ領域
Ｅヒープ領域
Ｊａｖａヒープ
サービスの応答時間
アプリケーションは
修正不要！
適用範囲拡大
無応答を解消！
突然の無応答
オンプレミスクラウド

3-13. JavaVMの高性能化
42
日立ＪａｖａＶＭ
日本ＮＣＲ(株)は、外部プロダクト選定時の評価基
準を標準化して定めているが、その指標は２０～
３０に及ぶ。たとえば処理性能としては、ミリセカンド
単位のレスポンスを追求している。
この厳しい性能評価テストにおいて、
Ｃｏｓｍｉｎｅｘｕｓは総合的に高い評価を獲得した。
特に、安定性に優れていることは高く評価された。
ご使用いただいているお客様からも高い評価
※事例紹介記事より抜粋
日本語コード変換
処理の高速化
文字列操作の
高速化
処理時間で上位を占める
文字列操作を高速化
Ｉ/Ｏのタイミングなどで
必ず発生する文字コード
変換を高速化
日本語処理を高速化
できるのも国産メーカー
ならでは！
性能向上できるのも
ソースを保持している
日立だからこそ！
提案
ポイント
日本語環境での文字列処理の高速化や各種の性能最適化を実施。
高負荷でも安定したサービスを提供。
メリット
サービスの応答が遅くてイライラする・・・。

Contents
1. 日立＋Java
・メモリリーク検出のための情報取得
・性能把握のためのトレース機能強化
5. まとめ
43

Contents
1. 日立＋Java
5. まとめ
44

4-1. Javaの安定動作を支援する取り組み
45
 メモリリークの素早い解析
 Javaヒープ上のオブジェクト統計情報取得
• ヒープ利用状況をクラス別の割合で表示
• クラス間の参照構造を一覧にして出力
(参考URL: http://www.hitachi.co.jp/Prod/comp/soft1/manual/pc/d3M1061/EM100149.HTM)
 性能問題の素早い特定
 Cosminexus PRF（性能解析トレース）機能を強化
• コンポーネントごとの実行時間の取得
• ユーザが希望する部分の実行時間の取得

4-2. Javaでメモリリーク？
46
✖ ある処理が終わったのに、GCでメモリ使用量が減らない
ガベージコレクションは万能ではありません。
メモリリークが発生している可能性アリ
 JavaのGCでは、オブジェクトの要・不要を
「参照関係」から判断します。
✖ オブジェクトを誰かが参照し続けているのが原因
 APIや外部ラ゗ブラリの暗黙的仕様や間違った使い方に起因
 プログラマ的には解放されていると思っている
プログラムの中身をよく知っている場合以外は、
解決に時間を要することが多いです…

4-3. Javaでのメモリリークの例
47
 メモリリークの例：class Cがヒープ領域を圧迫している
参照関係をたどると、原因はclass A
→特定するにはA→B→Cの参照関係の把握が必要
大規模、複雑なソースでは把握するのは困難
A A
B
B
C
C C
C
class Aがclass B
を参照している
class Cがヒープ
領域を圧迫

4-4. メモリリーク解析ツール
48
日立では、Java VMのスレッドダンプ出力を拡張して、
クラス毎の統計を出力可能なコマンドを開発しました
jheapprof [-f| -i] [-class <クラス名>] –p <プロセスID>
<プロセスID>で指定したjavaプロセスの拡張スレッドダンプを出力する
ヒープ領域の利用状況を分析して、クラス別の統計情報を算出
クラス毎の使用量→どのオブジェクトが増えている？
クラスの参照関係→誰がそのオブジェクトを握っている？
機能
参照関係を解析するツールを作りました
この情報を得るのが重要です。

Java Heap Profile
-----------------------
Size Instances Class
1024 4 classA
……
144 12 classC
…
128 2 classB
…
20 5 [Ljava.io.…
16 2 java.lang.…
14 2 [Ljava.lang.…
10 2 java.io.…
4-5. jheapprofコマンドの使い方(1)
49
jheapprofの使い方
(1) ヒープ領域に格納されているクラスの統計を収集する
jheapprof –p 2463 を少なくとも２回実行して゗ンスタンスサ゗ズの増減を把握
<出力例>
クラス名インスタンス数
インスタンス
サイズの合計
Java Heap Profile
-----------------------
Size Instances Class
1232 4 classA
……
372 31 classC
…
128 2 classB
…
20 5 [Ljava.io.…
16 2 java.lang.…
14 2 [Ljava.lang.…
10 2 java.io.…
class Cが
増加

Reference of class classC
-------------------------
classA(0x10766840)
classB(0x10766998)
classC(0x10766a88)
------
classA(0x10766840)
classC(0x10766920)
------
classA(0x10766840)
classC(0x10766920)
classC(0x10766ab8)
------
・・・
4-6. jheapprofコマンドの使い方(2)
50
jheapprofの使い方
(2) ヒープを圧迫しているclass Cの参照元を調べる
jheapprof –class classC –p 2463
<出力例>
コマンド数回でクラスの参照関係を自動抽出！
class Aが
あやしい！
参照の根っこは
すべてclass A
classA→classB→classCの
参照を表す
classA→classCの
参照を表す
classA→classC→classCの
参照を表す

4-7. メモリリークの素早い解析を支援・まとめ
51
メモリリークの素早い解析を支援するjheapprofコマンド
 メモリリーク＝予期しない参照によりオブジェクトが
GCで回収されない状態で残留
 原因究明にはクラスの参照関係の把握が必要
 大規模・複雑なソースでは究明が困難
 スレッドダンプ出力時にクラス別の統計情報を付加
 ヒープ上でクラス別に占めている割合を表示
 クラス構造を一覧にして出力可能
数回のコマンド実行でクラスの参照関係を自動抽出
 Openな環境をお使いの皆様
 VisualVM, jconsole, jmap, jstack, jhatなど色々あります。
• データの増減を追うだけなら上記で十分です。
• ただし、参照関係を追うのは大変みたいです

Contents
1. 日立＋Java
3. CosminexusV9の紹介
5. まとめ
52

4-8. Cosminexus V9でのトレース機能の強化ポ゗ント
53
：従来のトレース取得ポイント F/W:フレームワーク
UAP:ユーザアプリケーション
：Ｖ９以降での新トレースポイント
(ユーザ定義のトレース取得ポイント)
従来はコンテナ間での
連携部分でのみ
トレースを取得
V9では、Javaゕプリケーション内にも
トレースポ゗ントを設置可能
(場所はユーザーが指定可能)
ＥＪＢコンテナＷｅｂコンテナ
ＥＪＢ
HTTP
Server
ＥＪＢ
DB
ＪＳＰ/サーブレット
F/W UAP
トレースの取得可能ポ゗ントを拡充
ユーザプログラム内でもトレースを取得可能
フレームワークを使ったプログラムにも対応
強化点

4-9. Java の BCI 技術を応用
54
 ByteCode Instrumentation 機能で、ユーザ指定メソッド
のバ゗トコードへトレースポ゗ントを埋め込む
゗ンタフェース名しか分からない場合も実装クラスを自動判断
Java VM
class BaseImpl extends Base
性能解析トレースファイル
Javaプログラム
BCI エージェント
a.b.c.Base.exec(...), 123, true
設定フゔ゗ル
exec(...) {
return af;
}
ロード(1)
トレースポイント
（入口）
（出口）
（例外）
挿入
ロード(2)
Cosminexus
PRF デーモン
インスタンス
 BCI利用の利点
 JITコンパ゗ルされる
 プログラム改変無しで
処理を入れられる
 不要になったら外せる

Contents
1. 日立＋Java
5. まとめ
55

5. まとめ
 Javaは身の回りの様々な場所で使われています。
 ポータビリテゖ、スケーラビリテゖ、プログラミング容易性
 日立では、エンタープラ゗ズJavaシステムに対する
高性能・高信頼化へのご要望にお答えするべく、
Cosminexusを中心に、実行基盤製品の開発に
幅広く取り組んでいます。
本セッションでは、以下のような日立の取り組みを
ご紹介しました
 Javaプログラム実行の基本
 Cosminexus V9での強化ポ゗ント
 障害などへの対応力強化に向けた取り組み
56

株式会社日立製作所情報・通信システム社
ITプラットフォーム事業本部開発統括本部
2013/5/11
小幡元樹
END
57

JJavaプログラム実行の仕組みと、高速・安定動作に向けた取り組み

JJavaプログラム実行の仕組みと、高速・安定動作に向けた取り組み

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a JJavaプログラム実行の仕組みと、高速・安定動作に向けた取り組み

Similar a JJavaプログラム実行の仕組みと、高速・安定動作に向けた取り組み (20)

Más de 日本Javaユーザーグループ

Más de 日本Javaユーザーグループ (12)

Último

Último (8)

JJavaプログラム実行の仕組みと、高速・安定動作に向けた取り組み