Yes, this does help, but I'm learning as I go.
Ok. I'm using jdk1.2. That's the version that installed with JRun 3.0.
I did run the -verbosegc
What I got was GC: Need to expand mark bits to cover 16384 bytes
I have no idea really what this means? Is this good or bad that I am getting this
message.
I also ran the -Xms and got this message:
Initial heapsize is too small. 262144 bytes required. Could not create the java
virtual machine.
I then ran -Xmx and got this message
Incompatible initial and maximum heap sizes. Minimum is 1048576 bytes, maximum 0.
Initial must be less than or equal to maximum.
The default initial and maximum are 1048576 bytes and 67108864 bytes.
Could not create the java vitual machine.
This does not look good. What should I do, expand the maximum heap size in
global.properties?
Thanks for any help in deciphering all this information.
Also
On Friday, September 07, 2001 5:26 AM, Mullee John - ZGI
[SMTP:[EMAIL PROTECTED]] wrote:
> >I'm still running JRun 3.0 on NT sp5 IIS 4.0 and I do reboot the web server
>
> >automatically nightly because I ran into problems with IIS before.
> >javax.servlet.ServletException: null
> >java.lang.OutOfMemoryError
> > at com.cariboulake.jsql.JSQLDriver.connect(JSQLDriver.java,
>
> You MUST fix the leak; nothing you can possibly do will remove that
> necessity.
>
> In the meantime, all you can do is lengthen the time before the system runs
> out of memory.
> NT manages it's RAM rather inefficiently, and can be accelerated with
> something like
> SuperCacheNT <"http://sunbelt.ons.co.za/#PM";>.
>
> JRun uses the Java runtime, java.exe, which has it's own idea as to how to
> use memory.
>
> This is controlled via command-line parameters when starting java.exe
> java.exe is started by JRun for each Server (i.e. default-server has it's
> own java instance).
> The way in which java.exe is started is specified by parameters in
> JRUN\lib\global.properties,
> which provides defaults for all servers.
> Servers' configurations are in JRUN\servers\{server-name}\local.properties -
> local.properties can
> override the gloabl defaults if required.
> Two thing get specified in the properties files:
> a) which version of java.exe to run
> b) what parameters to give it.
> The parameters available to your java.exe depends on which one it is; if you
> use
> Sun's JDK 1.3 java.exe, for example, the options are:
> C:\jdk1.3\bin\java.exe
> Usage: java [-options] class [args...] (to execute a class)
> or java -jar [-options] jarfile [args...] (to execute a jar
> file)
> where options include:
> -cp -classpath <directories and zip/jar files separated by ;>
> set search path for application classes and resources
> -D<name>=<value> set a system property
> -verbose[:class|gc|jni]
> enable verbose output
> -version print product version and exit
> -showversion print product version and continue
> -? -help print this help message
> -X print help on non-standard options
> C:\jdk1.3\bin\java.exe -X
> -Xmixed mixed mode execution (default)
> -Xint interpreted mode execution only
> -Xbootclasspath:<directories and zip/jar files separated by ;>
> set search path for bootstrap classes and resources
> -Xbootclasspath/a:<directories and zip/jar files separated by ;>
> append to end of bootstrap class path
> -Xbootclasspath/p:<directories and zip/jar files separated by ;>
> prepend in front of bootstrap class path
> -Xnoclassgc disable class garbage collection
> -Xincgc enable incremental garbage collection
> -Xms<size> set initial Java heap size
> -Xmx<size> set maximum Java heap size
> -Xprof output cpu profiling data
> -Xrunhprof[:help]|[:<option>=<value>, ...] perform JVMPI heap, cpu,
> or monitor profiling
> -Xdebug enable remote debugging
> The -X options are non-standard and subject to change without notice.
>
> So you could set, in global.properties, a line like this:
>
> ########################################################################
> ## Java VM settings
> ########################################################################
> java.exe=C:\\PROGRA~1\\JavaSoft\\JRE\\1.3\\bin\\javaw.exe
> java.args.debug=-classic -Xnoagent -Xdebug
> -Xrunjdwp:transport=dt_socket,address=53006
> # extra virtual machine args (256MB min heap size, 1GB max heap size)
> user.javaargs=-Xincgc -Xnoclassgc -verbosegc -verboseclass -Xms268435456
> -Xmx1073741824
>
> When I use these parameters to run some java on the command-line I see this:
>
> D:\temp>java -Xincgc -Xnoclassgc -verbosegc -verboseclass -Xms268435456
> -Xmx1073741824 ParameterTester
> [GC 511K->237K(768K), 0.0114945 secs]
> [GC 749K->376K(960K), 0.0124172 secs]
> 2001-09-07 11:08:47,718 ParameterTester ERROR : () params =
> {item=[Ljava.lang.String;
>
> the lines staring with "[GC" are messages from the garbage-collector.
>
> Limiting the heap-size should mean you only have to restart jrun, not the
> whole machine.
>
> Be warned that the more objects you have, and/or the bigger the heap, then
> the longer the
> garbage-collector will take to check for unused objects to delete.
>
> If the heap is getting too big and slows down the GC, I would look at ways
> of storing
> info into a database, and breaking up the app into parts which could be run
> in seperate
> servers (i.e. jrun/servers/default, jrun/servers/my_other_1, ...), ideally
> on a multi-CPU
> machine or even seperate machines.
>
> hope this helps
>
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Your ad could be here. Monies from ads go to support these lists and provide more
resources for the community. http://www.fusionauthority.com/ads.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
