visualvm monitors memory usage

2019-09-03 14:28发布

in my tomcat startup, i set -xms , -xmx to 1GB. inside visualvm when i monitor memory

  1. when i do sampling of memory, it doesnt show accurate memory usage, until, if i press 'snapshot', and then the java classes that utilizing memory showing correct patterns and instances count. why like this?

  2. also, as i set tomcat memory to 1gb, memory keep on increasing ing zip-zat and go up aroudn 960mb. until i press "perform gc" and the memory back to 200mb..

  3. do you think needed to create scheduler to force hit perform.gc() on jvm ,everday at midnight?

any comments from my description

VisualVM screenshot

1条回答
再贱就再见
2楼-- · 2019-09-03 15:09

What I believe you see here is the concurrent Garbage Collector is doing young generation cleanups, but the heap is constantly churning so it can't get a hold of all the references for an old generation collection. When you hit the perform GC button you're doing a "stop-the-world" collection which blocks all the threads, freezing the heap, and allowing a much larger collection to occur. My main concerns here would be - does a large collection ever occur (after x hours)? Are you seeing OutOfMemory errors with a smaller heap?

1) Do you have the auto refresh button turned on? It may also be that profiler does a small GC (Eden space) before taking a snapshot.

2) This is perfectly normal. Garbage collection takes time and resources (processor cycles). If you've set your heap to a large size, it will wait until it reaches some percentage of that until triggering a garbage collection itself. I think the default free space to live object ratio is between 40% and 70% I know tomcat specifically changed the way it does garbage collection around version 5, tomcat v4 had performance issues because it spent a lot of time running the garbage collector. You may want to do some research here and see if tomcat has custom garbage collection options.

3) No. A nearly full heap is exactly what you're striving for. It may make sense to make the heap smaller so that a full garbage collection doesn't take such a long time. It's trade-off between lots of garbage collections (pauses) and lengthy garbage collections (long pauses). Each app is different, so I generally start with the defaults and tweak as needed. There are lots of options for garbage collection (and alternate collectors) if you're interested.

Java 5

Java 6 FAQ, Whitepaper

查看更多
登录 后发表回答