Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
Sluggish Mango instance
-
I've been messing around with my PC based Mango today and at some point it became very sluggish (menus are slow to load, operations which normally take a second seem to drag on for example importing CSV). Just wondering if there is a way to diagnose what is going on with the instance?
-
Woooow 99.9% CPU!
-
There's a very high probability the garbage collector is thrashing. That's usually what's happening when the CPU pegs and things slow way down. This means you may have gotten close to using all your memory for something. Do you know what caused it?
-
It started earlier today when I was screwing with all those scripts. At the same time I noticed that I was getting a ton of errors from the meta points about not being able to find the value. I cleared all the alarms, restarted mango, and changed the way I'm doing all those scripts (now just running every 15 mins and checking to see if my source points have newer data than my META points).
Seems much much happier right now.
For future, is there a way I can track down what thread inside Mango is causing something like that?
-
You can't track it down at the thread level, since memory is shared between threads. If it'll respond, /rest/v1/threads?stackDepth=40&asFile=true can be interesting for seeing if you have any long running threads (which are often to blame, and the GC thread will almost always show up as the main consumer of time in these situations (but 2nd and 3rd place can be interesting).
The other piece of information that can elucidate memory chokeholds is
Java/bin/jmap -histo $(pidof java)as typically one type of object has run away will all the memory, and you can see which type of object that is.From that and the stack traces, one can often sleuth it out.
Sometimes its easier to disable things, then re-enable them until the meltdown occurs in terms of hunting where the memory has gone, which doesn't require any programming skills.
-
I ended up upgrading my EC2 instance one level higher and then gave the JVM a ton of memory, system has been stable and very snappy since.
