-----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. Attaching a debugger can significantly degrade performance. For realtime monitoring, you may want to build-in some application self-monitoring features and then keep an eye on those from e.g. Zabbix. - -chris > Em ter, 2 de abr de 2019 às 20:01, Christopher Schultz < > [email protected]> escreveu: > > Fellipe, > > On 4/2/19 17:04, Fellipe Theophilo wrote: >>>> Hi everyone, I'm trying to find a way to monitor metrics of >>>> resources comsumption at context level. I've opened this >>>> thread: >>>> https://stackoverflow.com/questions/55070370/monitoring-multiple-ja va- > >>>> applications-at-once-with-one-zabbix-java-gateway > <https://stackoverflow.com/questions/55070370/monitoring-multiple-java - -applications-at-once-with-one-zabbix-java-gateway> >>>> >>>> > But no one knows a solution. By using jConsole and Zabbix I can >>>> check the value of some objects at context level, but none of >>>> them is any metric. So I tried the Spring Actuator, which >>>> expose many metrics through REST , returning a JSON. However, >>>> the call to >>>> http://<tomcat_address>:8080/<context_name>/metrics give >>>> metrics information of the JVM as a whole, even specifying >>>> the context name. To prove this I ran an AB(Apache Benchmark) >>>> to do a stress test and I've saw that memory usage grew >>>> together across the two contexts I have for testing. So the >>>> conclusion is that the Spring Actuator is not exposing >>>> metrics at context level. Do anyone know if is there a way to >>>> get metrics at context level? > > The reason that no tool provides per-context memory consumption > metrics is because it's not practical to actually measure that kind > of thing. > > You'd basically need to walk the object tree from GC roots (like > the GC does whenever it collects garbage) after determining what > the list of "GC roots" is for each context -- such as the > WebappClassLoader. > > The JVM treats memory as a shared resource. There is no memory > isolation between contexts within an application server. > > If you really want to monitor your web applications separately, > run them each in isolated JVMs. > > -chris >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlymhnYACgkQHPApP6U8 pFi1lg//bvCIPS2VAnJ8wT+YiUCldhk0IrOROWHngppYSX7hSLnhrlswu1srP0tO fhOpkXBXBbsp2wkX6xGugWhTqfmeRFplSokcWhKGsAi9822JeTqEk2LkhWsUA88R HGbKT1jk4Qw0OG+T94gJJPXhcQQYalNIE4+z68Jq/qA5HjTjDckM/7ORt2Tx049w rowge/AtBpZ3/E5GEtmh2LwOBA4oEUUJm6u3abnPU+0TlhZd1uVCR2MttNTaK4iG nYnn12bk+Ho03tXBxjdhd5fELt+VtpYidvlDA3wAqPwLA5xDKiRJJPKMvI0zgElv ShWZpE+2pGknROChEl+RCHNO3sSeOru4Ri5N0IHBfMcns6KpbM7xODoP7IrwFZUp zRD4+ffVan4qGGnLVsVZXyY5HA2K3Z51wz445lWK9cuSXJDDd4u+5vAW8cF7KIhH mXDypdS3L1RNatK6rDcRhDvkRgNiCzdTP2/qaAp5FOEkvGEshyX0AyL3WBD6Fqpb NcuR11jH80SKxeSUFatxjRMi/qx8zoO7WEHesfL1cvA3O1MBXYb/FO1d23+tK/f9 EXETpC90KQE9QjHXi6tZeKUBKkcU2YQyCOtARhlKAWgo/CoXekNbJ7wE8YAKhJp6 IjHDBcOOGHgaNexg+847Ds6+KqP1JjFmol6sjIVQQM8Xij1Y/jw= =N9dt -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
