Java でつくる低レイテンシ実装の技巧

Java でつくる
低レイテンシ実装の技巧
〜GCはさだめ、さだめは死〜
JJUG CCC 2016 Fall (2016/12/04)
Ryosuke Yamazaki

自己紹介
• 山崎良祐 (やまざき・りょうすけ)
• Twitter: nappa
• ソネット・メディア・ネットワークス所属
(プロバイダの So-net の子会社)
• 本日の発表および発言は個人の見解であり、
所属する組織の公式見解ではありません。

いちおう Oracle Contributor
• mysql-connector-java のバグ修正に貢献
• 詳しくは 2016年10月リリースの
5.1.40 の ChangeLog 参照
• Tシャツもらった!
• PostgreSQLのイベントに
行くときに着ようと思ってる

この枠のハッシュタグ
#ccc_m3

パフォーマンスの評価基準
• 「スループット」とは…
• 「レイテンシ」とは…
単位時間あたりの処理能力
要求してから結果が
返ってくるまでの時間

人間に例えると
• わんこそば１杯を
食べるのに必要な時間
= レイテンシ
• わんこそばを1時間に
何杯食べられるか
= スループット
わんこそば1杯を早く食べられるからといって、
わんこそばを大量に食べられるわけではない
私の場合…
レイテンシ: 平均8秒/杯
スループット: 151杯/時間

例題
• 車の自動ブレーキ制御のソフトウェアを
作るとしたら、要件は……
• 検知してから○ミリ秒以内に反応する
• ○ミリ秒を絶対に超えない
• 他の操作(アクセル) より優先
レイテンシが絶対的に重要
(遅れたら人が死ぬ)

レイテンシが非常に重要なアプリ
• ロケット・人工衛星の姿勢制御
• 医療関係 (MRI、CTスキャン etc)
• 防衛関係 (レーダー、ミサイル etc)
• 航空機 (航法・誘導・制御 etc)
• 自動車 (ブレーキ・エアバッグ etc )
時間内にタスクが終了しないと、タスク処理結果の
価値がなくなる = ハードリアルタイムシステム
専用OSがないと作れない

レイテンシがわりと重要なアプリ
• LINE のメッセージ
• ニコニコ生放送のコメント
• ゲーム
• バナー広告の配信
時間内にタスクが終了しないと、タスク処理結果の
価値が時間の経過によって減少する
= ソフトリアルタイムシステム
特殊な OS がなくとも実装次第でなんとかできる

当社サービス: Logicad
• 広告プラットフォーム
• 月間1500億回、広告を表示
• ピークで1秒あたり 100,000 回
オークションに参加している
…オークション？

ネット広告
のしくみ
※私の勤務先が扱っているものの場合。他にもいろいろある。

オークションで枠の価格が決まる

中身はシステム
A社 B社 C社

入札は JSON API
• ユーザID
• User-Agent
• サイトURL
• IPアドレス
• Referer
• etc…
• 入札額
• 表示したいタグ
• リンク先URL
• etc…
入札リクエスト
( HTTP Request )
入札レスポンス
(HTTP Response)

実装
JSON 受信
JSON を返す
?????????????
オークション開始
オークション終了
100ミリ秒
の
さだめ

イメージ
レスポンス数
レスポンスタイム 100 ms
多少は
超過しても
OK

新機能を追加する→処理時間増加
レスポンス数
超過
増加

増えたらダイエット
レスポンス数
なんとか
して
ダイエット

やらかすと
レスポンス数
会社の
存続に関わる
レベルに…

真空中の光速 = 秒速30万キロ
https://www.flickr.com/photos/walterpro/15373174944/
• 正確には299279458m/s
• 100ミリ秒では太平洋すら往復できない
• 光ファイバー中だと2/3
= 秒速約20万キロ
• 意外に遅い

電気信号の速度 = 光速の6割
• 2.4GHz の CPU = 1秒間に24億サイクル
• CPU の1サイクルは…
= 1 / (2.4 * 1000 * 1000 * 1000)
= 0.000000000416 秒
→0.416 ナノ秒
• 299279458(m/s) * 0.000000000416 * 0.6
= 0.0747 (m/サイクル)
→1サイクルにつき電気信号は 7.4cm しか
進めない

東京からの
ネットワークレイテンシ
(往復時間)
通信相手往復時間
東京〜東京約1〜2ミリ秒
東京〜大阪約5〜10ミリ秒
東京〜台湾約65ミリ秒
東京〜西海岸 100ミリ秒以上

東京からの
ネットワークレイテンシ
(往復時間)
通信相手往復時間
東京〜東京約1〜2ミリ秒
東京〜大阪約5〜10ミリ秒
東京〜台湾約65ミリ秒
東京〜西海岸 100ミリ秒以上
弊社の取引先の1つがココ

JSON 受信
JSON を返す
?????????????
32ミリ秒
( ´_ゝ｀)
32ミリ秒
( ´_ゝ｀)
( ´_ゝ｀)
( ´_ゝ｀)

JSON 受信
JSON を返す
( ´_ゝ｀)
( ´_ゝ｀)
100ミリ秒の半分以上が
光ファイバーに
もってかれる
( ´_ゝ｀)
32ミリ秒
( ´_ゝ｀)
32ミリ秒
( ´_ゝ｀)

disk
disk
レイテンシ源あれこれ
ルータスイッチ
アプリサーバ
DBサーバ
スイッチ

レイテンシ源 (1ms = 1,000,000ns)
操作レイテンシ
LAN 上サーバ間のパケット往復 150,000 ns〜
4KbytesをSSDから読む 150,000ns
HDD のシーク 10,000,000ns (10ms)
出典: https://gist.github.com/jboner/2841832

ハードウェア的な制約
• HDD 遅い
= 最新のものでも針が動くだけで約5ms
= 使えない
• SSD 遅い
= マイクロ秒単位 → アクセスは最小限に
• LAN 遅い
= 早くとも 100マイクロ秒単位 → 最小限に

CPUの中身にもレイテンシ源
インテル® 64 アーキテクチャーおよびIA-32 アーキテクチャー最適化リファレンス・マニュアルより抜粋

レイテンシ源 (1ms = 1,000,000ns)
L1 キャッシュ上のデータ参照 0.5ns
分岐予測ミス 5ns
L2 キャッシュ上のデータ参照 7ns
メインメモリ上のデータ参照 100ns
出典: https://gist.github.com/jboner/2841832
https://www.quora.com/Linux-Kernel-How-much-processor-time-does-a-process-switching-cost-to-the-process-scheduler
何千回・何万回・何十万回と発生するもの
↓
削減するには
低レベルを意識してコードを最適化する

レイテンシ源 (1ms = 1,000,000ns)
Full GC
(-Xmx16g –XX:UseParallelGC -XX:+UseParallelOldGC)
1,500ms〜
(1.5秒〜)
Full GC
(-Xmx24g -XX:+UseG1GC)
16,000ms〜
(16秒〜)
young GC Stop the world
(G1 GC)
80ms〜400ms
出典: 独自測定

今日の話
コードを最適化しよう
GC の悪影響をなんとかしよう

基本的なこと
• 「Javaパフォーマンス」を読もう
Scott Oaks 著
牧野聡訳
Acroquest Technology株式会社監訳
寺田佳央監訳
2015年04月発行
448ページ
ISBN978-4-87311-718-8

プロファイラで測定
• 早すぎる最適化は悪
• まずはプロファイリング
• Netbeans Profilter , jprof など
• 負荷をかけて測定
– なるべく本番に近い負荷をかける
– しばらく放置して十分に JIT Compile させる
– CPU使用率 100% に達する程度にかける
– CPU使用率 100% に達しなかったら
何かが間違ってる

perf
• Linux 向けプロファイラ
• C, C++ で書いたプログラムの
プロファイリングに使う
• 本来 Java 向けのツールではない、が
どうしても使わねばならんのだ
• 実行例
perf record -F 99 -a -g -- sleep 30 && perf report

JVM による最適化の問題点(1)
• Hotspot VM の生成した機械語では frame
pointer が使われない (使う必要が無い)
(frame pointer 用のレジスタ (x86_64 なら rbp
レジスタ) を汎用レジスタとして使う)
• 要するに、メソッドの呼び出し元のメソッド
が判らなくなる
• JVM 起動時に
-XX:+PreserveFramePointer
オプションを付ける

• 呼び出し頻度の多いメソッドが Inline 化され
る (呼び出し元に展開される)
• メソッド呼び出しのオーバーヘッドがなくな
るが、perf では困る
(小さいメソッドが見えなくなる)
• JVM 起動時に
-XX:-Inline
オプションをつける

• メモリ上のアドレスとメソッド名の対応関係
がわからない
• メモリ上のアドレスが実行中にころころ代わ
る
• perf-map-agent を使って名前を解決する
https://github.com/jrudolph/perf-map-agent

# Overhead Command
# ........ ............... ...............................
12.77% java perf-106368.map
[.] Ljp/so_netmedia/rtb/buyer/domain/buyer/XXXXXXXXXXXXXX;.select
|
--- Ljp/so_netmedia/rtb/buyer/domain/buyer/XXXXXXXXXXXXXXX;.select
Ljp/so_netmedia/rtb/buyer/domain/buyer/XXXXXXXXXXXXXXX;.decide
Ljp/so_netmedia/rtb/buyer/application/XXXXXXXXXXXXXXX;.process
Ljp/so_netmedia/rtb/buyer/application/XXXXXXXXXXXXXXX;.execute
Ljp/so_netmedia/rtb/buyer/application/XXXXXXXXXXXXXXX;.channelRead0
Ljp/so_netmedia/rtb/buyer/application/XXXXXXXXXXXXXXX;.channelRead0
Lio/netty/channel/SimpleChannelInboundHandler;.channelRead
Lio/netty/channel/AbstractChannelHandlerContext;.invokeChannelRead
Lio/netty/channel/AbstractChannelHandlerContext;.fireChannelRead
Lio/netty/channel/ChannelInboundHandlerAdapter;.channelRead
Ljp/so_netmedia/rtb/buyer/application/RequestRecordingHandler;.channelRead
Lio/netty/handler/codec/MessageToMessageDecoder;.channelRead
Lio/netty/handler/codec/ByteToMessageDecoder;.channelRead
Lio/netty/handler/timeout/ReadTimeoutHandler;.channelRead
Lio/netty/channel/ChannelInboundHandlerAdapter;.channelRead
Ljp/so_netmedia/rtb/buyer/application/BuyerServerLoggingHandler;.channelRead
Lio/netty/channel/DefaultChannelPipeline;.fireChannelRead
これが 25,000行ほど続く

flame graph
• Netflix の Brendan Gregg さんが作った
perf の結果をグラフ化してくれる
優れもの
• 詳しくは… http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html

Java でつくる低レイテンシ実装の技巧

DB への
アクセス部
デバイスドライバ
カーネル

正規表現で検索もできる
"HashMap" で検索した結果

Intel Performance Counter Monitor
https://software.intel.com/en-us/articles/intel-performance-counter-monitor

Core (SKT) | EXEC | IPC | FREQ | AFREQ | L3MISS | L2MISS | L3HIT | L2HIT | L3MPI | L2MPI | L3OCC | TEMP
0 0 1.81 1.53 1.18 1.22 2381 K 22 M 0.89 0.12 0.00 0.01 3528 30
1 0 1.68 1.42 1.19 1.22 2363 K 22 M 0.90 0.12 0.00 0.01 3744 32
2 0 1.86 1.57 1.18 1.22 2278 K 22 M 0.90 0.11 0.00 0.01 1800 30
3 0 1.84 1.55 1.18 1.22 2172 K 22 M 0.90 0.11 0.00 0.01 1656 30
4 0 1.84 1.56 1.18 1.22 2354 K 23 M 0.90 0.11 0.00 0.01 2592 30
5 0 1.70 1.44 1.18 1.22 2287 K 22 M 0.90 0.11 0.00 0.01 2448 33
6 0 1.84 1.56 1.18 1.22 2208 K 21 M 0.90 0.12 0.00 0.01 3456 30
7 0 1.80 1.53 1.18 1.22 2266 K 22 M 0.90 0.11 0.00 0.01 2232 30
8 0 1.84 1.56 1.18 1.22 2590 K 22 M 0.88 0.12 0.00 0.01 2808 31
9 0 1.73 1.47 1.17 1.22 2645 K 23 M 0.89 0.12 0.00 0.01 3240 31
10 0 1.89 1.62 1.17 1.22 2399 K 21 M 0.89 0.12 0.00 0.00 2592 31
11 0 1.80 1.54 1.17 1.22 2483 K 20 M 0.88 0.12 0.00 0.01 2016 30
12 0 1.73 1.50 1.15 1.22 2388 K 21 M 0.89 0.11 0.00 0.01 1584 28
13 0 1.70 1.46 1.16 1.22 2338 K 21 M 0.89 0.12 0.00 0.01 3888 30
14 0 1.89 1.61 1.18 1.22 1658 K 12 M 0.87 0.63 0.00 0.00 576 30
15 0 1.70 1.48 1.14 1.22 2460 K 20 M 0.88 0.12 0.00 0.01 3816 32
16 0 1.97 1.65 1.20 1.22 1087 K 10 M 0.89 0.74 0.00 0.00 1944 29
17 0 1.78 1.53 1.16 1.22 2445 K 21 M 0.89 0.12 0.00 0.01 2880 29
---------------------------------------------------------------------------------------------------------------
SKT 0 1.80 1.53 1.18 1.22 40 M 375 M 0.89 0.20 0.00 0.00 46800 28
---------------------------------------------------------------------------------------------------------------
TOTAL * 1.80 1.53 1.18 1.22 40 M 375 M 0.89 0.20 0.00 0.00 N/A N/A
Instructions retired: 75 G ; Active cycles: 49 G ; Time (TSC): 2317 Mticks ; C0 (active,non-halted) core residency: 96.57 %
C1 core residency: 2.92 %; C3 core residency: 0.48 %; C6 core residency: 0.03 %; C7 core residency: 0.00 %;
C2 package residency: 0.00 %; C3 package residency: 0.00 %; C6 package residency: 0.00 %; C7 package residency: 0.00 %;
PHYSICAL CORE IPC : 1.53 => corresponds to 38.28 % utilization for cores in active state
Instructions per nominal CPU cycle: 1.80 => corresponds to 45.00 % core utilization over time interval
---------------------------------------------------------------------------------------------------------------
※Intel Xeon E5-2699v3 で実行中の様子。CPU によって違うかも

Core (SKT) | EXEC | IPC | FREQ | AFREQ | L3MISS | L2MISS | L3HIT | L2HIT | L3MPI | L2MPI | L3OCC | TEMP
0 0 1.81 1.53 1.18 1.22 2381 K 22 M 0.89 0.12 0.00 0.01 3528 30
1 0 1.68 1.42 1.19 1.22 2363 K 22 M 0.90 0.12 0.00 0.01 3744 32
2 0 1.86 1.57 1.18 1.22 2278 K 22 M 0.90 0.11 0.00 0.01 1800 30
3 0 1.84 1.55 1.18 1.22 2172 K 22 M 0.90 0.11 0.00 0.01 1656 30
4 0 1.84 1.56 1.18 1.22 2354 K 23 M 0.90 0.11 0.00 0.01 2592 30
5 0 1.70 1.44 1.18 1.22 2287 K 22 M 0.90 0.11 0.00 0.01 2448 33
6 0 1.84 1.56 1.18 1.22 2208 K 21 M 0.90 0.12 0.00 0.01 3456 30
7 0 1.80 1.53 1.18 1.22 2266 K 22 M 0.90 0.11 0.00 0.01 2232 30
8 0 1.84 1.56 1.18 1.22 2590 K 22 M 0.88 0.12 0.00 0.01 2808 31
9 0 1.73 1.47 1.17 1.22 2645 K 23 M 0.89 0.12 0.00 0.01 3240 31
10 0 1.89 1.62 1.17 1.22 2399 K 21 M 0.89 0.12 0.00 0.00 2592 31
11 0 1.80 1.54 1.17 1.22 2483 K 20 M 0.88 0.12 0.00 0.01 2016 30
12 0 1.73 1.50 1.15 1.22 2388 K 21 M 0.89 0.11 0.00 0.01 1584 28
13 0 1.70 1.46 1.16 1.22 2338 K 21 M 0.89 0.12 0.00 0.01 3888 30
14 0 1.89 1.61 1.18 1.22 1658 K 12 M 0.87 0.63 0.00 0.00 576 30
15 0 1.70 1.48 1.14 1.22 2460 K 20 M 0.88 0.12 0.00 0.01 3816 32
16 0 1.97 1.65 1.20 1.22 1087 K 10 M 0.89 0.74 0.00 0.00 1944 29
17 0 1.78 1.53 1.16 1.22 2445 K 21 M 0.89 0.12 0.00 0.01 2880 29
---------------------------------------------------------------------------------------------------------------
SKT 0 1.80 1.53 1.18 1.22 40 M 375 M 0.89 0.20 0.00 0.00 46800 28
---------------------------------------------------------------------------------------------------------------
TOTAL * 1.80 1.53 1.18 1.22 40 M 375 M 0.89 0.20 0.00 0.00 N/A N/A
Instructions retired: 75 G ; Active cycles: 49 G ; Time (TSC): 2317 Mticks ; C0 (active,non-halted) core residency: 96.57 %
C1 core residency: 2.92 %; C3 core residency: 0.48 %; C6 core residency: 0.03 %; C7 core residency: 0.00 %;
C2 package residency: 0.00 %; C3 package residency: 0.00 %; C6 package residency: 0.00 %; C7 package residency: 0.00 %;
PHYSICAL CORE IPC : 1.53 => corresponds to 38.28 % utilization for cores in active state
Instructions per nominal CPU cycle: 1.80 => corresponds to 45.00 % core utilization over time interval
---------------------------------------------------------------------------------------------------------------
※Intel Xeon E5-2699v3 で実行中の様子。CPU によって違うかも
意味わからないと思うので解説

CPUの中身
(24コアの CPU の例)

CPUコアの中身

CPUコアの中身
ALU = 整数演算器
1コアに3個ある
(同時に3つの計算ができる）

CPUコアの中身
なるべく演算器の
稼働率が高くなるように
命令を並び替える

メモリはすごく遅い
• 足し算1回…0.5サイクル
• L1 キャッシュ ... 5サイクル
• L2 キャッシュ … 12サイクル
• L3 キャッシュ… 42サイクル
• メインメモリ…もっと
• メモリアクセスが多いと計算ユニットが
空回りする
= CPU使用率100%でも CPU の中身は
ほとんど遊んでたりする
(Intel Skylake アーキテクチャの場合）

キャッシュ階層
メインメモリ
L3キャッシュ
L2キャッシュ
L1キャッシュ
…45MB/28コア
…256KB/コア
…64KB/コア
64GB くらい
メインメモリは遠い・遅いので、まずキャッシュメモリを順番に参照する
データが無ければ…
欲しいデータ
(Intel Haswell-EP アーキテクチャの場合）

2回目の参照に備えて…
メインメモリ
L3キャッシュ
L2キャッシュ
L1キャッシュ
45MB/28コア
256KB/コア
64KB/コア
64GB くらい
1回目の参照後、2回目の参照に備えてただちにキャッシュメモリに書き込んでいく
データ
データ
データ
データ

2回目の参照は…
メインメモリ
L3キャッシュ
L2キャッシュ
L1キャッシュ
45MB/28コア
256KB/コア
64KB/コア
64GB くらいデータ
データ
データ
データここにある!
すぐ取れる!

容量がいっぱいになると消える
けど…
メインメモリ
L3キャッシュ
L2キャッシュ
L1キャッシュ
45MB/28コア
256KB/コア
64KB/コア
データ
データ
ここには残ってる!!

容量がいっぱいになると消える
けど…
メインメモリ
L3キャッシュ
L2キャッシュ
L1キャッシュ
45MB/28コア
256KB/コア
64KB/コア
データ
L2 から消えても
ここには残ってる!!

64バイト一気に取ってくる
メインメモリ
L3キャッシュ
L2キャッシュ
L1キャッシュ
メモリアクセスは64バイト (Java long 8個分)。隣接するデータも一緒に取ってくる
64バイトのデータ

読み方
• IPC
– instruction per cycle
– 命令を1サイクルで何個できたか
– (CPUによって違うけど) 2 超えたらすごいと思う
– 1を割っている場合は…
= 演算ユニットがメモリアクセス待ちで
待っている
= (理論上) もっと改善できる
• L3hit … L3 キャッシュヒット率
• L2hit … L2 キャッシュヒット率

perf のいいところ
• L2 キャッシュミスの発生している箇所を
特定できる
perf record -F 99 -a -g -e cache-misses

# ........ ............... ................................ .....
#
5.28% java perf-106368.map [.] Ljava/util/Arrays;.binarySearch0
|
--- Ljava/util/Arrays;.binarySearch0
|
|--96.20%-- Ljava/util/Arrays;.binarySearch
| Ljp/so_netmedia/rtb/kvs/domain/user/XXXXXXXXXXXXXXX;.XXXXXXXXXXXXXXX
| Ljp/so_netmedia/rtb/buyer/domain/buyer/XXXXXXXXXXXXXXX;.isCalculated
| Ljp/so_netmedia/rtb/buyer/domain/buyer/XXXXXXXXXXXXXXX;.match
| Ljp/so_netmedia/rtb/buyer/domain/buyer/XXXXXXXXXXXXXXX;.select
| Ljp/so_netmedia/rtb/buyer/domain/buyer/XXXXXXXXXXXXXXX;.decide
| Ljp/so_netmedia/rtb/buyer/application/XXXXXXXXXXXXXXX;.process
| Ljp/so_netmedia/rtb/buyer/application/XXXXXXXXXXXXXXX;.execute
| Ljp/so_netmedia/rtb/buyer/application/XXXXXXXXXXXXXXX;.channelRead0
| Ljp/so_netmedia/rtb/buyer/application/XXXXXXXXXXXXXXX;.channelRead0
| Lio/netty/channel/SimpleChannelInboundHandler;.channelRead
| Lio/netty/channel/AbstractChannelHandlerContext;.invokeChannelRead
| Lio/netty/channel/AbstractChannelHandlerContext;.fireChannelRead
| Lio/netty/channel/ChannelInboundHandlerAdapter;.channelRead
| Ljp/so_netmedia/rtb/buyer/application/RequestRecordingHandler;.channelRead
| Lio/netty/channel/AbstractChannelHandlerContext;.invokeChannelRead
java.util.Arrays.binarySearch は L2キャッシュミス発生源
アルゴリズム的に仕方無い

正規表現を使って着色
HashMap" で検索した結果

オブジェクトはメモリ上でどう表現されるか
class Hoge {
}
new Hoge();
コード
クラス定義への pointer(4バイト)
GC 用フラグ(4バイト)
ロック用のフラグ (4バイト)
ヒープ
※64bit環境・ヒープサイズ32GB以下のとき。以下同様

以降、このように表記
クラス定義への pointer(4バイト)
フラグ類 (4バイト)
ロック用のフラグ (4バイト)
ヘッダ (12バイト)

オブジェクトを3つ作ってみた
class Hoge {
}
new Hoge();
new Hoge();
new Hoge();
コードヒープ

インスタンス変数はヘッダ直下に
class Hoge {
int a = 1;
}
new Hoge();
コード
変数 a (4バイト)
ヒープ

並び替えされる
class Hoge {
int a = 1;
long b = 2;
}
new Hoge();
コード
変数 b (8バイト)
変数 a (4バイト)
ヒープ

参照型
Integer.valueOf(12345)
コード
数値12345 (4バイト)
ヒープ
数値67890L (8バイト)
Long.valueOf(67890L)

配列
new int[] { 1, 2, 3 };
コードヒープ
数値 “1” (4バイト)
数値 “2” (4バイト)
数値 “3” (4バイト)
配列の長さ “3” (4バイト)

参照
class A {
}
class B {
A a = new a();
}
new B();
コードヒープ
a のヘッダ
(12バイト)
b のヘッダ
(12バイト)
ポインタ (4バイト)

HashMap
HashMap<String, Integer> m =
new HashMap<>();
m.put("Apple", 3);
m.put("Orange", 2);
m.put("Banana", 10);

HashMap<String, Integer> m
HashMap$Node[16]
"Apple"
3
"Orange" "Banana"
102
HashMap$NodeHashMap$NodeHashMap$Node
key valuekey value key value
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Eclipse Collections を使う
MutableObjectIntMap<String> m2 =
ObjectIntMaps.mutable.of();
m2.put("Apple", 3);
m2.put("Orange", 2);
m2.put("Banana", 10);

ObjectIntHashMap<String> m
Object[8] keys
"Apple"
"Orange"
"Banana"
int[8] values
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
1003 0 0 2 0 0
全体のサイズが小さくなる。キャッシュにも乗りやすい

HashSet → ArrayList へ置換
してみた
• HashSet
– 中身は HashMap
– add, get, remove, contains, size の
実行時間が O(1)
• ArrayList
– 中身は配列
– get, remove, contains, size の実行時間が O(N)
O(1) < O(N) のはずなんだが…

レスポンスタイム半減
WRYYYYYYYYYYYYYYYYY

もっとやりたい人
• HotSpot VM が生み出した機械語を
逆アセンブルして見てみましょう。
詳しい使い方はおググりください
-XX:+PrintAssembly
:
0x000000010d528f80: mov %eax,-0x14000(%rsp)
0x000000010d528f87: push %rbp
0x000000010d528f88: sub $0x30,%rsp
0x000000010d528f8c: movabs $0x12166e950,%rax
0x000000010d528f96: mov 0x8(%rax),%edi
0x000000010d528f99: add $0x8,%edi
0x000000010d528f9c: mov %edi,0x8(%rax)
0x000000010d528f9f: movabs $0x12166e460,%rax ; {metadata({method}
{0x000000012166e460} 'disjoint' '([I[I)Z' in '.......

ここまで来れば
• 逆アセンブル結果を見て Java のソースを
書き換えることで高速化できる
• ループアンローリング等、C/C++ でしか
有効でないと思われていたテクニックも
Java で使える
• インラインアセンブラを使えない点を除けば
ほとんど C/C++ と同レベルの最適化が
できる
• ただし GC だけはどうしようもない

ヒープをケチると GC 大量発生
リクエスト数
会社の
存続に関わる
レベルに…

G1 GC しかない
• G1 GC は非常に優秀
• G1 GC については JJUG CCC 2015 Fall の
KUBOTA Yuji さんの発表を参照
http://www.slideshare.net/YujiKubota/garbage-
first-garbage-collection
• 大量にヒープとCPUコアを割り当てれば
Full GC が滅多に起きない

GC による Stop the world
• -XX:+UseParallelGC → 0.3%
-XX:+UseG1GC → 0.1%
• もはや G1 GC でいいんじゃないか
• 弊社の主戦力は G1 GC 、ヒープ30GBytes

ヒープ 30GBytes の世界
• ヒープダンプ取れない
(取るのに10時間以上かかる…)
• 取れても VisualVM で開けない
(大量のメモリを積んだマシンでないと…)
• 開けても解析できない
(OQL 1つ走らせるのに2時間以上…)
ヒーププロファイリング困難

恐怖の GCLocker Initiated GC
• JNI API の
GetPrimitiveArrayCritical
GetStringCritical
を呼ぶと GC の実行が保留される
→そのまま放置すると OutOfMemoryError
• ReleasePrimitiveArrayCritical
ReleaseStringCritical
を呼ぶと GC が再開する
→GC 保留中にたまったガベージを
一気に回収する = 時間がかかることがある

使ってはいけない Java SE API
java.io.ObjectInputStream#bytesToFloats, bytesToDoubles
java.io.ObjectOutputStream#floatsToBytes, doublesToBytes
java.nio.Bits#copyFromShortArray, copyToShortArray
java.nio.Bits#copyFromIntArray, copyToIntArray
java.nio.Bits#copyFromLongArray, copyToLongArray
java.util.zip.Adler32#updateBytes
java.util.zip.CRC32#updateBytes
java.util.zip.Deflater#setDictionary, deflateBytes
java.util.zip.Inflater#setDictionary, inflateBytes
java.lang.ClassLoader$NativeLibrary.load, unload
java.lang.ClassLoader#findBuiltinLib
java.util.TimeZone#getSystemTimeZoneID
java.util.zip.ZipFile#open
GCLocker Initiated GC を発生させるので、使わない!

GClocker Initiated GC 対策
• GC ログを見て、
GClocker Initated GC を見たら直ちに
「使ってはいけないAPI」を使っている
箇所を特定し、駆逐して差し上げる
• ライブラリの中でも使っていたりする
• デバッガを使って「使ってはいけない API」
を使っている箇所を燻り出す

モニタリング
• GC ログを監視
– GCはさだめ
– さだめは死
– 己のさだめをうけとめよ
• HTTPレスポンスのパーセンタイル値を
監視
– 99.9、99、98、95、75、50パーセンタイル値

弊社の現状
• 平均約 5 ms でレスポンスを返しています
• 99.5% のリクエストは 100 ミリ秒以内に
返しています
• 今後もがんばります。Java で戦い続けます
• 他にも色々テクニックがありますが
またの機会に

Java でつくる低レイテンシ実装の技巧

Java でつくる低レイテンシ実装の技巧

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(17)

Similar to Java でつくる低レイテンシ実装の技巧

Similar to Java でつくる低レイテンシ実装の技巧(20)

Recently uploaded

Recently uploaded(9)