JVM Operation Casual Talksに参加して思ったことをつらつらと書く

JVM Operation Casual Talks : ATND

内容は参加者のブログエントリとtogetterが下記にありますのでそちらを見るとよいと思います。

JVM Operation Casual Talksに参加しました #jvmcasual - @johtaniの日記 2nd
「JVM Operation Casual Talks」発表資料のリンクをまとめてみる #jvmcasual - 元RX-7乗りの適当な日々
JVM Operation Casual Talks に参加してきました。 - susumuis Info
JVM Operation Casual Talks #jvmcasual - Togetter


で、このエントリでは発表を聞いて思ったことをつらつらと書きます。

ちなみに僕はJava歴10年以上なのですが、JVM運用経験はほとんどありません。最近はちょっとありますけどそれは後述します。

今まではJavaでWebアプリを開発したことはあっても、負荷の少ない業務アプリだったり、運用は保守費の関係上お客さんがやることになっていたりしたためです。

ただSQL書いたことあってもMySQL運用したことが無い人がいるようにJavaでアプリを書いたことがあってもJVMを運用したことが無い人って結構いるような気がしますね。例え悪いw

あとパネルディスカッションでもちょっと話が出ましたが、自分たちで作ったJavaアプリを運用するのか、それともCassandra, Hadoop/HBase, Elasticsearch, SolrのようなJavaで作られたミドルウェアを運用するかで話はちょっと違うと思います。前者ならソースいじれるけど後者は難しい。

Web系だとLL言語で開発することが多いのでJVM運用するとしたら後者のパターンなのかなと思いましたけど、Scalaで開発する話もあったのでそうとも言い切れないようですね。


で、僕のJVM運用話を書くとHadoop/HBase/Hive辺りの話になります。

正確に言うと僕がやったというより別の人がやって僕はそれを眺めていただけですがw

Hadoop/Hiveはまだいいのですが、HBaseはまあ大変です。regionserverがよくダウンします。

以前はHBaseのtar ballを持ってきてほぼそのまま動かしてました。そのため-XX:+UseConcMarkSweepGCだけ有効になっていましたが、今だとこんな感じです。

-Xmx8192m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -Xmn1G -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:... -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=512M

馬本に書いてあるのとだいたい同じです。

HBaseの場合は書き込み負荷が高くなるとメモリストアの情報をディスクにフラッシュします。フラッシュするとヒープに穴ができます。これがヒープの断片化につながります。
ちなみに固定長のバッファを使ってヒープの断片化を避けようというのがMSLABってやつのことだと思ってます。

この辺も参考になるかも
Avoiding Full GCs in Apache HBase with MemStore-Local Allocation Buffers: Part 1 - Cloudera Engineering Blog

ヒープが断片化すると新しくオブジェクトが割り当てられない状況になりアプリケーションスレッドとGCスレッドを両方動かすことができずconcurrent mode failureになりstop the worldになる可能性があります。

デフォルトだとヒープの92%を占有した情報になるとCMS GCが実行されますが、それだと手遅れになる場合があってHBaseだと-XX:CMSInitiatingOccupancyFraction=70にするのが良いらしいです。NorikraもCMSInitiatingOccupancyFractionを下げて効果があったようですが、HBaseと同じようにオブジェクトの生成が多いパターンなのかもしれません。


モニタリング周りの話をするとCassandraではJMXの情報をHTTP JSON APIで取れないようですが、HBaseだと取れます。といいつつHTTP JSON APIは使わずJavaアプリであるJMXToolkitを使ってJMX情報を取得しているのは内緒だ。

HadoopJMXの情報をHTTP JSON APIで取れます。ちなみにTreasure DataではこのJSON APIを取得するhadoop-metricsというruby gemを作ってこれでHadoopのモニタリングをしているらしいです。あとhadoop-metricsを使うfluent-plugin-hadoop-metricsというfluentdプラグインもあるようですね。

僕はノリでfluent-plugin-jstatを書きましたが、これjstatを実行するユーザが監視対象アプリの実行ユーザと同じじゃなきゃいけないのでtd-agent使っている人は使えませんね。

まあ、そんな感じかな。JVM運用周りって情報少ないような気がするのでいろいろ情報交換できるといいですね。