Re: Best practices to set heap memory

[Mark Thomas]

On 21/04/2025 17:49, Christopher Schultz wrote:

Ramesh,

On 4/21/25 1:06 AM, Ramesh B R wrote:

How to decide on heap memory size?
is it 25% of total memory? or 50% total memory?

What is the ideal value (in %) for heap memory ?


Only you can answer that question about your own application environment.

The percentage of total memory is completely irrelevant if you ask me. 
Presumably, you have a server so that you can serve requests for the 
application. If you have other services on the same server, then you 
will have to balance the memory requirements of each service against the 
others.


If it's a single-service server then I would dedicate ALL of the 
available memory to that service. That doesn't mean 100% (or 90% or 80%) 
dedicated to heap memory, as there is a lot of memory usage in Java that 
is not accounted for by the heap.


I would start from the other end: what does your application actually 
need under typical (and worst-case) load scenarios. If your application 
doesn't need a lot of heap space, then I wouldn't bother paying for it, 
whether you are buying physical RAM chips or renting them from a cloud 
provider.


If you have other requirements, such as minimal application pauses, or 
transaction times where GC could impact your ability to meet certain 
goals, then your heap space may be of critical concern. Mot modern GCs 
benefit from more memory. Remember that the "cost" of the garbage 
collector is related to the number of things that need to stay in memory 
rather than the number of things that need to be collected. So running 
GC on a large heap is no more expensive than it is running on a small 
heap, assuming the same load scenarios.


Big +1 to all of the above.

A long time ago I attended some talks of Java GC, memory usage and 
performance. A very quick summary is:


- Memory footprint, throughput and latency. Pick any two at the expense 
of the third.


- Look at your application's steady state memory usage. It should be a 
sawtooth. Take the minimum value of the sawtooth and multiply it by 5. 
Allocate that much memory to the Java heap. That should give GC the room 
it needs to operate efficiently.


That exact multiplier may not apply to more modern GC algorithms.

Every application is different. You'll need to do some testing to find 
out what works best for your application.


Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: State Synchronization without Serialization - Possible?

[Mark Thomas]

On 22/04/2025 01:09, Eric Robinson wrote:

Hi all,

We want to implement tomcat clustering, but we cannot because the application 
is commercial, and it does not support serializable objects. In short, it does 
not work with tomcat's standard clustering technology. Is there any known 
reliable way to share session state, cookies, etc., between tomcat instances, 
without using tomcat's native clustering facilities, and without having access 
to the application code? I know it's probably a dumb question, but I must ask.


What are you trying to achieve?

Sharing the load between multiple servers?

Fail over (with data loss) if one server fails?

Fail over without data loss if one server fails?

The first two can be done. The third would require some tool that could 
reliably serialize any Java object regardless of whether it was 
serializable. I haven't come across such a tool but that doesn't mean 
one doesn't exist.


Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Best practices to set heap memory

[Gregg, John E.]

Your heap is big enough when your GC performance is good enough.

Garbage collectors have improved tremendously over the years.  My rule of thumb 
used to be that I wanted the app to spend less than 1% of time in GC, but 
that’s actually easy to achieve these days as long as your heap is big enough.  
I can’t tell you whether it needs to be 1GB or 10GB.  You’ll have to 
experiment.  It’s very common to have GC overhead well below 1% now.  (That’s 
600ms per 6ms.)


From: Mark Thomas 
Sent: Tuesday, April 22, 2025 2:38 AM
To: users@tomcat.apache.org
Subject: Re: Best practices to set heap memory

​͏​On 21/04/2025 17: 49, Christopher Schultz wrote: > Ramesh, > > On 4/21/25 1: 
06 AM, Ramesh B R wrote: >> How to decide on heap memory size? >> is it 25% of 
total memory? or 50% total memory? >> >> What is the ideal 
ZjQcmQRYFpfptPreheaderEnd


On 21/04/2025 17:49, Christopher Schultz wrote:

> Ramesh,

>

> On 4/21/25 1:06 AM, Ramesh B R wrote:

>> How to decide on heap memory size?

>> is it 25% of total memory? or 50% total memory?

>>

>> What is the ideal value (in %) for heap memory ?

>

> Only you can answer that question about your own application environment.

>

> The percentage of total memory is completely irrelevant if you ask me.

> Presumably, you have a server so that you can serve requests for the

> application. If you have other services on the same server, then you

> will have to balance the memory requirements of each service against the

> others.

>

> If it's a single-service server then I would dedicate ALL of the

> available memory to that service. That doesn't mean 100% (or 90% or 80%)

> dedicated to heap memory, as there is a lot of memory usage in Java that

> is not accounted for by the heap.

>

> I would start from the other end: what does your application actually

> need under typical (and worst-case) load scenarios. If your application

> doesn't need a lot of heap space, then I wouldn't bother paying for it,

> whether you are buying physical RAM chips or renting them from a cloud

> provider.

>

> If you have other requirements, such as minimal application pauses, or

> transaction times where GC could impact your ability to meet certain

> goals, then your heap space may be of critical concern. Mot modern GCs

> benefit from more memory. Remember that the "cost" of the garbage

> collector is related to the number of things that need to stay in memory

> rather than the number of things that need to be collected. So running

> GC on a large heap is no more expensive than it is running on a small

> heap, assuming the same load scenarios.



Big +1 to all of the above.



A long time ago I attended some talks of Java GC, memory usage and

performance. A very quick summary is:



- Memory footprint, throughput and latency. Pick any two at the expense

of the third.



- Look at your application's steady state memory usage. It should be a

sawtooth. Take the minimum value of the sawtooth and multiply it by 5.

Allocate that much memory to the Java heap. That should give GC the room

it needs to operate efficiently.



That exact multiplier may not apply to more modern GC algorithms.



Every application is different. You'll need to do some testing to find

out what works best for your application.



Mark





-

To unsubscribe, e-mail: 
users-unsubscr...@tomcat.apache.org

For additional commands, e-mail: 
users-h...@tomcat.apache.org

Re: Best practices to set heap memory

[Christopher Schultz]

Mark,

On 4/22/25 3:38 AM, Mark Thomas wrote:

On 21/04/2025 17:49, Christopher Schultz wrote:

Ramesh,

On 4/21/25 1:06 AM, Ramesh B R wrote:

How to decide on heap memory size?
is it 25% of total memory? or 50% total memory?

What is the ideal value (in %) for heap memory ?


Only you can answer that question about your own application environment.

The percentage of total memory is completely irrelevant if you ask me. 
Presumably, you have a server so that you can serve requests for the 
application. If you have other services on the same server, then you 
will have to balance the memory requirements of each service against 
the others.


If it's a single-service server then I would dedicate ALL of the 
available memory to that service. That doesn't mean 100% (or 90% or 
80%) dedicated to heap memory, as there is a lot of memory usage in 
Java that is not accounted for by the heap.


I would start from the other end: what does your application actually 
need under typical (and worst-case) load scenarios. If your 
application doesn't need a lot of heap space, then I wouldn't bother 
paying for it, whether you are buying physical RAM chips or renting 
them from a cloud provider.


If you have other requirements, such as minimal application pauses, or 
transaction times where GC could impact your ability to meet certain 
goals, then your heap space may be of critical concern. Mot modern GCs 
benefit from more memory. Remember that the "cost" of the garbage 
collector is related to the number of things that need to stay in 
memory rather than the number of things that need to be collected. So 
running GC on a large heap is no more expensive than it is running on 
a small heap, assuming the same load scenarios.


Big +1 to all of the above.

A long time ago I attended some talks of Java GC, memory usage and 
performance. A very quick summary is:


- Memory footprint, throughput and latency. Pick any two at the expense 
of the third.


- Look at your application's steady state memory usage. It should be a 
sawtooth. Take the minimum value of the sawtooth and multiply it by 5. 
Allocate that much memory to the Java heap. That should give GC the room 
it needs to operate efficiently.


That exact multiplier may not apply to more modern GC algorithms.

Every application is different. You'll need to do some testing to find 
out what works best for your application.


Ooh, one more thing... assuming this is a long-lived service on 
dedicated (possibly virtual) hardware: set your minimum and maximum heap 
sizes on startup to the save value. There is zero advantage to having 
the JVM constantly re-sizing the heap if you expect to use it all 
eventually.


-chris


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Axis Fault, Xerces sees the webapp as stopped although it is running

[Mark Thomas]

On 22/04/2025 16:44, Simon Arame wrote:




What is strange is that although it says "this web application instance has
been stopped already", the web application is still running, end users are
still receiving 200 OKs from the web application.


Any other web applications running on that Tomcat instance?

Has the web application with the issue ever been restarted / reloaded?


We are not sure what causes this because it does not always happen, it is
"intermittent". The SoapBindingStub is called from a JSP which is aimed to
simulate a call to a Soap service as if it was coming from outside of this
app.
So the jsp that made the call received this 500 error from the Soap service
but this is unusual.


What you are seeing is the web application attempting to use classes 
that were loaded by a different/"older version of the current" web 
application.


This sort of thing can happen when a web application (or a library is 
uses) registers something at the JVM level which then becomes a global 
resource rather than a web application specific resource.


The trick to fixing this is figuring out what code is performing this 
JVM level registration and moving that code from the web application to 
$CATALINA_BASE/lib


If it is a library the application is using, this is relatively simple. 
If it is the application then things get trickier.


Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: State Synchronization without Serialization - Possible?

[Eric Robinson]

The third one. ☹

Oh well, I had to ask.

-Eric


-Original Message-
From: Mark Thomas 
Sent: Tuesday, April 22, 2025 2:50 AM
To: users@tomcat.apache.org
Subject: Re: State Synchronization without Serialization - Possible?

On 22/04/2025 01:09, Eric Robinson wrote:
> Hi all,
>
> We want to implement tomcat clustering, but we cannot because the application 
> is commercial, and it does not support serializable objects. In short, it 
> does not work with tomcat's standard clustering technology. Is there any 
> known reliable way to share session state, cookies, etc., between tomcat 
> instances, without using tomcat's native clustering facilities, and without 
> having access to the application code? I know it's probably a dumb question, 
> but I must ask.

What are you trying to achieve?

Sharing the load between multiple servers?

Fail over (with data loss) if one server fails?

Fail over without data loss if one server fails?

The first two can be done. The third would require some tool that could 
reliably serialize any Java object regardless of whether it was serializable. I 
haven't come across such a tool but that doesn't mean one doesn't exist.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Axis Fault, Xerces sees the webapp as stopped although it is running

[Simon Arame]

Hi,

I'm running tomcat 9.0.98 with jvm 1.8.0_432 on a Rocky LInux.

I've encountered this problem with Axis Soap library: the server throws an
exception, in the application log, a simple AxisFault: ( hostname and class
name changed for privacy reasons )

> ERROR - axisfaultexception
> AxisFault
>  faultCode: {
http://schemas.xmlsoap.org/soap/envelope/}Server.userException
>  faultSubcode:
>  faultString: java.lang.reflect.InvocationTargetException
>  faultActor:
>  faultNode:
>  faultDetail:
> {http://xml.apache.org/axis/}hostname:myhostname.com

> java.lang.reflect.InvocationTargetException
> at
org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222)
> at
org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129)
> at
org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087)
> at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown
Source)
> at
org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown
Source)
> at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
Source)
> at
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown
Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown
Source)
> at
org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source)
> at
org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
> at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
> at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
> at
org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
> at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
> at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
> at org.apache.axis.client.Call.invoke(Call.java:2767)
> at org.apache.axis.client.Call.invoke(Call.java:2443)
> at org.apache.axis.client.Call.invoke(Call.java:2366)
> at org.apache.axis.client.Call.invoke(Call.java:1812)
> at my.app.SoapBindingStub.method(SoapBindingStub.java: ###)
> at my...

But then I also see the following when I open the catalina.log

>22-Apr-2025 10:34:05.537 INFO [http-nio-8080-exec-17]
org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading
Illegal access: this web application instance has been stopped already.
Could not load
[org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl$DaysInMonth]. The
following stack trace is thrown for debugging purposes as well as to
attempt to terminate the thread which caused the illegal access.
>java.lang.IllegalStateException: Illegal access: this web
application instance has been stopped already. Could not load
[org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl$DaysInMonth]. The
following stack trace is thrown for debugging purposes as well as to
attempt to terminate the thread which caused the illegal access.
>at
org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading(WebappClassLoaderBase.java:1369)
>at
org.apache.catalina.loader.WebappClassLoaderBase.checkStateForClassLoading(WebappClassLoaderBase.java:1357)
>at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1191)
>at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1158)
>at
org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl.maximumDayInMonthFor(Unknown
Source)
>at
org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl.isValid(Unknown
Source)
>at
org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl.(Unknown
Source)
>at
org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl.createDateTime(Unknown
Source)
>at
org.apache.xerces.jaxp.datatype.XMLGregorianCalendarImpl.(Unknown
Source)
>at
org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl.newXMLGregorianCalendar(Unknown
Source)
>at
com.sun.xml.bind.DatatypeConverterImpl._parseDateTime(DatatypeConverterImpl.java:397)
>at
com.sun.xml.bind.DatatypeConverterImpl.parseDateTime(DatatypeConverterImpl.java:392)
>at
javax.xml.bind.DatatypeConverter.parseDateTime(DatatypeConverter.java:327)
>at my.app.SoapFacade.method(SoapFacade.java: ###)


What is strange is that although it says "this web application instance has
been stopped