mx is limiting the heap of a java process.
In other words:
It limits the total heap for one tomcat instance.
The total memory can be much higher:
- stacksize per thread
Some vm's let you set these values (-Xss).
If you have some hundred of threads that can make up some memory.
- static memory (like string constants, the code, ...)
That pretty much defined at compile time.
- and may be further sorts of memories that depend on
the vendor and version of the jdk.
Regarding your config:
You can try to play with the combination of
maxProcessors
connectionTimeout
acceptCount
I'm not shure how the accepted but not processed
request are handled (wether they are queued in one
thread, or if each has it's own thread)
There isn't much more you can change in tomcat.
The best recommendation I have is to find out where
the memory comes from and either to cure the cause or
find out that you have to live with that memory usage
and spend more memory.
> -----Original Message-----
> From: Cristopher Daniluk [mailto:[EMAIL PROTECTED]
> Sent: Thursday, September 11, 2003 5:33 PM
> To: [EMAIL PROTECTED]
> Subject: Tomcat cluster tuning
>
>
>
> What is the -Xmx option limiting? Threads? Defined services? Instances
> of Tomcat?
>
> I would've thought that it would limit the entire tomcat instance, but
> we have been far exceeding the 768mb limit we set.
>
>
> <Connector
> className="org.apache.coyote.tomcat4.CoyoteConnector"
> port="8009" minProcessors="5" maxProcessors="100"
> enableLookups="true" redirectPort="8443"
> acceptCount="100" debug="0" connectionTimeout="-1"
>
> protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"
> />
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
