Hi,
that's a question that is not specific to Zabbix or Tomcat but to all kind of
cases that use *one* JVM to run more than one "Application". And that's also an
open point to me since nearly decades.
Some years ago I googled something that is called "Classmexer" (as a
subproject(?) of something that is called "Javamex"
https://www.javamex.com/classmexer/
This seems to provide a Package that may calculate the memory consumption of an
java object (tree?). Maybe, by help of this, on may be able to calculate what's
the memory attatched to a certain classloader or servlet container. Maybe some
Java guru here can take a look at this, it even seem to provide a JMX
instrumentation interface, yet.
If it is possible to use this an if it's not a real expensive operation, then
somebody may develop a kind of adapter to be used for Tomcat or other
Application Servers.
@Fellipe: There are some tools to examine a JVM heap dump, but -- as me --
that's not you're looking for. Dumping the heap on a running JVM is a
stop-world-event that will take significant time in case of the usecase here,
where the heap of the Tomcat JVM will be sized to many GBs to serve a couple of
applications. From this, in a production environment one may pull a heap dump
for offline debugging purposes in case of already ongoing trouble. But it's not
appropriate for continuous monitoring.
Guido
>-----Original Message-----
>From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>Sent: Friday, April 05, 2019 12:35 AM
>To: users@tomcat.apache.org
>Subject: Re: Monitoring resources comsumption at context level
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>Fellipe,
>
>On 4/4/19 16:51, Fellipe Theophilo wrote:
>> Hi Cris, thank you for reply. So, I've talked to the developer team
>> about this and they told me that they want to be able to know at
>> OBJECT level or at CLASS level what is consuming more resources, to
>> make easier to debug the code. For example, suppose that some JVM
>> is having high resource comsumption, they want to know what CLASS,
>> or what METHOD is the responsible for the issue. Is there any way
>> to do it?
>
>Your developer team should already know that the only way to do that
>would be to take a heap dump or attach a debugger to a running JVM.
>What they want is simply not possible via JMX.
>
>Taking a heap dump can cause your JVM to stall for an indeterminate
>amount of time.
