From: Mark Thomas [mailto:ma...@apache.org]
Subject: Re: Setting the Right Amount of Memory
So what is the impact say (picking some random numbers of the air) if
you have an app that is quite happy with 256MB of heap space but has
1024MB allocated?
Probably unmeasurable, assuming
://security.it.ray.com/news/2007/zipfiles.html
Should you have any questions or difficulty with these instructions, please
contact the Help Desk at 877.844.4712
---
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Subject: RE: Setting the Right Amount of Memory
Let's see if a .java
On 21/06/2010 04:15, Caldarale, Charles R wrote:
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Subject: Re: Setting the Right Amount of Memory
Unreachable (dead) objects are never encountered,
so their number or size does not come into play.
For complete disclosure, I
So what is the impact say (picking some random
numbers of the air) if you have an app that is quite
happy with 256MB of heap space but has 1024MB allocated?
My question exactly!
--
Eric Robinson
Disclaimer - June 21, 2010
This email and any files transmitted with it are confidential
From: Robinson, Eric [mailto:eric.robin...@psmnv.com]
Subject: RE: Setting the Right Amount of Memory
So what is the impact say (picking some random
numbers of the air) if you have an app that is quite
happy with 256MB of heap space but has 1024MB allocated?
My question exactly
Sorry for not responding yet. Busy at what I actually
get paid for, and trying to generate some real numbers
for the question at hand. More later.
No worries, I just want to keep the thread alive until something
definitive comes from it if possible. :-)
--
Eric Robinson
Disclaimer -
Caldarale, Charles R wrote:
On Jun 19, 2010, at 18:31, André Warnier a...@ice-sa.com wrote:
As Mark writes above (and my interpretation of things) :
- a bigger Heap means that the JVM will be able to accumulate more
dead stuff in it,
- when it is needed however, it will take much longer,
Caldarale, Charles R wrote:
(Sent from my iPhone on a ferry in the middle of Lake Michigan.)
Posters to this forum, observe the incredible dedication of some of the
contributors here.
I'm willing to bet that if the ferry was sinking, Chuck would be the last one on board,
making sure there
On 20/06/2010 10:25, André Warnier wrote:
Caldarale, Charles R wrote:
We would need some means of checking though.
Some means of registering a check in, by location? Hmm.
I wonder if anyone's had that idea before... ;)
p
On 20/06/2010 00:30, André Warnier wrote:
Robinson, Eric wrote:
On 17/06/2010 08:59, Robinson, Eric wrote:
If your heap size is right on the edge of your minimum for a Tomcat
instance, you may be doing more GC work than is really needed.
However, if you're satisfied with the response time and
On 20/06/2010 10:24, André Warnier wrote:
Caldarale, Charles R wrote:
On Jun 19, 2010, at 18:31, André Warnier a...@ice-sa.com wrote:
As Mark writes above (and my interpretation of things) :
- a bigger Heap means that the JVM will be able to accumulate more
dead stuff in it,
- when it is
On Jun 20, 2010, at 4:24, André Warnier a...@ice-sa.com wrote:
The time it takes to perform a GC is *not* dependent on the number or
size of dead objects, just on the live ones.
That is counter-intuitive. Pray, why is that ?
All modern GC algorithms are variations of mark-sweep-compact.
On 20.6.2010 14:06, Mark Thomas wrote:
On 20/06/2010 00:30, André Warnier wrote:
Just a note here : 160 X 512 MB = 81 GB.
If each Tomcat's JVM is allowed to use up to 512 MB of Heap, there might
be moments where a lot of JVM's will be using close to that amount.
Unless your system can really
On 20 June 2010 16:01, Caldarale, Charles R chuck.caldar...@unisys.comwrote:
All modern GC algorithms are variations of mark-sweep-compact. The
basic operation consists of following the object reference graph from
a set of known roots (eg, thread stack frames), marking each
discovered object
Having a borderline heap size can, in the worst case, result
in almost continual GC activity, if there is only room to
allocate a minimal number of objects between GC occurrences.
For what it's worth, either this is not the case in our real-world
situation or the effect is negligible. Even
From: Caldarale, Charles R [mailto:chuck.caldar...@unisys.com]
Subject: Re: Setting the Right Amount of Memory
Unreachable (dead) objects are never encountered,
so their number or size does not come into play.
For complete disclosure, I should note that dead objects in the tenured (old
From: Robinson, Eric [mailto:eric.robin...@psmnv.com]
Subject: RE: Setting the Right Amount of Memory
Having a borderline heap size can, in the worst case, result
in almost continual GC activity, if there is only room to
allocate a minimal number of objects between GC occurrences
For what it's worth, either this is not the case in our
real-world situation or the effect is negligible.
Not surprising - you'd have to be very unlucky to be right
at the edge and see a lot of GC activity and be able to
continue running. Usually you'll be over the edge a bit,
From: Robinson, Eric [mailto:eric.robin...@psmnv.com]
Subject: RE: Setting the Right Amount of Memory
What qualifies as a tight heap and what qualifies as a
significant increase?
Both are entirely dependent on what's running inside the JVM. Monitoring the
GC actions will tell you
On 17/06/2010 08:59, Robinson, Eric wrote:
If your heap size is right on the edge of your minimum for a Tomcat
instance, you may be doing more GC work than is really needed.
However, if you're satisfied with the response time and CPU
utilization, you should be ok.
Time to hit the vendor
Robinson, Eric wrote:
On 17/06/2010 08:59, Robinson, Eric wrote:
If your heap size is right on the edge of your minimum for a Tomcat
instance, you may be doing more GC work than is really needed.
However, if you're satisfied with the response time and CPU
utilization, you should be ok.
Time
Just a note here : 160 X 512 MB = 81 GB. If each Tomcat's
JVM Is allowed to use up to 512 MB of Heap, there might be
moments where a lot of JVM's will be using close to that
amount. Unless your system can really support that amount
of real RAM, you may be in for massive swapping.
On Jun 19, 2010, at 18:31, André Warnier a...@ice-sa.com wrote:
As Mark writes above (and my interpretation of things) :
- a bigger Heap means that the JVM will be able to accumulate more
dead stuff in it,
- when it is needed however, it will take much longer, because there
is more
If your heap size is right on the edge of your minimum for a Tomcat
instance, you may be doing more GC work than is really needed.
However, if you're satisfied with the response time and
CPU utilization, you should be ok.
My thoughts exactly. Just wanted to check it with the community.
Just wondering, what tools do you use to manage all the
instances? Also, what do you use to look for the OutOfMemory
in logs? I am looking at Splunk too.
Just shell scripts. We have scripts that...
-- set up a new instance and customize it for a new customer
-- stops,
On 17/06/2010 08:59, Robinson, Eric wrote:
If your heap size is right on the edge of your minimum for a Tomcat
instance, you may be doing more GC work than is really needed.
However, if you're satisfied with the response time and
CPU utilization, you should be ok.
My thoughts exactly.
Time to hit the vendor around the head with the cluebat.
If the app is happy with less heap space then increasing
it is only going to cause problems - mainly that GC when it
happens will take longer and trigger longer pauses. You can
mitigate this with GC config (later VMs may make the
We run 150+ instances of tomcat on one server. To optimize memory
utilization, each tomcat instance is configured with 64MB by default
(export JAVA_OPTS=-ms64M -mx64M). We then watch for
Java.Lang.OutOfmemory errors in the logs. If we see any of these over
time, we allocate additional RAM in
On 6/16/2010 10:42 AM, Robinson, Eric wrote:
We run 150+ instances of tomcat on one server. To optimize memory
utilization, each tomcat instance is configured with 64MB by default
(export JAVA_OPTS=-ms64M -mx64M). We then watch for
Java.Lang.OutOfmemory errors in the logs. If we see any of
Hi Eric,
Just wondering, what tools do you use to manage all the instances?
Also, what do you use to look for the OutOfMemory in logs? I am
looking at Splunk too.
Andrew
On Thu, Jun 17, 2010 at 12:42 AM, Robinson, Eric
eric.robin...@psmnv.com wrote:
We run 150+ instances of tomcat on one
From: Robinson, Eric [mailto:eric.robin...@psmnv.com]
Subject: Setting the Right Amount of Memory
If tomcat is not throwing OutOfMemory errors and system responsiveness
is good, is there really any reason to allocate higher amounts of RAM?
If your heap size is right on the edge of your
31 matches
Mail list logo
