Linux下Java的虚拟内存使用，使用了太多内存

Virtual Memory Usage from Java under Linux, too much memory used

提问by Mario Ortegón

I have a problem with a Java application running under Linux.

我有一个在 Linux 下运行的 Java 应用程序的问题。

When I launch the application, using the default maximum heap size (64 MB), I see using the tops application that 240 MB of virtual Memory are allocated to the application. This creates some issues with some other software on the computer, which is relatively resource-limited.

当我使用默认的最大堆大小 (64 MB) 启动应用程序时，我看到使用 tops 应用程序为应用程序分配了 240 MB 的虚拟内存。这会导致计算机上的一些其他软件出现一些问题，这些软件相对资源有限。

The reserved virtual memory will not be used anyway, as far as I understand, because once we reach the heap limit an OutOfMemoryErroris thrown. I ran the same application under windows and I see that the Virtual Memory size and the Heap size are similar.

据我所知，无论如何都不会使用保留的虚拟内存，因为一旦我们达到堆限制，OutOfMemoryError就会抛出一个。我在 windows 下运行了相同的应用程序，我看到虚拟内存大小和堆大小相似。

Is there anyway that I can configure the Virtual Memory in use for a Java process under Linux?

无论如何，我可以为Linux下的Java进程配置正在使用的虚拟内存吗？

Edit 1: The problem is not the Heap. The problem is that if I set a Heap of 128 MB, for example, still Linux allocates 210 MB of Virtual Memory, which is not needed, ever.**

编辑 1：问题不在于堆。问题是，如果我设置一个 128 MB 的堆，例如，Linux 仍然分配 210 MB 的虚拟内存，这是不需要的，永远。**

Edit 2: Using ulimit -vallows limiting the amount of virtual memory. If the size set is below 204 MB, then the application won't run even though it doesn't need 204 MB, only 64 MB. So I want to understand why Java requires so much virtual memory. Can this be changed?

编辑 2：使用ulimit -v允许限制虚拟内存的数量。如果设置的大小低于 204 MB，那么即使不需要 204 MB，只需要 64 MB，应用程序也不会运行。所以我想了解为什么Java需要这么多的虚拟内存。这可以改变吗？

Edit 3: There are several other applications running in the system, which is embedded. And the system does have a virtual memory limit (from comments, important detail).

编辑 3：系统中还有其他几个应用程序在运行，这些应用程序是嵌入式的。并且系统确实有虚拟内存限制（来自评论，重要细节）。

采纳答案by kdgregory

This has been a long-standing complaint with Java, but it's largely meaningless, and usually based on looking at the wrong information. The usual phrasing is something like "Hello World on Java takes 10 megabytes! Why does it need that?" Well, here's a way to make Hello World on a 64-bit JVM claim to take over 4 gigabytes ... at least by one form of measurement.

这是 Java 长期以来的抱怨，但它在很大程度上毫无意义，而且通常基于查看错误的信息。通常的措辞是“Java 上的 Hello World 需要 10 兆字节！为什么需要那个？” 好吧，这里有一种方法可以让 64 位 JVM 上的 Hello World 占用超过 4 GB 的空间……至少通过一种测量形式。

java -Xms1024m -Xmx4096m com.example.Hello

Different Ways to Measure Memory

测量内存的不同方法

On Linux, the topcommand gives you several different numbers for memory. Here's what it says about the Hello World example:

在 Linux 上，top命令为您提供了几个不同的内存数字。以下是关于 Hello World 示例的说明：

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2120 kgregory  20   0 4373m  15m 7152 S    0  0.2   0:00.10 java

• VIRT is the virtual memory space: the sum of everything in the virtual memory map (see below). It is largely meaningless, except when it isn't (see below).
• RES is the resident set size: the number of pages that are currently resident in RAM. In almost all cases, this is the only number that you should use when saying "too big." But it's still not a very good number, especially when talking about Java.
• SHR is the amount of resident memory that is shared with other processes. For a Java process, this is typically limited to shared libraries and memory-mapped JARfiles. In this example, I only had one Java process running, so I suspect that the 7k is a result of libraries used by the OS.
• SWAP isn't turned on by default, and isn't shown here. It indicates the amount of virtual memory that is currently resident on disk, whether or not it's actually in the swap space. The OS is very good about keeping active pages in RAM, and the only cures for swapping are (1) buy more memory, or (2) reduce the number of processes, so it's best to ignore this number.

• VIRT 是虚拟内存空间：虚拟内存映射中所有内容的总和（见下文）。它基本上没有意义，除非它不是（见下文）。
• RES 是常驻集大小：当前驻留在 RAM 中的页数。在几乎所有情况下，这是您在说“太大”时应该使用的唯一数字。但这仍然不是一个很好的数字，尤其是在谈论 Java 时。
• SHR 是与其他进程共享的常驻内存量。对于 Java 进程，这通常仅限于共享库和内存映射 JAR 文件。在这个例子中，我只运行了一个 Java 进程，所以我怀疑 7k 是操作系统使用的库的结果。
• 默认情况下未打开 SWAP，此处未显示。它表示当前驻留在磁盘上的虚拟内存量，无论它实际上是否在交换空间中。操作系统非常擅长将活动页面保留在 RAM 中，交换的唯一方法是 (1) 购买更多内存，或 (2) 减少进程数，因此最好忽略此数字。

The situation for Windows Task Manager is a bit more complicated. Under Windows XP, there are "Memory Usage" and "Virtual Memory Size" columns, but the official documentationis silent on what they mean. Windows Vista and Windows 7 add more columns, and they're actually documented. Of these, the "Working Set" measurement is the most useful; it roughly corresponds to the sum of RES and SHR on Linux.

Windows 任务管理器的情况稍微复杂一些。在 Windows XP 下，有“Memory Usage”和“Virtual Memory Size”列，但官方文档没有说明它们的含义。Windows Vista 和 Windows 7 添加了更多的列，并且它们实际上被记录在案。其中，“工作集”测量是最有用的；它大致对应于 Linux 上的 RES 和 SHR 的总和。

Understanding the Virtual Memory Map

了解虚拟内存映射

The virtual memory consumed by a process is the total of everything that's in the process memory map. This includes data (eg, the Java heap), but also all of the shared libraries and memory-mapped files used by the program. On Linux, you can use the pmapcommand to see all of the things mapped into the process space (from here on out I'm only going to refer to Linux, because it's what I use; I'm sure there are equivalent tools for Windows). Here's an excerpt from the memory map of the "Hello World" program; the entire memory map is over 100 lines long, and it's not unusual to have a thousand-line list.

进程消耗的虚拟内存是进程内存映射中所有内容的总和。这包括数据（例如，Java 堆），但也包括程序使用的所有共享库和内存映射文件。在 Linux 上，您可以使用pmap命令查看映射到进程空间中的所有内容（从这里开始，我将只参考 Linux，因为它是我使用的；我确定有等效的工具可用于视窗）。这是“Hello World”程序内存映射的摘录；整个内存映射长达100多行，千行列表也不少见。

0000000040000000     36K r-x--  /usr/local/java/jdk-1.6-x64/bin/java
0000000040108000      8K rwx--  /usr/local/java/jdk-1.6-x64/bin/java
0000000040eba000    676K rwx--    [ anon ]
00000006fae00000  21248K rwx--    [ anon ]
00000006fc2c0000  62720K rwx--    [ anon ]
0000000700000000 699072K rwx--    [ anon ]
000000072aab0000 2097152K rwx--    [ anon ]
00000007aaab0000 349504K rwx--    [ anon ]
00000007c0000000 1048576K rwx--    [ anon ]
...
00007fa1ed00d000   1652K r-xs-  /usr/local/java/jdk-1.6-x64/jre/lib/rt.jar
...
00007fa1ed1d3000   1024K rwx--    [ anon ]
00007fa1ed2d3000      4K -----    [ anon ]
00007fa1ed2d4000   1024K rwx--    [ anon ]
00007fa1ed3d4000      4K -----    [ anon ]
...
00007fa1f20d3000    164K r-x--  /usr/local/java/jdk-1.6-x64/jre/lib/amd64/libjava.so
00007fa1f20fc000   1020K -----  /usr/local/java/jdk-1.6-x64/jre/lib/amd64/libjava.so
00007fa1f21fb000     28K rwx--  /usr/local/java/jdk-1.6-x64/jre/lib/amd64/libjava.so
...
00007fa1f34aa000   1576K r-x--  /lib/x86_64-linux-gnu/libc-2.13.so
00007fa1f3634000   2044K -----  /lib/x86_64-linux-gnu/libc-2.13.so
00007fa1f3833000     16K r-x--  /lib/x86_64-linux-gnu/libc-2.13.so
00007fa1f3837000      4K rwx--  /lib/x86_64-linux-gnu/libc-2.13.so
...

A quick explanation of the format: each row starts with the virtual memory address of the segment. This is followed by the segment size, permissions, and the source of the segment. This last item is either a file or "anon", which indicates a block of memory allocated via mmap.

格式的快速解释：每一行都以段的虚拟内存地址开始。接下来是段大小、权限和段的来源。最后一项是文件或“匿名”，表示通过mmap分配的内存块。

Starting from the top, we have

从顶部开始，我们有

• The JVM loader (ie, the program that gets run when you type java). This is very small; all it does is load in the shared libraries where the real JVM code is stored.
• A bunch of anon blocks holding the Java heap and internal data. This is a Sun JVM, so the heap is broken into multiple generations, each of which is its own memory block. Note that the JVM allocates virtual memory space based on the -Xmxvalue; this allows it to have a contiguous heap. The -Xmsvalue is used internally to say how much of the heap is "in use" when the program starts, and to trigger garbage collection as that limit is approached.
• A memory-mapped JARfile, in this case the file that holds the "JDK classes." When you memory-map a JAR, you can access the files within it very efficiently (versus reading it from the start each time). The Sun JVM will memory-map all JARs on the classpath; if your application code needs to access a JAR, you can also memory-map it.
• Per-thread data for two threads. The 1M block is the thread stack. I didn't have a good explanation for the 4k block, but @ericsoe identified it as a "guard block": it does not have read/write permissions, so will cause a segment fault if accessed, and the JVM catches that and translates it to a StackOverFlowError. For a real app, you will see dozens if not hundreds of these entries repeated through the memory map.
• One of the shared libraries that holds the actual JVM code. There are several of these.
• The shared library for the C standard library. This is just one of many things that the JVM loads that are not strictly part of Java.

• JVM 加载程序（即，在您键入时运行的程序java）。这是非常小的；它所做的只是加载到存储真实 JVM 代码的共享库中。
• 一堆持有 Java 堆和内部数据的匿名块。这是一个Sun JVM，所以堆被分成多代，每一代都是自己的内存块。注意JVM根据-Xmx值分配虚拟内存空间；这允许它有一个连续的堆。该-Xms值在内部用于说明程序启动时“正在使用”的堆有多少，并在接近该限制时触发垃圾收集。
• 内存映射 JARfile，在本例中是保存“JDK 类”的文件。当您对 JAR 进行内存映射时，您可以非常有效地访问其中的文件（而不是每次从头开始读取）。Sun JVM 将对类路径上的所有 JAR 进行内存映射；如果您的应用程序代码需要访问 JAR，您还可以对其进行内存映射。
• 两个线程的每线程数据。1M 块是线程堆栈。我对 4k 块没有很好的解释，但 @ericsoe 将其标识为“保护块”：它没有读/写权限，因此如果访问会导致段错误，JVM 会捕获并翻译它到一个StackOverFlowError. 对于真正的应用程序，您会看到数十个甚至数百个这些条目在内存映射中重复。
• 保存实际 JVM 代码的共享库之一。其中有几个。
• C 标准库的共享库。这只是 JVM 加载的许多不属于 Java 的严格内容之一。

The shared libraries are particularly interesting: each shared library has at least two segments: a read-only segment containing the library code, and a read-write segment that contains global per-process data for the library (I don't know what the segment with no permissions is; I've only seen it on x64 Linux). The read-only portion of the library can be shared between all processes that use the library; for example, libchas 1.5M of virtual memory space that can be shared.

共享库特别有趣：每个共享库至少有两个段：一个包含库代码的只读段，一个包含库的全局每进程数据的读写段（我不知道是什么）没有权限的段是；我只在 x64 Linux 上看到过）。库的只读部分可以在使用库的所有进程之间共享；例如，libc有1.5M的虚拟内存空间可以共享。

When is Virtual Memory Size Important?

虚拟内存大小何时重要？

The virtual memory map contains a lot of stuff. Some of it is read-only, some of it is shared, and some of it is allocated but never touched (eg, almost all of the 4Gb of heap in this example). But the operating system is smart enough to only load what it needs, so the virtual memory size is largely irrelevant.

虚拟内存映射包含很多东西。有些是只读的，有些是共享的，有些是分配的但从未接触过（例如，在这个例子中几乎所有的 4Gb 堆）。但是操作系统足够聪明，只加载它需要的东西，所以虚拟内存大小在很大程度上无关紧要。

Where virtual memory size is important is if you're running on a 32-bit operating system, where you can only allocate 2Gb (or, in some cases, 3Gb) of process address space. In that case you're dealing with a scarce resource, and might have to make tradeoffs, such as reducing your heap size in order to memory-map a large file or create lots of threads.

如果您在 32 位操作系统上运行，虚拟内存大小很重要，您只能分配 2Gb（或在某些情况下，3Gb）的进程地址空间。在这种情况下，您正在处理稀缺资源，并且可能必须进行权衡，例如减少堆大小以对大文件进行内存映射或创建大量线程。

But, given that 64-bit machines are ubiquitous, I don't think it will be long before Virtual Memory Size is a completely irrelevant statistic.

但是，鉴于 64 位机器无处不在，我认为不久之后虚拟内存大小将成为一个完全无关的统计数据。

When is Resident Set Size Important?

驻留集大小何时重要？

Resident Set size is that portion of the virtual memory space that is actually in RAM. If your RSS grows to be a significant portion of your total physical memory, it might be time to start worrying. If your RSS grows to take up all your physical memory, and your system starts swapping, it's well past time to start worrying.

驻留集大小是实际在 RAM 中的那部分虚拟内存空间。如果您的 RSS 增长到您的总物理内存的很大一部分，则可能是时候开始担心了。如果您的 RSS 增长到占用您所有的物理内存，并且您的系统开始交换，那么该担心的时间已经过去了。

But RSS is also misleading, especially on a lightly loaded machine. The operating system doesn't expend a lot of effort to reclaiming the pages used by a process. There's little benefit to be gained by doing so, and the potential for an expensive page fault if the process touches the page in the future. As a result, the RSS statistic may include lots of pages that aren't in active use.

但是 RSS 也具有误导性，尤其是在负载较轻的机器上。操作系统不会花费大量精力来回收进程使用的页面。这样做几乎没有什么好处，而且如果进程在将来接触到页面，可能会发生代价高昂的页面错误。因此，RSS 统计信息可能包含许多未处于活动状态的页面。

Bottom Line

底线

Unless you're swapping, don't get overly concerned about what the various memory statistics are telling you. With the caveat that an ever-growing RSS may indicate some sort of memory leak.

除非您正在交换，否则不要过分担心各种内存统计信息告诉您什么。需要注意的是，不断增长的 RSS 可能表明某种内存泄漏。

With a Java program, it's far more important to pay attention to what's happening in the heap. The total amount of space consumed is important, and there are some steps that you can take to reduce that. More important is the amount of time that you spend in garbage collection, and which parts of the heap are getting collected.

对于 Java 程序，关注堆中发生的事情要重要得多。消耗的空间总量很重要，您可以采取一些步骤来减少它。更重要的是你花在垃圾收集上的时间，以及堆的哪些部分被收集。

Accessing the disk (ie, a database) is expensive, and memory is cheap. If you can trade one for the other, do so.

访问磁盘（即数据库）很昂贵，而内存很便宜。如果你可以用一个换另一个，那就这样做吧。

回答by Marko

No, you can't configure memory amount needed by VM. However, note that this is virtual memory, not resident, so it just stays there without harm if not actually used.

不，您无法配置 VM 所需的内存量。但是，请注意，这是虚拟内存，而不是常驻内存，因此如果不实际使用，它只会留在那里而不会造成伤害。

Alernatively, you can try some other JVM then Sun one, with smaller memory footprint, but I can't advise here.

或者，您可以尝试一些其他的 JVM，然后是 Sun 一个，内存占用更小，但我不能在这里建议。

回答by Paul Tomblin

Sun's java 1.4 has the following arguments to control memory size:

Sun 的 java 1.4 有以下参数来控制内存大小：

-Xmsn Specify the initial size, in bytes, of the memory allocation pool. This value must be a multiple of 1024 greater than 1MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is 2MB. Examples:

           -Xms6291456
           -Xms6144k
           -Xms6m

-Xmxn Specify the maximum size, in bytes, of the memory allocation pool. This value must a multiple of 1024 greater than 2MB. Append the letter k or K to indicate kilobytes, or m or M to indicate megabytes. The default value is 64MB. Examples:

           -Xmx83886080
           -Xmx81920k
           -Xmx80m

-Xmsn 指定内存分配池的初始大小（以字节为单位）。该值必须是大于 1MB 的 1024 的倍数。附加字母 k 或 K 以指示千字节，或附加字母 m 或 M 以指示兆字节。默认值为 2MB。例子：

           -Xms6291456
           -Xms6144k
           -Xms6m

-Xmxn 指定内存分配池的最大大小（以字节为单位）。该值必须是大于 2MB 的 1024 的倍数。附加字母 k 或 K 以指示千字节，或附加字母 m 或 M 以指示兆字节。默认值为 64MB。例子：

           -Xmx83886080
           -Xmx81920k
           -Xmx80m

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html

http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/java.html

Java 5 and 6 have some more. See http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

Java 5 和 6 还有一些。请参阅http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

回答by VonC

Just a thought, but you may check the influence of a ulimit -voption.

只是一个想法，但你可以检查的影响一个ulimit -v选项。

That is not an actual solution since it would limit address space available for allprocess, but that would allow you to check the behavior of your application with a limited virtual memory.

这不是一个实际的解决方案，因为它会限制所有进程可用的地址空间，但这将允许您使用有限的虚拟内存检查应用程序的行为。

回答by James Schek

The amount of memory allocated for the Java process is pretty much on-par with what I would expect. I've had similar problems running Java on embedded/memory limited systems. Running anyapplication with arbitrary VM limits or on systems that don't have adequate amounts of swap tend to break. It seems to be the nature of many modern apps that aren't design for use on resource-limited systems.

为 Java 进程分配的内存量与我预期的差不多。我在嵌入式/内存有限的系统上运行 Java 时遇到过类似的问题。在具有任意 VM 限制或在没有足够交换量的系统上运行任何应用程序往往会中断。这似乎是许多现代应用程序的本质，它们不是为在资源有限的系统上使用而设计的。

You have a few more options you can try and limit your JVM's memory footprint. This might reduce the virtual memory footprint:

您还有更多选项可以尝试限制 JVM 的内存占用。这可能会减少虚拟内存占用：

-XX:ReservedCodeCacheSize=32m Reserved code cache size (in bytes) - maximum code cache size. [Solaris 64-bit, amd64, and -server x86: 48m; in 1.5.0_06 and earlier, Solaris 64-bit and and64: 1024m.]

-XX:MaxPermSize=64m Size of the Permanent Generation. [5.0 and newer: 64 bit VMs are scaled 30% larger; 1.4 amd64: 96m; 1.3.1 -client: 32m.]

-XX:ReservedCodeCacheSize=32m 保留代码缓存大小（以字节为单位）- 最大代码缓存大小。[Solaris 64 位、amd64 和 -server x86：48m；在 1.5.0_06 及更早版本中，Solaris 64 位和 and64：1024m。]

-XX:MaxPermSize=64m 永久代的大小。[5.0 及更新版本：64 位虚拟机扩展了 30%；1.4 amd64：96m；1.3.1 - 客户端：32m。]

Also, you also should set your -Xmx (max heap size) to a value as close as possible to the actual peak memory usageof your application. I believe the default behavior of the JVM is still to doublethe heap size each time it expands it up to the max. If you start with 32M heap and your app peaked to 65M, then the heap would end up growing 32M -> 64M -> 128M.

此外，您还应该将 -Xmx（最大堆大小）设置为尽可能接近应用程序实际峰值内存使用量的值。我相信 JVM 的默认行为仍然是每次将堆大小扩展到最大值时将堆大小加倍。如果您从 32M 堆开始并且您的应用程序达到 65M，那么堆最终会增长 32M -> 64M -> 128M。

You might also try this to make the VM less aggressive about growing the heap:

您也可以尝试使用此方法来降低 VM 在堆增长方面的积极性：

-XX:MinHeapFreeRatio=40 Minimum percentage of heap free after GC to avoid expansion.

-XX:MinHeapFreeRatio=40 GC 后堆空闲的最小百分比以避免扩展。

Also, from what I recall from experimenting with this a few years ago, the number of native libraries loaded had a huge impact on the minimum footprint. Loading java.net.Socket added more than 15M if I recall correctly (and I probably don't).

此外，从我几年前的试验中回忆起，加载的本机库的数量对最小占用空间产生了巨大影响。如果我没记错的话，加载 java.net.Socket 增加了超过 15M（我可能没有）。

回答by Thorbj?rn Ravn Andersen

The Sun JVM requires a lot of memory for HotSpot and it maps in the runtime libraries in shared memory.

Sun JVM 需要大量内存用于 HotSpot，它映射到共享内存中的运行时库。

If memory is an issue consider using another JVM suitable for embedding. IBM has j9, and there is the Open Source "jamvm" which uses GNU classpath libraries. Also Sun has the Squeak JVM running on the SunSPOTS so there are alternatives.

如果内存是一个问题，请考虑使用另一个适合嵌入的 JVM。IBM 有 j9，还有使用 GNU 类路径库的开源“jamvm”。此外，Sun 在 SunSPOTS 上运行了 Squeak JVM，因此还有其他选择。

回答by runholen

One way of reducing the heap sice of a system with limited resources may be to play around with the -XX:MaxHeapFreeRatio variable. This is usually set to 70, and is the maximum percentage of the heap that is free before the GC shrinks it. Setting it to a lower value, and you will see in eg the jvisualvm profiler that a smaller heap sice is usually used for your program.

减少资源有限的系统的堆空间的一种方法可能是使用 -XX:MaxHeapFreeRatio 变量。这通常设置为 70，它是 GC 收缩前空闲堆的最大百分比。将其设置为较低的值，您将在例如 jvisualvm 分析器中看到较小的堆通常用于您的程序。

EDIT: To set small values for -XX:MaxHeapFreeRatio you must also set -XX:MinHeapFreeRatio Eg

编辑：要为 -XX:MaxHeapFreeRatio 设置较小的值，您还必须设置 -XX:MinHeapFreeRatio 例如

java -XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=25 HelloWorld

EDIT2: Added an example for a real application that starts and does the same task, one with default parameters and one with 10 and 25 as parameters. I didn't notice any real speed difference, although java in theory should use more time to increase the heap in the latter example.

EDIT2：为启动并执行相同任务的真实应用程序添加了一个示例，一个使用默认参数，一个使用 10 和 25 作为参数。我没有注意到任何真正的速度差异，尽管理论上 java 应该使用更多时间来增加后一个例子中的堆。

At the end, max heap is 905, used heap is 378

最后，最大堆为 905，使用的堆为 378

At the end, max heap is 722, used heap is 378

最后，最大堆为 722，使用的堆为 378

This actually have some inpact, as our application runs on a remote desktop server, and many users may run it at once.

这实际上有一些影响，因为我们的应用程序运行在远程桌面服务器上，许多用户可能会同时运行它。

回答by Lari Hotari

There is a known problem with Java and glibc >= 2.10 (includes Ubuntu >= 10.04, RHEL >= 6).

Java 和 glibc >= 2.10（包括 Ubuntu >= 10.04，RHEL >= 6）存在一个已知问题。

The cure is to set this env. variable:

解决方法是设置这个环境。多变的：

export MALLOC_ARENA_MAX=4

If you are running Tomcat, you can add this to TOMCAT_HOME/bin/setenv.shfile.

如果您正在运行 Tomcat，则可以将其添加到TOMCAT_HOME/bin/setenv.sh文件中。

For Docker, add this to Dockerfile

对于 Docker，将此添加到 Dockerfile

ENV MALLOC_ARENA_MAX=4

There is an IBM article about setting MALLOC_ARENA_MAX https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage?lang=en

有一篇关于设置 MALLOC_ARENA_MAX 的 IBM 文章 https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage?lang=en

This blog post says

这篇博文说

resident memory has been known to creep in a manner similar to a memory leak or memory fragmentation.

众所周知，常驻内存会以类似于内存泄漏或内存碎片的方式蔓延。

There is also an open JDK bug JDK-8193521 "glibc wastes memory with default configuration"

还有一个开放的 JDK 错误JDK-8193521“glibc 使用默认配置浪费内存”

search for MALLOC_ARENA_MAX on Google or SO for more references.

在 Google 或 SO 上搜索 MALLOC_ARENA_MAX 以获取更多参考。

You might want to tune also other malloc options to optimize for low fragmentation of allocated memory:

您可能还想调整其他 malloc 选项以优化已分配内存的低碎片化：

# tune glibc memory allocation, optimize for low fragmentation
# limit the number of arenas
export MALLOC_ARENA_MAX=2
# disable dynamic mmap threshold, see M_MMAP_THRESHOLD in "man mallopt"
export MALLOC_MMAP_THRESHOLD_=131072
export MALLOC_TRIM_THRESHOLD_=131072
export MALLOC_TOP_PAD_=131072
export MALLOC_MMAP_MAX_=65536