-
Notifications
You must be signed in to change notification settings - Fork 814
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
High CPU consumption with JMX errors #313
Comments
@remh have you seen this before? CPU seems busier than it should be, on top of not getting the data. |
The cpu must be rising because the jmx connection is not working. So at each collection the agent spawns a new jmx connector process, launching the jvm which may be cpu consuming. What's happening when we manually launch jmx connector ? |
Independently from knowing why the connection doesn't work, we need to On Sun, Dec 23, 2012 at 11:29 AM, Remi Hakim notifications@github.comwrote:
|
An easy-ish way to limit our cpu is to nice the process when we run it so that our cpu usage gets deprioritized. |
Yep, that's a start. On Fri, Dec 28, 2012 at 4:26 PM, Carlo Cabanilla
|
Ok so here the things I did:
Performances are ok but not great, the jmx connector uses a mean value of 2% cpu on my machine, with high peak when performing the dump. Collector is ok (less than 0.5 %) In the overall, it will fix the problem encountered. I used ab to apply heavy load to a tomcat instance and it seems to be working as expected, although from time to time the jmx connection breaks without an obvious reason, but the improved failure handling will relaunch the connection at the next collection. |
How many concurrent connections did you use with |
200, I couldn't get more |
Worth spawning a big ec2 box to crank that number up. 5000 is a good On Monday, January 7, 2013, Remi Hakim wrote:
|
good idea. doing it |
JMXFetch is going to be way more efficient. |
JMXFetch is way more efficient. |
from the collector log
The text was updated successfully, but these errors were encountered: