谷本 心 in せろ部屋

はてなダイアリーから引っ越してきました

Day-4 : Too Big to Fail: Top Tips for Massive, Mission-Critical Enteprise Applications

大規模ミッションクリティカル系システムのためのTips。
たった1分遅れただけで、満席になってて座れないぐらいの人気セッションでした。
内容的にも、知らなかったTipsが多い、得るものの多いセッションでした。


このセッションで対象にするシステムは、メモリが16〜100GBぐらい、
スレッドが10〜100ぐらい同時に動くような規模のもの。


1. Heapを抑えるために、Composed OOPS (COOPS) を使いなさい。
方法 : -XX:+UseCompressedOOPS
効果 : ヒープに長く残っている情報を圧縮する。実際2.76GB → 2.27GBになった。


2. 1スレッドで(1リクエストで)たくさんのオブジェクトを生成する場合は、NUMAを使いなさい
方法 : -XX:+UserNUMA
効果 : GCの効率が改善する


3. 共有メモリを良いパフォーマンスで読み出したいなら、Dyrect Mapped ByteBufferを使いなさい
Direct Mapped ByteBufferを利用したデータは、Non-heap領域にロードされ、
ヒープ領域での読み込みに比べ、より高速に参照することができる。
複数JREでファイル(メモリ)を共有したい場合に有効な方法である。


4. Javaとネイティブ(C/C++)で時間を合わせたいなら、System.nanoTime()を使いなさい
CLOCK_MONOTONIC関数が呼ばれるため、これをネイティブ側で利用すると
同じタイムスタンプを取得することができる。


5. 簡単にアプリケーションの挙動を見たい場合は、hprofを使いなさい。
方法 : -Xrunhprof:cpu=sample


6. より正確にhprofの結果を知りたい場合は、HotSpotのインライン化を無効にしなさい
方法 : -XX:-inline
効果 : JITによるインライン化により、行番号がずれる事を防ぐ


7. System.identityHashCode()の利用をやめるとGC時間が短いくなり、Resident Setのサイズも減る
identityHashCodeで生成したハッシュコードはオブジェクト自身に記録され、
その後ずっと残すために、GC前に退避し、GC後に復元される。
この処理がGC時間を増大させてしまう。
シリアライズRMIを利用していると、どうしてもidentityHashCodeを利用してしまう。


という感じで、私自身知らなかった事、つまり得るものの多いセッションでした。
これは後から資料を見る価値がありますね。