[OPNFLWPLUG-119] cbench in throughput mode causes the controller to run out of memory Created: 22/Apr/14  Updated: 27/Sep/21  Resolved: 01/Aug/14

Status: Resolved
Project: OpenFlowPlugin
Component/s: General
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Jan Medved Assignee: Michal Rehak
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Mac OS
Platform: Macintosh


Issue Links:
Blocks
is blocked by CONTROLLER-435 unbound queue Resolved
is blocked by OPNFLWPLUG-150 Openflow Plugin piggybacks threads no... Resolved
is blocked by OPNFLWPLUG-174 Implement ingress back pressure based... Resolved
External issue ID: 803

 Description   

When cbench is run with parameters as show below, the OldGen space takes all available memory and nothing is left for the heap. The parameters are:

> cbench -c 192.168.162.1 -p 6633 -m 10000 -l 13 -w 3 -M 100000 -t -i 50 -I 5 -s 10

The controller is run in the RPC loopback mode. From the OSGI console, type:

> dropAllPacketsRpc on

Also make sure that the Simple Forwarding and Arp Handler bundles are deactivated (deleted from the plugins folder) before running the test.

It was observed that after about 6 iterations of a cbench run the flow setup rate decreased considerably. The attached Yourkit profiler showed that the OldGen space consumed all available memory and nothing was left for heap. Eventually, the controller stopped functioning.

Note that this bug is not happening when cbench is run in latency mode, where there is a backpressure (i.e. cbench does not send out a new packet in until a response from the controller is received). This means that there is probably a queue somewhere that fills up and is never freed.



 Comments   
Comment by Michal Rehak [ 08/May/14 ]

https://git.opendaylight.org/gerrit/#/c/6738/
merged - fixed deadlock for addFlow and updateFlow

Comment by Michal Rehak [ 01/Aug/14 ]

bug-956 resolved

Generated at Wed Feb 07 20:31:37 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.