Releasing agent memory to OS

Lukas Krejci lkrejci at redhat.com
Mon Sep 15 14:01:45 UTC 2014


Yes, your points are all valid.

I think it all depends on the machine that the agent is deployed on.

As Steven pointed out in another email in this thread, people usually are only 
interested in max heap of the apps so that they can plan in advance on the 
amount of RAM needed on a machine. In that case you don't really need to care 
about how much RAM the agent uses at any given moment - you just know it won't 
ever use more than max heap + max permgen + some margin for native.

I was coming to this from a different angle though. In highly dynamic 
environments where a lot of processes compete for resources, it might be 
beneficial to use as little RAM as possible so that other processes can get 
hold of it. This also might help IMHO in containerized environments (which 
only increase the competition for physical resources). Think OpenShift running 
unteen gears on a single box. While it might hurt the performance of the 
single gear, the overall situation would I think be (ever so slightly) better 
because the memory would be available to the rest of the gears on that box.

But yes, I, too, don't think we should make these a default. Maybe just point 
the settings out in the docs or something. After 8 years of working with Java 
I only discovered these settings a couple of months ago so if there are more 
people as ignorant as me, we might help someone solve their problems ;)

Lukas

On Monday, September 15, 2014 02:18:00 PM Heiko W.Rupp wrote:
> Am 29.08.2014 um 17:57 schrieb Lukas Krejci <lkrejci at redhat.com>:
> > Setting these to 5 (meaning maximum 5% free heap) lowered the total memory
> > usage from 188M to 154M during "quiet" times and to 165M during peak times
> > in the agent lifecycle (peak probably happening during discovery) in the
> > default
> I am not sure if this is a good thing, as the VM probably needs to run much
> more garbage collections as it will first try to keep the working set in
> the heap. The second thing is that requesting and freeing memory from the
> OS is more expensive than object allocations inside the heap.
> 
> I am not opposed to using those parameters to reduce the memory usage,
> but we need to make sure with longer test runs and gc-analysis that this
> does not increase the cpu usage of the agent and/or slow it down.
> 
> It may be better to further reduce the memory usage inside the agent and the
> plugins and let the agent' VM free up the memory when it thinks it is a
> good time to do so.
> 
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list