5

私はメモリを大量に消費するアプリケーションを支援するオプションを模索しており、そうすることでTerracottaのBigMemoryに出くわしました。私が収集したものから、彼らはガベージコレクションされていないオフヒープの「ネイティブメモリ」を利用しており、シリアル化/逆シリアル化の問題により、これはヒープストレージよりも約10倍遅いようです。BigMemoryについて読む前は、通常のJNI以外の「ネイティブメモリ」について聞いたことがありませんでした。BigMemoryは、さらに検討する必要のある興味深いオプションですが、シリアル化の問題を回避できれば、ネイティブメモリで何ができるのか興味があります。

ByteBufferシリアル化の問題がない場合（たとえば、巨大なものと比較している場合）、Javaネイティブメモリは従来のヒープメモリよりも高速ですか（これにはオブジェクトが必要だと思いますか？ byte[]）？それとも、ガベージコレクションなどの気まぐれがこの質問に答えられないようにしますか？「測定する」がこのあたりの一般的な答えであることは知っていますが、Javaでネイティブメモリがどのように機能するかについてはまだ十分にわかっていないため、代表的なテストを設定しないのではないかと思います。

4

3 に答える 3

4

ダイレクト メモリは、データの 1 つのコピーを回避するため、IO の実行時に高速です。ただし、アプリケーションの 95% では、違いに気付かないでしょう。

データを直接メモリに保存できますが、データ POJO を保存するよりも高速ではありません。(または、安全か、読み取り可能か、保守可能か) GC が心配な場合は、事前にオブジェクトを作成し (変更可能にする必要があります)、それらを破棄せずに再利用してください。オブジェクトを破棄しない場合、収集するものは何もありません。

シリアル化の問題がない場合 (たとえば、巨大なバイト [] と比較している場合)、Java ネイティブ メモリは従来のヒープ メモリよりも高速ですか (これには ByteBuffer オブジェクトが必要だと思いますか?)。

intデータをバイトに変換せずに4バイト全体を読み書きできるため、バイト以外を使用する場合、ダイレクトメモリはバイト[]を使用するよりも高速になります。ただし、すべてのアクセスを境界チェックする必要があるため、POJO を使用するよりも遅くなります。

それとも、気まぐれなガベージ コレクションなどにより、この質問は答えられないものになるのでしょうか?

速度は GC とは関係ありません。GC は、オブジェクトを作成または破棄する場合にのみ重要です。

ところで: 破棄するオブジェクトの数を最小限に抑え、Eden のサイズを大きくすると、小さなコレクションでさえ、長時間 (たとえば 1 日) 発生するのを防ぐことができます。

于 2011-05-02T23:00:12.783 に答える
2

BigMemoryのポイントは、ネイティブメモリが高速であるということではなく、メモリへの参照を追跡してクリーンアップする作業を行う必要があるガベージコレクタのオーバーヘッドを削減することです。ヒープサイズが大きくなると、GC間隔とCPUコミットメントも大きくなります。状況によっては、これにより一種の「ガラ​​スの天井」が作成され、Javaヒープが非常に大きくなり、GCが大量に発生し、GCが起動するたびに大量のプロセッサパワーを消費する可能性があります。また、多くのGCアルゴリズムでは多くのJVMはこれを処理するのにはるかに優れていますが、GC参照追跡アルゴリズムのその部分が終了するまで誰も何もできないことを意味するあるレベルのロック。私がアプリサーバーとJVMを使用して作業しているところ、「ガラスの天井」は約1.5GBであることがわかりました。それよりも大きいヒープを構成しようとすると、GCルーチンが合計CPU時間の50％以上を消費し始めるため、非常に現実的なコストになります。これは、JVMベンダーが提供するさまざまな形式のGC分析によって決定されました。

一方、BigMemoryは、メモリ管理に対してより手動のアプローチを採用しています。これにより、オーバーヘッドが削減され、HashMapに似たはるかに単純なアプローチではありますが、Cで行ったように、独自のメモリクリーンアップを実行する必要があります。これにより、従来のガベージコレクションルーチンが本質的に不要になり、その結果、そのオーバーヘッドがなくなります。Terracottaの人々は、Javaガベージコレクターの下から抜け出すのが簡単な方法であるため、ByteBufferを介してネイティブメモリを使用したと思います。

次のホワイトペーパーには、BigMemoryの設計方法に関する優れた情報と、GCのオーバーヘッドに関する背景情報が含まれています：http ：//www.terracotta.org/resources/whitepapers/bigmemory-whitepaper 。

于 2011-05-03T03:29:45.503 に答える
1

シリアライゼーションの問題を回避できれば、ネイティブ メモリで何ができるのか興味があります。

あなたの質問は誤った仮定に基づいていると思います。私の知る限り、彼らがここで話しているシリアライゼーションの問題を回避することは不可能です。できる唯一のことは、BigMemory に入れるオブジェクトを単純化し、カスタムのシリアライゼーション/デシリアライゼーション コードを使用してオーバーヘッドを削減することです。

ベンチマークによってオーバーヘッドの大まかなアイデアが得られるかもしれませんが、実際のオーバーヘッドはアプリケーションによって大きく異なります。私のアドバイスは次のとおりです。

  • 必要があるとわかっている場合にのみ、このルートをたどってください。(アプリケーションを特定の実装テクノロジに関連付けます。)

  • 関連するデータがまだキャッシュとして使用して管理されていない場合は、アプリケーションへの侵入的な変更に備えてください。

  • BigMemory で優れたパフォーマンスを得るために、キャッシング コードの (再) チューニングに時間を費やす準備をしてください。

  • データ構造が複雑な場合は、それに比例してランタイム オーバーヘッドとチューニング作業が大きくなることが予想されます。

于 2011-05-03T02:19:39.077 に答える