You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@storm.apache.org by "Jiahong Li (JIRA)" <ji...@apache.org> on 2014/06/05 13:58:02 UTC
[jira] [Updated] (STORM-339) serere memory leak to OOM
[ https://issues.apache.org/jira/browse/STORM-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jiahong Li updated STORM-339:
-----------------------------
Description:
Without any ackers enabled, fast component will continuously leak memory and causing OOM problems when target component is slow. The OOM problem can be reproduced by running this fast-slow-topology
https://github.com/Gvain/storm-perf-test/tree/fast-slow-topology
with command:
storm jar storm_perf_test-1.0.0-SNAPSHOT-jar-with-dependencies.jar com.yahoo.storm.perftest.Main --spout 1 --bolt 1 --workers 2 --testTime 600 --messageSize 6400
And the worker childopts with -Xms2g -Xmx2g -Xmn512m ...
At the same time, the executed count of target component is far behind from the emitted count of source component.
I guess it could be that netty client is buffering too much messages in its mesage_queue as target component sends back OK/Failure Response too slowly.
was:
Without any ackers enabled, under heavy throughput, workers will continuously leak memory and causing OOM problems.
At the same time, the executed count of target component is far behind from the emitted count of source component.
I guess it could be that netty client is buffering too much messages in its mesage_queue as target component sends back OK/Failure Response too slowly.
> serere memory leak to OOM
> -------------------------
>
> Key: STORM-339
> URL: https://issues.apache.org/jira/browse/STORM-339
> Project: Apache Storm (Incubating)
> Issue Type: Bug
> Affects Versions: 0.9.2-incubating
> Reporter: Jiahong Li
> Priority: Critical
>
> Without any ackers enabled, fast component will continuously leak memory and causing OOM problems when target component is slow. The OOM problem can be reproduced by running this fast-slow-topology
> https://github.com/Gvain/storm-perf-test/tree/fast-slow-topology
> with command:
> storm jar storm_perf_test-1.0.0-SNAPSHOT-jar-with-dependencies.jar com.yahoo.storm.perftest.Main --spout 1 --bolt 1 --workers 2 --testTime 600 --messageSize 6400
> And the worker childopts with -Xms2g -Xmx2g -Xmn512m ...
> At the same time, the executed count of target component is far behind from the emitted count of source component.
> I guess it could be that netty client is buffering too much messages in its mesage_queue as target component sends back OK/Failure Response too slowly.
--
This message was sent by Atlassian JIRA
(v6.2#6252)