----------------------------------------------------------------
BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
WHEN YOU POST, include all relevant version numbers, log files,
and configuration files.  Don't make us guess your problem!!!
----------------------------------------------------------------

Thanks Cameron for all the valuable info.
I already  have it set to -Xms32m -Xmx64m.
Is it best to keep the min and max the same?

I will investigate several of your suggestions.
Only one I can't is the fact that I must run under jdk1.1.8
for my applet graphics code.

Heard anything about Tomcat?
Is it the next logical step or still in it's teething stages?

Don

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Riley,
> Cameron
> Sent: Monday, July 31, 2000 8:07 AM
> To: 'Java Apache Users'
> Subject: RE: JVM and 50% CPU usage
>
>
> ----------------------------------------------------------------
> BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
> WHEN YOU POST, include all relevant version numbers, log files,
> and configuration files.  Don't make us guess your problem!!!
> ----------------------------------------------------------------
>
>
> Don,
>
> Sorry for the late reply;
>
> >I do not understand how the garbage collection would make the
> >JVM CPU usage jump to 50%.
>
> An application I have running atop of JServ uses approx a 17 meg stack and
> the CPU breaths between 5% and 13% at most loads on a 500 Mhz single
> processor machine. There was an article a few months ago at IBM/Alphaworks
> on setting the JVM's max and minimum stack memory settings. If you set the
> stack memory at 128 meg and your application only uses 20, the
> stack memory
> will fill out until finally all the 108 meg not used by the app is GC'ed.
> Alternatively if you set the stack memory at 16 Meg and your app uses 50
> Meg, the JVM will be bogged down by continually sweeping for
> garbage to free
> up the stack. You can set this in jserv.properties under
> wrapper.bin.parameters. ie;
>
>  wrapper.bin.parameters=-Xms64m -Xmx64m
>
> will set the JVM memory stack to be 64 Mb max and min.
>
> >Could JServ trigger the JVM to jump like that.
> >If so how? How could I monitor this to see what causes this.
>
> I doubt it, I have never seen JServ do that on it's own. Have a look that
> your application isnt suddenly generating several thousand
> classes and then
> de-referencing them. Also have a look at how your db pool is setup, I have
> noticed that when the db pool instantiates it asks for a bunch of
> resources.
> If you are continually generating new db connections, try using a
> singleton
> based connection pool. That will help as well.
>
> >The logs have basically been useless. Do the JServ logs
> >reflect any messages coming from the JVM?
>
> Yes, but you have to tell JServ that you want to listen to that sort of
> information first. You have to set the JVM settings in
> wrapper.bin.parameters in jserv.properties. You can set the
> startup switches
> for the JVM from here.
>
> >Are there monitoring tools for NT to determine how this happens?
>
> If you wish to have a look at how when the GC is being called by
> the JVM add
> to your JServ config in jserv.properties;
>
>  wrapper.bin.parameters=-verbose:gc
>
> IIRC it will appear in your jserv.log file. NT differs greatly between
> JVM's, I would try out several differant JVM's on NT and settle
> on the most
> stable, all of them from 1.2.1 onwards seem to be fast enough but
> stability
> differs depending on the application running on top of them. Between 1.2.1
> and 1.2.2 there was a change in how the prepared statement
> handled closing a
> resultset with ODBC so watch out for that memory leak. I would
> also test the
> JDK JVM's against the JRE JVM's. I dont know why but with NT the JDK JVM's
> have appeared to be more robust but that is just my impression.
>
>
>
>
>
> Cameron Riley
>
>
>
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe:        [EMAIL PROTECTED]
> To unsubscribe:      [EMAIL PROTECTED]
> Search Archives:
> <http://www.mail-archive.com/java-apache-users%40list.working-dogs.com/>
> Problems?:           [EMAIL PROTECTED]
>



--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Search Archives: 
<http://www.mail-archive.com/java-apache-users%40list.working-dogs.com/>
Problems?:           [EMAIL PROTECTED]

Reply via email to