Java进程中提交的内存和RSS的差异 [英] Difference in committed memory and RSS in java process

问题描述

我正在运行一个运行jetty的简单Java进程，其顶部显示了2.9g的RAM.使用的JDK版本是1.8.0_112.

I am running a simple java process running jetty, for which top shows 2.9g of RAM. JDK version used is 1.8.0_112.

使用本机内存跟踪(jcmd)，它显示已提交的总内存仅为1.5G内存

Using Native Memory Tracking (jcmd), it is showing total committed memory is just 1.5G of memory

直接缓冲池的大小也非常小，如jvisualvm所报道.

Also the direct buffer pool size is very less, as reported by jvisualvm.

我完全意识到NMT所显示的内存是已提交的内存，不需要在RAM中.在那种情况下，NMT存储器对RES的贡献应该＜0. 1.5GB的RES内存.

I am completely aware that memory shown by NMT is committed memory which need not to be in RAM. In that case contribution of NMT memory to RES should be < 1.5GB of RES memory.

在我的情况下，这里的区别是〜1.4G(RES显示的是1.4G的更多内存)，这不能仅仅归因于共享库，罐子.有人可以建议我如何知道这个额外的内存是什么，以及可以使用哪些工具来检查它们吗?

In my case, the difference here is of ~1.4G (RES is showing 1.4G of more memory) which can't be attributed just to the shared libs, jars. Can someone suggest me how to know what this extra memory is and which tools can be used to check them?

我已经在线/Stackoverflow检查了所有现有的相关问题，但是找不到任何合适的答案.

I have checked all the existing related issues online/Stackoverflow, but couldn't find any suitable answer.

推荐答案

pmap -X <pid>将从操作系统的角度显示RSS的详细分类.

pmap -X <pid> will show the detailed breakdown of RSS from OS perspective.

NMT不计算由本机非JVM代码分配的内存，即使该内存是由标准Java类库(例如Java库)分配的也是如此.通过ZipInputStream的本机方法.请参阅相关问题.

NMT does not count memory allocated by native non-JVM code, even if this memory is allocated by the standard Java Class Library, e.g. by native methods of ZipInputStream. See the related question.

另一个可能的原因是malloc本身.本机内存分配器很少将未使用的内存返回给操作系统.例如，如果应用程序使用malloc在小块中分配1 GB，然后释放所有这些块，则从应用程序的角度来看，将有1 GB的可用内存，但是OS可能会在RSS中计入这1 GB.此内存基本上属于应用程序的malloc池，可以在以后的malloc调用中重新使用.

The other possible reason is malloc itself. Native memory allocator rarely returns unused memory back to the OS. For example, if an application allocates 1 GB in small chunks with malloc and then frees all these chunks, from the application perspective there will be 1 GB of free memory, but OS is likely to count this 1 GB in RSS. This memory basically belongs to the application's malloc pool and can be reused for future malloc calls.

尝试使用替代分配器，例如 jemalloc 或

Try to use alternative allocators like jemalloc or tcmalloc. By the way, they both have an allocation profiler that may help in finding native memory leaks.

这篇关于Java进程中提交的内存和RSS的差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！