On Wed, 2022-05-18 at 17:36 -0400, Christopher Schultz wrote:
> > > > > Is it possible to find out the per deployed context heap usage in 
> > > > > tomcat?
> > > > 
> > > > With a profiler you can look at the retained size of the web 
> > > > application class loader instance associated with a web application.
> > > 
> What reference path would lead from a java.lang.String object to the web 
> application ClassLoader? It's allocation-path? That would be tied to the 
> Thread which allocated it, not to the TCCL the Thread happened to have 
> at the time.

If you look at a memory dump you can follow the references both up and down
Going up means asking "who owns this object" or "what class keeps this object
alive". 
Going down means asking "What fields does this class hold"

With modern memory profilers you can aks for the retained set of objects, 
the profiler will then start from the root objects and go down and calculate
how much memory is hanging under each object. Since the jvm heap is a 
graph with circles this is a bit tricky, but that is for the profile writers
to figure out.

So if we look at a hypothetical example:
Tomcat holds references to one or more classloaders, one per webapp.
Each such classloader holds on to a set of servlets.
Each servlet holds on to its own resources.

So when you look at the retained sets you se something like:
Tomcat holds 100% of the memory
 - Classloader for webapp 1 holds 80% of the memory
  - Servlet A holds 79% of the memory
  - Servlet B holds 1% of the memory
 - Classloader for webapp 2 holds 15% of the memory
 - classloader for webapp 3 holds 5% of the memory


This is of course a simplified example and common things may make the
statistics hard to read.

Personally I have used both visualvm and eclipse mat to look at memory 
profiles. Both of them support retained set calculations, but with the
last releases of java I have only managed to get visualvm working well.
If you get eclipse mat working with this it tends to be a bit more helpful.

Hope that makes sense!

/robo

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

Reply via email to