2017-08-06 15 views
0

1分あたり100kパッケージを処理するJavaアプリケーションがあります。パッケージには、ユーザー操作の詳細とユーザー操作の1つが含まれます。操作には3〜14個のパッケージがあります。受信したすべてのパッケージには操作のための一意のデータが含まれていますが、残念ながら操作にはIDはありません。そのため、ユーザーIDと操作日を使用して、同じ操作に属するパッケージをマージしています。 15分以内にユーザー操作のパッケージをすべて受け取ることが保証されています。したがって、永続化する前にすべてのパッケージをマージするには、受信したすべてのパッケージをHazelcastにキャッシュし、OPSTARTパッケージまたはOPENDパッケージを受け取ったときにパッケージを挿入します。パッケージの有効期限は20分です。しかし、1時間程度実行した後、Hazelcastのヒープスペースは70%を超えます。ヘーゼルキャストメモリ不足

c.h.internal.diagnostics.HealthMonitor : [192.168.2.42]:5701 [dev] [3.7.5] processors=4, physical.memory.total=15.7G, physical.memory.free=6.1G, swap.space.total=2.0G, swap.space.free=2.0G, heap.memory.used=3.1G, heap.memory.free=267.1M, heap.memory.total=3.3G, heap.memory.max=3.5G, heap.memory.used/total=92.15%, heap.memory.used/max=88.02%, minor.gc.count=71, minor.gc.time=4628ms, major.gc.count=10, major.gc.time=7186ms, load.process=0.00%, load.system=0.01%, load.systemAverage=0.00%, thread.count=502, thread.peakCount=502, cluster.timeDiff=-121091, event.q.size=0, executor.q.async.size=0, executor.q.client.size=0, executor.q.query.size=0, executor.q.scheduled.size=0, executor.q.io.size=0, executor.q.system.size=0, executor.q.operations.size=0, executor.q.priorityOperation.size=0, operations.completed.count=4722977, executor.q.mapLoad.size=0, executor.q.mapLoadAllKeys.size=0, executor.q.cluster.size=0, executor.q.response.size=0, operations.running.count=0, operations.pending.invocations.percentage=0.00%, operations.pending.invocations.count=50, proxy.count=0, clientEndpoint.count=0, connection.active.count=1, client.connection.count=0, connection.count=1 

約1時間30分後に、呼び出しがタイムアウトになります。

c.h.s.i.o.impl.InvocationMonitor   : [192.168.2.42]:5701 [dev] [3.7.5] Invocations:50 timeouts:0 backup-timeouts:1 

開始から2〜3時間後、Hazelcastはメモリ不足例外をスローし、デプロイメントは終了します。

キャッシュされたデータには、4GBのメモリで十分です。 Hazelcastがメモリ不足例外をスローする原因を見つけることができませんでした。理由は何でしょうか?問題を理解するために何ができますか?

+0

4GBで十分であると言うなら、どのように必要性を計算しましたか?あなたはまだ頭部のダンプを見ましたか? – noctarius

+0

"期限切れ"プロセスがパッケージを払拭していないようです。それ、または他の種類のメモリリーク。 – rghome

答えて

1

OOMEの原因を特定する最善の方法は、ヒープダンプを作成して解析し、メモリがどのように保持されているかを確認することです。おそらく、膨大な数のバイト配列になるでしょう。これらのバイト配列への参照をチェックし、それらを集約すると(jprofilerはこれをサポートしています)、メモリを保持するクラスの連鎖を決定するのは非常に簡単です。