tp://security.it.ray.com/antivirus/extensions.html
http://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]
> Subjec
> 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 unmeasur
> 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 -
> 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
> 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 confidenti
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 com
> 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 acti
>> 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,
> e
> 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 n
> 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 t
> 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
On 20 June 2010 16:01, Caldarale, Charles R wrote:
> 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 with a found flag, and
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 sup
On Jun 20, 2010, at 4:24, "André Warnier" 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. The
basi
On 20/06/2010 10:24, André Warnier wrote:
> Caldarale, Charles R wrote:
>> On Jun 19, 2010, at 18:31, "André Warnier" 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 i
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 res
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
>
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 w
Caldarale, Charles R wrote:
On Jun 19, 2010, at 18:31, "André Warnier" 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
i
On Jun 19, 2010, at 18:31, "André Warnier" 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 stuff to cl
> 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.
Th
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 t
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 v
> 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 th
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 e
> 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, sta
> 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.
> 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
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
wrote:
>
> We run 150+ instances of tomcat on one server. To optimize memo
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 the
30 matches
Mail list logo
