Re: High load consumption - Artemis on Docker
@tim for a first analysis is fine to use JVisualVM, but I recommend async-profiler (or perf tools) because it shows GC activity, Kernel activity (on the networking layer and disk) and, if they are using a native SSL provider, the native methods cost of it (that often is huge). In addition, JVisualVM suffer from the safepoint bias issue, like many other profilers around, some reference here: http://psy-lob-saw.blogspot.com/2016/02/why-most-sampling-java-profilers-are.html Il gio 23 apr 2020, 05:16 Tim Bain ha scritto: > JVisualVM, which ships with the Oracle JDK (not sure about OpenJDK) is > another option. Be sure to use the CPU sampler, not the CPU profiler, if > you can't afford to add a significant load to the process (e.g. if this is > an operational host). > > Tim > > On Wed, Apr 22, 2020, 4:21 PM Francesco Nigro wrote: > > > I mean not just GC logs but CPU profiling (async-profiler is a mixed > > native-java profiler). Without something like that I cannot see how to > > help. > > > > Il mer 22 apr 2020, 23:43 Ybello ha scritto: > > > > > Hi thanks for the answers > > > Yes we did almost every memory analysis tools and we didn't find any > > > symptoms > > > It defentley something with the Artemis Broker... > > > We change the network Docker host implementation as well , insant of > > using > > > --proxy-docker we change it to --host network and still not luck > > > 8bhope to get some answers we got lost here... > > > > > > > > > > > > -- > > > Sent from: > > > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html > > > > > >
Re: High load consumption - Artemis on Docker
JVisualVM, which ships with the Oracle JDK (not sure about OpenJDK) is another option. Be sure to use the CPU sampler, not the CPU profiler, if you can't afford to add a significant load to the process (e.g. if this is an operational host). Tim On Wed, Apr 22, 2020, 4:21 PM Francesco Nigro wrote: > I mean not just GC logs but CPU profiling (async-profiler is a mixed > native-java profiler). Without something like that I cannot see how to > help. > > Il mer 22 apr 2020, 23:43 Ybello ha scritto: > > > Hi thanks for the answers > > Yes we did almost every memory analysis tools and we didn't find any > > symptoms > > It defentley something with the Artemis Broker... > > We change the network Docker host implementation as well , insant of > using > > --proxy-docker we change it to --host network and still not luck > > 8bhope to get some answers we got lost here... > > > > > > > > -- > > Sent from: > > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html > > >
Re: High load consumption - Artemis on Docker
I mean not just GC logs but CPU profiling (async-profiler is a mixed native-java profiler). Without something like that I cannot see how to help. Il mer 22 apr 2020, 23:43 Ybello ha scritto: > Hi thanks for the answers > Yes we did almost every memory analysis tools and we didn't find any > symptoms > It defentley something with the Artemis Broker... > We change the network Docker host implementation as well , insant of using > --proxy-docker we change it to --host network and still not luck > 8bhope to get some answers we got lost here... > > > > -- > Sent from: > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html >
Re: High load consumption - Artemis on Docker
Hi thanks for the answers Yes we did almost every memory analysis tools and we didn't find any symptoms It defentley something with the Artemis Broker... We change the network Docker host implementation as well , insant of using --proxy-docker we change it to --host network and still not luck 8bhope to get some answers we got lost here... -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Re: High load consumption - Artemis on Docker
Have you tried profiling with async-profiler (or perf tools) where the CPU time is spent? It could be either lack of memory on the heap (hence the GC is doing much more work to free up memory continuously) or whatever possible reason... Il mer 22 apr 2020, 23:04 Ybello ha scritto: > Hello everyone > Recently we suffering from bad performance that cause our Artemis to be on > 100% of cpu , load average is 12.8 > Our Artemis is sitting on o e gcp vm based on Docker image, the version > that > we running is 2.10 > I really want need your help to understanding the problems, we've been > trying everything without success > > Please advise > > Thanks > Yossi > > > > -- > Sent from: > http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html >
High load consumption - Artemis on Docker
Hello everyone Recently we suffering from bad performance that cause our Artemis to be on 100% of cpu , load average is 12.8 Our Artemis is sitting on o e gcp vm based on Docker image, the version that we running is 2.10 I really want need your help to understanding the problems, we've been trying everything without success Please advise Thanks Yossi -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Re: Artemis does not reconnect to MySQL after connection timeout
I exactly have the same problem like mk666aim! Is there any solution for this? Compare this stackoverflow thread: https://stackoverflow.com/questions/60884155/activemq-artemis-jdbc-store-add-connection-pool-for-db-connections Currently I send keep alive messages to my queues to keep alive the brokers db connection to the database. ANswers to your questions: 1) MySQL terminates connections without traffic after 8h. 2) This is not a solution 3) An MySQL connection is thrown, and caught by the brokers general exception handlern. This restarts the whole messagebroker and disconnects all clients. 4) As i understand, it's currently not (or no longer) possible to configure a javax.sql.DataSource which is handled by any connection pool (hikaro, c3po, ...). Obviously this was possible before via spring xml config. 5) Even if autoReconnect is set to true, the MySQL driver thows an exception which causes the messagebroker to restart. -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
