Ok, so if I set to 512M it isn't that effective?  Would this be better
in a 2xproc 512M heap environment:
ConcurrentGC with ParNewGC (ParNewGC on Multi-CPU machines):
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> Sent: Monday, August 04, 2003 1:03 PM
> To: Tomcat Users List
> Subject: RE: JVM tuning
> 
> 
> Isnt the adaptive sizing only relevant to much larger memory 
> configurations (Im running this JVM with a max heap of 1-1.5Gb?
> Pete
> 
> 
> 
> 
> 
> "Angus Mezick" <[EMAIL PROTECTED]>
> 04/08/2003 17:51
> Please respond to "Tomcat Users List"
>  
>         To:     "Tomcat Users List" <[EMAIL PROTECTED]>
>         cc: 
>         Subject:        RE: JVM tuning
> 
> 
> Wouldn't AdaptiveSizePolicy help? (saves you the work of Java 
> Heap usage
> analyzing :-) :
> 
> I use this on my 2x proc machine.
> 
> -XX:UseParallelGC -XX:+UseAdaptiveSizePolicy
> 
> > -----Original Message-----
> > From: [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED] 
> > Sent: Monday, August 04, 2003 9:55 AM
> > To: Tomcat Users List
> > Subject: RE: JVM tuning
> > 
> > 
> > Ah sorry I should really have said that I was focusing 
> > specifically on 
> > memory managment; general performance tuning is a completely 
> > different 
> > matter in which I do agree with you!  On the memory front 
> > however I would 
> > stand by the fact that most tomcat webapps (big or small) 
> > would benefit 
> > from a change in the default JVM config.
> > 
> > Anyway, have sorted out my problem now (by doing just that as 
> > well as a GC 
> > change) and performance is 10x better!
> > 
> > cheers
> > Pete
> > 
> > 
> > 
> > 
> > 
> > "Shapira, Yoav" <[EMAIL PROTECTED]>
> > 04/08/2003 14:45
> > Please respond to "Tomcat Users List"
> > 
> >         To:     "Tomcat Users List" <[EMAIL PROTECTED]>
> >         cc: 
> >         Subject:        RE: JVM tuning
> > 
> > 
> > 
> > Howdy,
> > 
> > >Well not really; we know that we are running Tomcat, a web 
> container
> > which
> > >has its own (fixed) characteristics.  It is a server side 
> > app which is
> > >processing non state based transactions which are thus 
> highly like to
> > >involve a lot of objects being created and destroyed 
> without too many
> > >hanging around for long;  the details of the webapp, unless it is
> > highly
> > >unusual, are likely not to matter particularly.  This is a rule of
> > thumb
> > >not an exact science and the vast majority of people who run Tomcat
> > would
> > >benefit from running in such a configuration (or playing 
> > with it to see
> > >what the effects were) 
> > 
> > I disagree ;)
> > 
> > Every time I've tuned a webapp for pay, both transactional 
> > and not, both
> > full J2EE and "just" servlets/JSPs, the above has been false.  The
> > webapp's specific implementation matters far more (typically 
> > 3-4 orders
> > of magnitude) than the container implementation, especially 
> > for a mature
> > container which has been tuned repetitively and carefully over time.
> > It's precisely because of this, and because as you say performance
> > tuning is not a science, that a rule of thumb is as likely to 
> > hurt as it
> > is to help if blindly applied.
> > 
> > > read Sun's own tuning documentation and you will
> > >see the default settings are not said to be suitable for 
> the majority
> > of
> > >server apps.
> > 
> > I appreciate the pointer - I used to help write them ;)
> > 
> > Good luck, however, as it's always YMMV with these things.
> > 
> > Yoav Shapira
> > 
> > 
> > 
> > This e-mail, including any attachments, is a confidential business 
> > communication, and may contain information that is confidential, 
> > proprietary and/or privileged.  This e-mail is intended 
> only for the 
> > individual(s) to whom it is addressed, and may not be 
> saved, copied, 
> > printed, disclosed or used by anyone else.  If you are not the(an) 
> > intended recipient, please immediately delete this e-mail from your 
> > computer system and notify the sender.  Thank you.
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to