Jmap堆转储，它包括年轻一代吗? [英] Jmap heap dump, does it include young generation?

问题描述

jmap堆转储仅包含旧一代，还是包含年轻一代?

我有2个堆转储(jmap -heap:format=b 9999):

• 我的一台服务器没有负载(没有HTTP请求)
• 在50％CPU上工作时一个，高负载(基准测试)

现在，第一个转储显示的堆大小大于第二个(我认为这很奇怪).

Now, the first dump shows a heap size bigger than the second (which I thought was weird).

这可能是因为Garbage收集器经常运行(是的，JVM几乎已满)导致Young一代(高负载)经常更改吗?老一辈人已占满99％，我注意到年轻一辈子的空间使用情况相差很大.

Could that be because the Young generation (at high load) is changing often because the Garbage collector is running often (yes, the JVM is almost full) ? Old generation is full at 99%, I've noticed the young generation space usage vary a lot.

这意味着我在GC完成他的工作后立即进行了第二次转储，这就是为什么它较小的原因.我说的对吗?

So that would mean that I made the second dump right after the GC did his job, this is why its size is smaller. Am I right ?

其他信息:

Java参数:

-XX:+UseParallelGC -XX:+AggressiveHeap
-Xms2048m -Xmx4096m -XX:NewSize=64m
-XX:PermSize=64m -XX:MaxPermSize=512m

推荐答案

快速解答

两者-堆由年轻一代和老一代组成.因此，当您进行堆转储时，内容将同时包含两者.堆转储的统计信息应该分开.尝试删除命令的二进制部分，并以纯文本格式查看.您将看到配置摘要，然后逐个细分.另一方面，-histo会无区别地显示堆中的所有对象

Both - The Heap is made up of the Young and Old Generation. So when you take a heap dump, the contents contains both. The Stats of the heap dump should be seperated. Try removing the binary portion of your command and look at it in plain text. You will see a summary of your configuration, and then a break down of each generation. On the flip side, a -histo would just show all objects on the heap with no distinction

长期回答

可能是第二个过程的垃圾收集刚刚完成.或相反，第一个进程可能在一段时间内没有完整的收集，而位于更高的内存中.进行捕获时，此应用程序/服务器是否刚刚重新启动?如果您使用jvisualvm之类的工具查看一个空闲进程，则即使进程没有做任何工作，您也会看到内存分配图在向上和向下移动.这只是JVM在做自己的事情.

It could be that a garbage collection had just finished for the 2nd process. Or the opposite, the first process may not have had a full collection in a while and was sitting at higher memory. Was this application/server just restarted when you took the capture? If you look at an idle process using a tool like jvisualvm, you will see the memory allocation graphs move up and down even though your process isn't doing any work. This is just the JVM doing its own thing.

通常，您的Full GC应该在老一代中达到99％的标记之前就启动了.JVM将决定何时运行Full GC.您的年轻代会大幅波动，因为这是最快创建/删除对象的地方.在运行完整的GC之前，将进行许多部分GC的操作以清除年轻一代.两者之间的差异将意味着您的JVM活动暂停.看到部分GC不会损害您的应用程序.但是，完整GC的暂停时间将使您的应用程序在运行时停止运行.因此，您将希望最大程度地减少这种情况.

Typically your Full GC should kick off well before it reaches a 99% mark in the Old Gen. The JVM will decide when to run the full GC. Your Young Gen will fluctuate alot as this is where objects are created/removed the fastest. There will be many partial GC's done to clean out the young gen before a full GC get run. The difference between the two will mean a pause in your JVM activity. Seeing a partial GC will not hurt your application. But the pause times of a full GC will stop your application while it runs. So you will want to minimize those the best you can.

如果您正在寻找内存泄漏或仅进行概要分析以查看您的应用程序gc的工作方式，我建议您使用启动标志来打印垃圾收集状态.

If you are looking for memory leaks or just profiling to see how your application(s) gc is working, I would recommend using the startup flags to print the garbage collection stats.

-XX:+PrintGCDetails -verbose:gc -Xloggc:/log/path/gc.log

运行您的程序一段时间，然后将捕获的日志加载到工具中以帮助可视化结果.我个人使用了IBM Support Assistant Workbench中提供的垃圾收集和内存可视化工具.它将为您提供捕获的垃圾收集统计信息的摘要以及动态图表，您可以使用该图表查看应用程序中内存的行为方式.这不会给您堆上有什么对象.

run your program for a while and then load the captured log in a tool to help visualize the results. I personally use the Garbage Collection and Memory Visualizer offered in the IBM Support Assistant Workbench. It will provide you with a summary of the captured garbage collection stats as well as a dynamic graph which you can use to see how the memory in your application has been behaving. This will not give you what objects were on your heap.

在应用程序出现问题时，如果您可以暂停一下，我将修改jmap命令以执行以下操作

At problem times in your application, if you can live with a pause, I would modify your jmap command to do the following

jmap -dump:format=b,file=/file/location/dump.hprof <pid>

使用 MAT 之类的工具，您将能够看到所有对象，泄漏嫌疑人以及其他各种统计信息关于世代，关于堆的引用.

Using a Tool like MAT, you will be able to see all of the objects, leak suspects, and various other stats about the generations, references of the heap.

编辑调谐讨论

根据您的启动参数，您可以尝试一些操作

Based on your start-up parameters there are a few things you can try

• 将-Xms设置为相同的值 作为您的-Xmx.通过这样做，JVM 不必花费时间分配 更多的堆.如果您希望自己的应用占用4GB的存储空间，请立即将其全部提供
• 取决于处理器数量 在您正在运行的系统上 您可以为其设置标志的应用程序 -XX:ParallelGCThreads=##.
• 我还没有尝试过，但是 文档显示了一个参数 -XX:+UseParallelOldGC表明可以减少旧式GC的时间 集合.
• 尝试将您的新一代大小更改为堆的1/4. (1024而不是64)对老一代而言可能太过分了.默认大小为30％左右，您已将您的应用配置为年轻一代使用2％左右.尽管您没有配置最大大小，但我担心太多数据会移至旧一代，因为新一代太小而无法处理所有请求.因此，您必须执行更完整(已暂停)的GC才能清理内存.

• Set your -Xms equal to the same value as your -Xmx. By doing this the JVM doesn't have to spend time allocating more heap. If you expect your application to take 4gb, then give it all right away
• Depending on the number of processors on the system you are running this application you can set the flag for -XX:ParallelGCThreads=##.
• I havent tried this one but the documentation shows a parameter for -XX:+UseParallelOldGC which shows some promise to reduce time of old GC collection.
• Try changing your new generation size to 1/4 of the Heap. (1024 instead of 64) This could be forcing too much to the old generation. The default size is around 30%, you have your application configured to use around 2% for young gen. Though you have no max size configured, I worry that too much data would be moved to old gen because the new gen is too small to handle all of the requests. Thus you have to perform more full (paused) GC's in order to clean up the memory.

总的来说，我确实相信，如果您这么快地分配了这么多的内存，那么这可能是一代的问题，其中的内存会过早地分配给旧的一代.如果对新世代大小的调整不起作用，则需要通过-Xmx配置添加更多堆，或者退后一步以确切地找到保留在内存中的内容.我们前面讨论的MAT工具可以为您显示保存在内存中的对象的引用.我建议您尝试要点1& 4第一.要获得正确的值，这将是一次反复的尝试

I do believe overall if you are allocating this much memory so fast, then it could be a generation problem where the memory is allocated to the Old generation prematurely. If a tweak to your new gen size doesn't work, then you need to either add more heap via the -Xmx configuration, or take a step back and find exactly what is holding onto the memory. The MAT tool which we discussed earlier can show you the references holding onto the objects in memory. I would recommend trying bullet points 1 & 4 first. This will be trial and error for you to get the right values

这篇关于Jmap堆转储，它包括年轻一代吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！