search

stagemonitor / stagemonitor-mailinglist

GitHub issues abused as a mailing list
3 stars 0 forks source link

stagemonitor with vaadin #23

Open marcell93 opened 8 years ago

marcell93 commented 8 years ago

Hi I'm trying to use stagemonitor with vaadin and every time I use my jboss 6.2 server consumes more and more RAM until a moment stumbles everything. The only thing I did was add stagemonitor the pom. What else do to make everything work well? I'm using google translator because I do not speak English :laughing: . Thank you very much, greetings

felixbarny commented 8 years ago

Hi Marcel, does the memory increase when you do a redeploy of your application or also when the server is just running? It probably has to do with this issue: https://github.com/stagemonitor/stagemonitor/issues/126

marcell93 commented 8 years ago

Memory increases when the server is running. Do not know if this is the problem stagemonitor/stagemonitor#126

felixbarny commented 8 years ago

Could you share your application so that I can reproduce the problem?

marcell93 commented 8 years ago

The problem is that it has many validations to work only in my workplace and are too numerous to remove them. I'll have to add some settings to my server?

felixbarny commented 8 years ago

Would it be possible for you to send me a heap dump of your application when it is about to crash? Then I can use Eclipse Memory Analyzer to see what's wrong.

marcell93 commented 8 years ago

The heap dump generated weighs 758MB. As I give?

felixbarny commented 8 years ago

maybe via dropbox or something simmilar?

marcell93 commented 8 years ago

This is the file thank you very much https://www.dropbox.com/s/o21qlqn35ywkv4t/dumpGLA.bin?dl=0

felixbarny commented 8 years ago

Was this heap dump taken just before a crash? At first glance I can't see any memory wasted by stagemonitor. The only thing that is a bit strange is that Finalizers account for about 20% of the heap size. What are your current settings for stagemonitor?

marcell93 commented 8 years ago

The configuration is the one by default. The head dump did when the Jboss get to consume 2GB of RAM. You want to do it when the server consumes 6 GB of RAM ?

felixbarny commented 8 years ago

Did you specify the configuration key stagemonitor.instrument.include like explained here?

marcell93 commented 8 years ago

The stagemonitor.properties file has these lines: stagemonitor.applicationName = GLA

stagemonitor.instanceName = GLA

stagemonitor.instrument.include = uy.com.antel.gla.ui

In Jboss I get this:

09: 52: 13,809 WARN org.stagemonitor.jvm.JvmPlugin Could not register cpu usage. (com.sun.management.OperatingSystemMXBean from [Module "deployment.gla.ear.gla-ui-1.0-SNAPSHOT.war: main" from Service Module Loader])

felixbarny commented 8 years ago

You get the warning because by default the module class loader is configured in such a way that you can't load OperatingSystemMXBean. You can safely ignore this warning. Does it run more smoothly now with this config?

marcell93 commented 8 years ago

Continues to malfunction

felixbarny commented 8 years ago

Well, then I'll need a heap dump which is taken right before the server crashes. See http://stackoverflow.com/questions/542979/using-heapdumponoutofmemoryerror-parameter-for-heap-dump-for-jboss.

If you want, you can also take a look at the heap dump with Eclipse Memory Analyzer

You could also try setting stagemonitor.instrument.runtimeAttach to false so that we can exclude that something goes wrong because of bytecode manipulation.

marcell93 commented 8 years ago

I'll download the analyzer memory. Now I put stagemonitor.instrument.runtimeAttach = false and the server works well but in the call tree of stagemonitor nothing appears before if appeared.

felixbarny commented 8 years ago

Yeah, this setting basically disables the call tree feature. But now we know that this is the cause of the leak.

Now we have to analyze the heap dump of the crashed server to find out about the root cause.

marcell93 commented 8 years ago

This is the heap dump created when the server can consume 6GB of RAM. https://www.dropbox.com/s/35pzg5znylfixpb/dumpGLA2.bin?dl=0

marcell93 commented 8 years ago

Typically, the server consumes 1GB or 1.5GB of RAM

felixbarny commented 8 years ago

Are you sure this is the right heap dump? The heap is only 280 MB. Btw: which Java version are you using?

marcell93 commented 8 years ago

java -version java version "1.8.0_51" Java(TM) SE Runtime Environment (build 1.8.0_51-b16) Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)

The head dump did so: http://stackoverflow.com/questions/17135721/generating-heap-dumps-java-jre7

felixbarny commented 8 years ago

Just to be sure: are you actually running into OutOfMemoryErrors or ist the heap utilisation just higher than usual? In which environment are you experiencing the issues? Production or development on local machine? Does the memory decrease to a acceptable level when you are performing a manual garbage collection (for example with jvisualvm)?

marcell93 commented 8 years ago

It is the heap dump when the server is consuming a lot of RAM. It happens on my local machine, do not fix me if it worked remotely. I did not understand the last question. This is the head dump created from NetBeans: https://www.dropbox.com/s/fgsq20tk8urummt/heapdump-1457977189613.hprof?dl=0

felixbarny commented 8 years ago

I'm on vacation the next few days but I have a idea and I'm working on it.

marcell93 commented 8 years ago

Great thank you very much

felixbarny commented 8 years ago

I'm back from vacation and illness. I've added a new configuration option which enables object pooling for the profiler: https://github.com/stagemonitor/stagemonitor/commit/c2fe8e1a2285d64f1452e347fcf0f7922d649600#diff-8096c12c96b1a0d7d3fee012b12d9073R73 I hope that this helps you.

You can try out the latest SNAPSHOT like explained here: https://github.com/stagemonitor/stagemonitor#snapshots and set the configuration option stagemonitor.profiler.objectPooling=true.