Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
JavaOne 2012で印象に残ったセッションを振り返るビッグデータ時代のメモリ管理は  やっぱり大変みたいです         GOMI Akiko
自己紹介 五味明子 GOMI Akiko 編集者出身のフリーランスライター  EnterpriseZine、クラウドwatch、gihyo.jp、  ITmediaなど主にWeb媒体でエンプラ系の記事を  書いてます サンフランシスコのJ...
数少ないセッションにしか参加しておりませんが…… いちばんおもしろかった「Big RAM」というセッ  ションの内容を紹介します セッションを行ったのはサンマテオのビッグデー  タベンチャーCausata(http://www.causat...
いわゆるビッグデータがバズっておりますが… ニールさん曰く「あと4年でサーバマシンはテラ    バイトクラスのメモリがふつうに搭載されるよう    になる」そうです   その理由としてはメモリ価格の大幅な低下がやは    り大きい。3年前に...
どうする!?ガベージコレクション!      メモリ512GBのDellサーバ(4×8コアプロセッサ)+JDK 1.7.0でベン      チマークを取った結果…                                         ...
G1がダメなら並列化やCMSでイケるかというとそう単純でもなく… やっぱりいろいろトレードオフがあるわけで フリースペースをたくさん取ればいいというものでもないし
じゃあどうすればいいのさo(`ω´*)oGCにポーズタイムを発生させない夢のJVMがなんとあるのです!(ただし商用)Azul SystemsのZingというOracle HotSpotと100%互換のJVM ニールさんが取ったベンチでは250G...
そのほかにも工夫すればなんとかな るかもしれない…  Direct ByteBuffers  OffHeapObject  バイト配列をon-heapでストア  メモリマップドファイルなどOSのキャッシュを   活用  Etc…結局、...
Upcoming SlideShare
Loading in …5
×

JavaOne報告会 LT資料

765 views

Published on

2012年9月にサンフランシスコで行われたJavaOneで聞いたセッションのひとつの内容を東京のJavaOne報告会でLTで発表させていただきました。ビッグデータ時代、ビッグメモリ時代のガベージコレクションのお話です。

Published in: Technology
  • Be the first to comment

JavaOne報告会 LT資料

  1. 1. JavaOne 2012で印象に残ったセッションを振り返るビッグデータ時代のメモリ管理は やっぱり大変みたいです GOMI Akiko
  2. 2. 自己紹介 五味明子 GOMI Akiko 編集者出身のフリーランスライター EnterpriseZine、クラウドwatch、gihyo.jp、 ITmediaなど主にWeb媒体でエンプラ系の記事を 書いてます サンフランシスコのJavaOne取材は4年ぶり3回目、 ただし今回はOOWの取材がメインだったので実 はあまりJavaOneを見てないです… Twitterもやってます→@g3akk
  3. 3. 数少ないセッションにしか参加しておりませんが…… いちばんおもしろかった「Big RAM」というセッ ションの内容を紹介します セッションを行ったのはサンマテオのビッグデー タベンチャーCausata(http://www.causata.com/) のデベロップメントリードのニール・ファーガソ ンさん
  4. 4. いわゆるビッグデータがバズっておりますが… ニールさん曰く「あと4年でサーバマシンはテラ バイトクラスのメモリがふつうに搭載されるよう になる」そうです その理由としてはメモリ価格の大幅な低下がやは り大きい。3年前に比べて半分くらいに下がって いる で、この傾向はまだまだ続く…… データもどんどん増える… メモリの管理がたいへんになるしパフォーマンス にも気をつけないとビジネスにならない
  5. 5. どうする!?ガベージコレクション! メモリ512GBのDellサーバ(4×8コアプロセッサ)+JDK 1.7.0でベン チマークを取った結果… G1だと結 局28分も かかって しまったヒープサイズが120GB以上になるとまともにコレクタが動かない ※ヒープ領域の90%はアクティブデータ、残り10%はフリー状態でテスト
  6. 6. G1がダメなら並列化やCMSでイケるかというとそう単純でもなく… やっぱりいろいろトレードオフがあるわけで フリースペースをたくさん取ればいいというものでもないし
  7. 7. じゃあどうすればいいのさo(`ω´*)oGCにポーズタイムを発生させない夢のJVMがなんとあるのです!(ただし商用)Azul SystemsのZingというOracle HotSpotと100%互換のJVM ニールさんが取ったベンチでは250GBのヒープ領域に230GBのライブデータを 載せてもつねに100ミリ秒以下のポーズタイムだったとか! ちなみに100GB程 度なら75ミリ秒、G1は225秒…はっきり言って比べ物にならない速さ!!
  8. 8. そのほかにも工夫すればなんとかな るかもしれない…  Direct ByteBuffers  OffHeapObject  バイト配列をon-heapでストア  メモリマップドファイルなどOSのキャッシュを 活用  Etc…結局、パーフェクトな方法はない!でもこれからはマルチテラバイトヒープの時代になるだから効率的なメモリ管理は必須自分のコードとデータを使っていろいろ試してみるべし!

×