NorikraのJVMチューンで
苦労している話
#jvmcasual JVM Operation Casual Talks
2014/04/07 at LINE
@tagomoris (TAGOMORI Satoshi)
14年4月7日月曜日
TAGOMORI Satoshi (@tagomoris)
LINE Corp.
Development Support Team
14年4月7日月曜日
Schema-less Stream
Processing with SQL
Norikra
Schema-less Stream
Processing with SQL
14年4月7日月曜日
Norikraの特徴
JRuby (EsperというJavaのライブラリ使用)
ストリーム処理エンジン
メタデータの他はクエリ処理の中間状態のみ保持
全データがオンメモリ
入力データを大量に受け取っては破棄
再起動 → 中間状態を破棄 (基本的に不可能)
14年4月7日月曜日
Norikraの現状 in LINE
一部サービスで本番運用中
Input: ピーク時 最大 2500 events/seconds (∼10Mbps)
500,000,000 events (4/1∼)
1 norikra process
4 fluentd process (fluent-plugin-norikra) on a server
1CPU 4core (8 thread), 16GB RAM
14年4月7日月曜日
Norikra in 2013 (0.1.0-0.1.2)
無防備状態
ほぼJVMデフォルト設定で運用
-Xmx4096m だけ
4ヶ月くらいは元気に動いてた
14年4月7日月曜日
Norikra崩壊
年末年始の案件でトラフィック増
→ Full GC で帰ってこなくなる事件
とりあえずオプションを足してお茶を濁す
-Xmx4096m -XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode -XX:NewRatio=4
http://qiita.com/harukasan/items/cc3eac01c917afc7cbde
14年4月7日月曜日
とりあえず安定期
2014 early
あれ? 割とえいやでやったけど動いてるぞ
忘却
14年4月7日月曜日
Norikra崩壊 at 2014/03/06
OutOfMemoryError ??????????
覚悟を決めてちゃんとモニタリングすることを決意
derived + jstat でメモリ状況のグラフ化
http://blog.nomadscafe.jp/2013/02/
derivedgrowthforecastpostjava.html
14年4月7日月曜日
以後 毎週木曜 昼に死亡
火曜・木曜にトラフィックが多い
が、なぜか木曜だけ死亡する??? ナンデ????
そもそもなんでold領域をそんなに使う???
火曜 木曜
14年4月7日月曜日
SoftRef なるものの存在
どうもそういうものがあるとold領域が使われるらし
い、というあやふやな理解
http://www.oracle.com/technetwork/java/
hotspotfaq-138619.html#gc_softrefs
14年4月7日月曜日
GCパラメータをいじる期
GC関連の情報にあたりながら試行錯誤
-Xmx4096m -XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:NewRatio=1 -XX:NewSize=2048m
-XX:SurvivorRatio=2 -XX:MaxTenuringThreshold=10
-XX:TargetSurvivorRatio=80 -XX:SurvivorRatio=2
-XX:MaxTenuringThreshold=15
-XX:TargetSurvivorRatio=80
-XX:SoftRefLRUPolicyMSPerMB=200
14年4月7日月曜日
結果
木曜昼を乗り切ったぞ!
suv0/suv1 も使うようになったように見える!
これで勝った!!!!!
14年4月7日月曜日
結果
木曜昼を乗り切ったぞ!
suv0/suv1 も使うようになったように見える!
これで勝った!!!!!
13:07 xxxx: 今回キャンペーンの視聴数がそれぞれいつ
もよりかなり少なかったみたいなので、イベント総数
としては先週より少なそうですね
14年4月7日月曜日
神降臨
http://d.hatena.ne.jp/nekop/20140327/1395886237
“オブジェクトアロケーションが激しいようなアプリ
ケーションでは92%だと手遅れになることがあるの
でCMSInitiatingOccupancyFractionは下げたほうが良
い。70とか。”
14年4月7日月曜日
ガッと変更
-Xmx4096m -Xms4096m -XX:+UseConcMarkSweepGC
-XX:+UseCompressedOops
-XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSInitiatingOccupancyOnly
-XX:NewRatio=1 -XX:NewSize=2048m
-XX:SurvivorRatio=2 -XX:MaxTenuringThreshold=15
-XX:TargetSurvivorRatio=80
-XX:SoftRefLRUPolicyMSPerMB=200
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps
-XX:+HeapDumpOnOutOfMemoryError
14年4月7日月曜日
結果
stop the worldは0.2秒以下
14年4月7日月曜日
雑感
old領域の使用率が高い状態でGCが走っても全部解放
できるところまで走らない (途中でやめちゃう)
そもそもold領域の使用率が高い状態になる前に片を
つけるのが重要?
同トラフィックをdev環境(仮想2cpu)に流したら stop
the world の時間が1秒近くに……良いCPU重要
保持しているデータが多いわけではないからG1GCは
不要?
14年4月7日月曜日
Norikra 0.1.6以降
このあたりのJVM optionをデフォルト有効にして起動
作者にJVMの質問とかあんまりしてほしくない
--gc-log などのオプションを追加
ユーザ各位にも頑張っていただきたい
めでたしめでたし
14年4月7日月曜日
NorikraのJVMチューンで
苦労しているた話
#jvmcasual JVM Operation Casual Talks
2014/04/07 at LINE
@tagomoris (TAGOMORI Satoshi)
14年4月7日月曜日
完
14年4月7日月曜日
完?
14年4月7日月曜日

NorikraのJVMチューンで苦労している話