Releasing agent memory to OS
by Lukas Krejci
Hi all,
in the continuing quest to minimize the memory requirements of agent, I've
come across these 2 params in the Java tuning guide [1]:
-XX:MinHeapFreeRatio and
-XX:MaxHeapFreeRatio
These 2 basically define the thresholds of free heap space when the allocation
or freeing of the system memory occurs (more details in the tuning guide [1]).
Setting these thresholds to the same value basically translates to the maximum
free heap (i.e. the maximum amount of allocated memory above the memory
required by the objects) at any given point in time.
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
settings with a smallish inventory (9 servers, 1017 services, 98 metrics per
minute).
Of course, having such "tight" heap slows down memory allocation during peak
times but IMHO our agent should not seek the maximum performance but rather
the lowest possible overhead.
What do you think about introducing these 2 parameters to the agent startup
command?
Lukas
[1] http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html#0.0.0.
%20Total%20Heap|outline
9 years, 7 months
Extract remote interfaces into own module
by Heiko W.Rupp
Hey,
I think it could be good to move all the remote EJB-Interfaces (plus needed
Pojo classes) into a separate maven module and package(*) that would then
form the remote interface that is e.g. used with the cli.
Reasons
- smaller remote interface package
- EJB Beans and server side utilities stay server side and can't accidentally be used
- Easier scoping of what is in the remote interface and what not
- Easier application of e.g. checkstyle rules to only this module
Wdyt?
Heiko
*) Technically for compatibility reasons with the CLI it may be better to move the
non-remote classes into a new package and keep the existing one for the
Remote interfaces.
9 years, 8 months
server itest development
by John Sanda
Working with the server integration tests in the itests-2 module can be really cumbersome. To test some SLSB code that I have written, not only do I have to fully rebuild server/jar, I also have to fully rebuild the ear. Then I can go run my tests. I just pushed a change[1] to the storage_workflow branch that eliminates the need to rebuild the ear. It will be a little while before the storage_workflow branch is ready to be merged. I wanted to point this out in case anyone wants to go ahead cherry pick the commit to master.
[1] https://github.com/rhq-project/rhq/commit/0f0d0ac7c3e88d328483da11816e9e5...
- John
9 years, 8 months
AUTO: David A. Webster is out of the office (returning 08/18/2014)
by David A. Webster
I am out of the office until 08/18/2014.
On Vacation, will be back Monday, August 18.
Note: This is an automated response to your message "Re: Extract remote
interfaces into own module" sent on 8/11/2014 8:21:50 AM.
This is the only notification you will receive while this person is away.
**
This email and any attachments may contain information that is confidential and/or privileged for the sole use of the intended recipient. Any use, review, disclosure, copying, distribution or reliance by others, and any forwarding of this email or its contents, without the express permission of the sender is strictly prohibited by law. If you are not the intended recipient, please contact the sender immediately, delete the e-mail and destroy all copies.
**
9 years, 8 months