Ask Your Question
0

Controller uses 100% cpu without anything to do

asked 2014-12-15 06:30:56 -0700

Lorunification gravatar image

updated 2014-12-15 07:02:30 -0700

Hello everyone,

As soon as i start my controller (hydrogen release) it consumes 100% cpu even though there is no traffic to handle at all. I already tried to stop some modules that may possibly cause this (like the one i am developing) but i did not find anything yet. I thought this might help as i think it is some kind of infinit-loop in one of the modules or something like that.

Did anyone else experience this issue and knows how to solve this?

Following is a list of installed modules i got from the osgi console:

osgi> ss
"Framework is launched."


id  State       Bundle
0   ACTIVE      org.eclipse.osgi_3.8.1.v20120830-144521
1   ACTIVE      org.apache.felix.fileinstall_3.1.6
2   ACTIVE      org.eclipse.jdt.core.compiler.batch_3.8.0.I20120518-2145
3   ACTIVE      org.eclipse.equinox.ds_1.4.0.v20120522-1841
4   ACTIVE      org.eclipse.equinox.util_1.0.400.v20120522-2049
5   ACTIVE      org.eclipse.osgi.services_3.3.100.v20120522-1822
6   ACTIVE      org.eclipse.equinox.console_1.0.0.v20120522-1841
7   ACTIVE      slf4j.api_1.7.2
8   ACTIVE      ch.qos.logback.classic_1.0.9
9   ACTIVE      ch.qos.logback.core_1.0.9
10  ACTIVE      com.sun.jersey.core_1.17.0
11  ACTIVE      com.sun.jersey.jersey-server_1.17.0
12  ACTIVE      jcl.over.slf4j_1.7.2
13  ACTIVE      org.sdnhub.odl.protocol_plugins.openflow13_0.1.0.SNAPSHOT
14  ACTIVE      org.opendaylight.controller.topology.web_0.4.1
15  ACTIVE      com.google.guava_14.0.1
16  ACTIVE      org.opendaylight.controller.arphandler_0.5.1
17  ACTIVE      org.opendaylight.controller.flows.web_0.4.1
18  ACTIVE      org.opendaylight.controller.forwardingrulesmanager.implementation_0.4.1
19  ACTIVE      org.opendaylight.controller.thirdparty.com.sun.jersey.jersey-servlet_1.17.0
20  ACTIVE      org.apache.commons.lang3_3.1.0
21  ACTIVE      org.opendaylight.controller.configuration_0.4.1
22  ACTIVE      org.springframework.beans_3.1.3.RELEASE
23  ACTIVE      org.eclipse.virgo.util.osgi_3.6.0.RELEASE
24  ACTIVE      org.springframework.transaction_3.1.3.RELEASE
25  ACTIVE      org.opendaylight.controller.switchmanager.implementation_0.4.1
26  ACTIVE      org.springframework.web.servlet_3.1.3.RELEASE
27  ACTIVE      org.opendaylight.controller.usermanager_0.4.1
28  ACTIVE      org.opendaylight.controller.containermanager.implementation_0.5.1
29  ACTIVE      com.google.gson_2.2.4
30  ACTIVE      controllermanager.northbound_0.0.1
31  ACTIVE      javax.servlet.jsp.jstl_1.2.0.v201105211821
32  ACTIVE      org.apache.el_7.0.32.v201211081135
33  ACTIVE      org.springframework.security.taglibs_3.1.3.RELEASE
34  ACTIVE      org.eclipse.gemini.web.tomcat_2.2.0.RELEASE
35  ACTIVE      org.opendaylight.controller.statisticsmanager.implementation_0.4.1
36  ACTIVE      org.springframework.core_3.1.3.RELEASE
37  ACTIVE      javax.ejb_3.1.1.v201204261316
38  ACTIVE      org.opendaylight.controller.commons.northbound_0.4.1
39  RESOLVED    org.apache.tomcat.util_7.0.32.v201211201952
                Master=64
40  ACTIVE      com.fasterxml.jackson.core.jackson-annotations_2.3.0
41  RESOLVED    org.opendaylight.controller.security_0.4.1
                Master=64
42  ACTIVE      org.opendaylight.controller.connectionmanager.northbound_0.1.1
43  <<LAZY>>    org.eclipse.equinox.http.servlet_1.0.0.v20070606
44  ACTIVE      org.opendaylight.controller.hosttracker_0.5.1
45  ACTIVE      org.opendaylight.controller.statisticsmanager_0 ...
(more)
edit retag flag offensive close merge delete

Comments

Yes I also see this. Sometimes, ODL (Helium-SR2) seems to get really busy using over 350% CPU with > 190 threads. This often goes on for > 10 mins. Most recently, I eventually got: "java.lang.OutOfMemoryError: GC overhead limit exceeded at at akka.dispatch.AbstractNodeQueue.<init>"

avoellmy ( 2015-02-02 13:46:18 -0700 )edit

2 answers

Sort by ยป oldest newest most voted
0

answered 2014-12-15 06:58:33 -0700

It takes a while for ODL to get up and running after you start it. Its CPU usage should calm down to a few % after <90 seconds. This is why we have to wait a bit after starting ODL in perf tests.

I lead a lot of the ODL perf testing and I've never seen ODL peg like this except when first starting and when it's being hammered with flows. If it doesn't calm down like I described, you should file a bug.

Also, please use Helium SR1 if at all possible. We'd prefer not to support Hydrogen.

edit flag offensive delete publish link more

Comments

I just realized, that the cpu load rises once i start mininet and stays high even after mininet gets closed. Every time i restart mininet the cpu load rises around 50% and stays like this. At the osgi console i get SwitchHandler-2 at fist start. Second start SwitchHandler-4 and so on.

Lorunification ( 2014-12-15 07:06:56 -0700 )edit

That's still with Hydrogen I assume? Again, it'd be more realistic to try Helium SR1 and/or master.

dfarrell07 ( 2014-12-15 07:36:02 -0700 )edit

I would use SR1 but unfortunately i am not able to use my self-written module (that was created with hydrogen) with helium since i don't know, and neither do i find infos on, what to do with my old project to make it work.

Lorunification ( 2014-12-15 10:28:52 -0700 )edit

^^Might be worth asking that in another question.

dfarrell07 ( 2014-12-15 11:55:46 -0700 )edit
0

answered 2014-12-17 02:55:35 -0700

pskhanapur gravatar image

It could be a that some L2 packets are looping, happens if you have loops in your topology. Try comparing with loopless topolgies.

edit flag offensive delete publish link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

[hide preview]

Question Tools

Follow
2 followers

Stats

Asked: 2014-12-15 06:30:56 -0700

Seen: 455 times

Last updated: Dec 17 '14