storm-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject 回覆: [Issue] OutOfMemoryError when disable ackers
Date Thu, 03 Jul 2014 02:16:05 GMT
I really not remove anchor ack when I run storm in the unreliable way by setNumAckers to 0.

I think it's simple by changing config to be between reliable and unreliable storm. I'll try
it later. Thank you

----- Reply message -----
寄件者: "Cody A. Ray" <>
收件者: <>
主旨: [Issue] OutOfMemoryError when disable ackers
日期: 週四, 7月 3 日, 2014 年 6:49 上午

My hunch would be that you're anchoring your tuples and without acker tasks these tuple trees
are never destroyed. So all the tuples from each batch are kept in memory until you run out
of memory, i.e., a very, very fast memory leak.

If you disable ackers, you should probably not anchor your tuples either.


On Mon, Jun 30, 2014 at 9:56 PM, <> wrote:

Hi all,
I use storm 0.9.2 now, and do real-time processing by basic storm. It's normal to use in reliable
way. But the speed is extremely slow about 6000 tuples/s. So I try to disable acker feature
by conf.setNumAckers(0). However, this leads to following error:

java.lang.OutOfMemoryError: GC overhead limit exceeded at java.lang.reflect.Method.copy(
at java.lang.reflect.ReflectAccess.copyMethod( at sun.reflect.ReflectionFactory.copyMethod(
at java.lang.Class.copyMethods( at java.lang.Class.getMethods(
at clojure.lang.Reflector.getMethods( at clojure.lang.Reflector.invokeInstanceMethod(
at backtype.storm.daemon.worker$mk_transfer_fn$fn__5748.invoke(worker.clj:128) at backtype.storm.daemon.executor$start_batch_transfer__GT_worker_handler_BANG_$fn__5483.invoke(executor.clj:256)
at backtype.storm.disruptor$clojure_handler$reify__745.onEvent(disruptor..clj:58) at backtype.storm.utils.DisruptorQueue.consumeBatchToCursor(
at backtype.storm.utils.DisruptorQueue.consumeBatchWhenAvailable( at
backtype.storm.disruptor$consume_batch_when_available.invoke(disruptor.clj:80) at backtype.storm.disruptor$consume_loop_STAR_$fn__758.invoke(disruptor.clj:94)
at backtype.storm.util$async_loop$fn__457.invoke(util.clj:431) at

Can anyone tell me why this happens?
Thank you very much.

Best regards,
James Fu

Cody A. Ray, LEED AP
View raw message