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

#jvmcasual JVM Operation Casual Talks2014/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/06OutOfMemoryError ？？？？？？？？？？覚悟を決めてちゃんとモニタリングすることを決意

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 Talks2014/04/07 at LINE

@tagomoris (TAGOMORI Satoshi)

14年4月7日月曜日

完

14年4月7日月曜日

完？

14年4月7日月曜日