visualvm监视内存使用情况 [英] visualvm monitors memory usage
问题描述
在我的tomcat启动中，我将-xms，-xmx设置为1GB.当我监视内存时，在visualvm内部
in my tomcat startup, i set -xms , -xmx to 1GB. inside visualvm when i monitor memory
-
当我进行内存采样时，它不会显示准确的内存使用情况，直到我按快照"，然后利用内存的Java类才会显示正确的模式和实例计数.为什么会这样?
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?
另外，当我将tomcat内存设置为1gb时，内存会继续增加zip-zat并上升到960mb.直到我按执行gc"，然后内存回到200mb.
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..
您是否需要每天在午夜创建调度程序以在jvm上强制命中perform.gc()?
do you think needed to create scheduler to force hit perform.gc() on jvm ,everday at midnight?
我的描述中有任何评论
推荐答案
我相信您在这里看到的是并发的Garbage Collector正在清理年轻一代，但是堆一直在搅动，因此无法容纳所有对象旧版本集合的参考.当您单击perform GC按钮时，您正在执行世界停止"收集，该收集将阻塞所有线程，冻结堆，并允许进行更大的收集.我在这里主要担心的是-是否会在x个小时后进行大量收集?您是否看到堆较小的OutOfMemory错误?
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)您是否已打开自动刷新按钮?可能还有因为事件探查器在拍摄快照之前做了一个小的GC(Eden空间).
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)这是完全正常的.垃圾收集需要时间和资源(处理器周期).如果您将堆设置为较大的大小，它将等待直到达到堆的某个百分比，然后才触发垃圾回收本身.我认为默认的可用空间与活动对象的比率在40％到70％之间，我知道tomcat特别更改了版本5进行垃圾收集的方式.tomcatv4存在性能问题，因为它花费了大量时间运行垃圾收集器.您可能要在这里做一些研究，看看tomcat是否具有自定义垃圾收集选项.
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)不.几乎要堆满就是您要争取的.减小堆大小可能很有意义，这样一个完整的垃圾回收不会花费很长时间.在大量垃圾收集(暂停)和冗长的垃圾收集(长时间暂停)之间进行权衡.每个应用程序都是不同的，因此我通常从默认值开始，并根据需要进行调整.如果您有兴趣，可以使用很多选项进行垃圾收集(和备用收集器).
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.
