java JVM 和内存使用 - JRun 服务器未使用完整的 PSPermGen 分配？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3529482/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
JVM and Memory Usage - JRun server not using full PSPermGen allocation?
提问by Ciaran Archer
I'm trying to understand why out ColdFusion 9 (JRun) server is throwing the following error:
我试图了解为什么 ColdFusion 9 (JRun) 服务器会抛出以下错误：
java.lang.OutOfMemoryError: requested 32756 bytes for ChunkPool::allocate. Out of swap space?
The JVM arguments are as follows:
JVM 参数如下：
-server -Dsun.io.useCanonCaches=false -XX:MaxPermSize=192m -XX:+UseParallelGC -
I had jconsole running when the dump happened and I am trying to reconcile some numbers with the -XX:MaxPermSize=192msetting above. When JRun died it had the following memory usage:
发生转储时，我让 jconsole 运行，并且我正在尝试将一些数字与上述-XX:MaxPermSize=192m设置进行协调。当 JRun 死亡时，它的内存使用情况如下：
Heap
PSYoungGen total 136960K, used 60012K [0x5f180000, 0x67e30000, 0x68d00000)
eden space 130624K, 45% used [0x5f180000,0x62c1b178,0x67110000)
from space 6336K, 0% used [0x67800000,0x67800000,0x67e30000)
to space 6720K, 0% used [0x67110000,0x67110000,0x677a0000)
PSOldGen total 405696K, used 241824K [0x11500000, 0x2a130000, 0x5f180000)
object space 405696K, 59% used [0x11500000,0x20128360,0x2a130000)
PSPermGen total 77440K, used 77070K [0x05500000, 0x0a0a0000, 0x11500000)
object space 77440K, 99% used [0x05500000,0x0a043af0,0x0a0a0000)
My first question is that the dump shows the PSPermGenbeing the problem - it says the total is 77440K, but it should be 196608K (based on my 192m JVM argument), right? What am I missing here? Is this something to do with the other non-heap pool - the Code Cache?
我的第一个问题是转储显示PSPermGen问题所在——它说总数是 77440K，但它应该是 196608K（基于我的 192m JVM 参数），对吧？我在这里错过了什么？这与另一个非堆池 - 代码缓存有关吗？
I'm running on a 32bit machine, Windows Server 2008 Standard. I was thinking of increasing the PSPermGenJVM argument, but I want to understand why it doesn't seem to be using its current allocation.
我在 32 位机器上运行，Windows Server 2008 Standard。我正在考虑增加PSPermGenJVM 参数，但我想了解为什么它似乎没有使用其当前分配。
Thanks in advance!
提前致谢！
回答by Stephen C
An "out of swap space" OOME happens when the JVM has asked the operating system for more memory, and the operating system has been unable to fulfill the request because all swap (disc) space has already been allocated. Basically, you've hit a system-wide hard limit on the amount of virtual memory that is available.
当 JVM 要求操作系统提供更多内存时，就会发生“交换空间不足”OOME，而操作系统无法满足请求，因为所有交换（磁盘）空间都已分配。基本上，您已经达到了系统范围内可用虚拟内存量的硬限制。
This can happen through no fault of your application, or the JVM. Or it might be a consequence of increasing -Xmxetc beyond your system's capacity to support it.
这可能不是由于您的应用程序或 JVM 的错误而发生的。或者它可能是增加-Xmxetc 超出系统支持它的能力的结果。
There are three approaches to addressing this:
有三种方法可以解决这个问题：
Add more physical memory to the system.
Increase the amount of swap space available on the system; e.g. on Linux look at the manual entry for
swaponand friends. (But be careful that the ratio of active virtual memory to physical memory doesn't get too large ... or your system is liable to "thrash", and performance will drop through the floor.)Cut down the number and size of processes that are running on the system.
向系统添加更多物理内存。
增加系统上可用的交换空间量；例如，在 Linux 上查看手册条目供
swapon朋友们使用。（但要注意活动虚拟内存与物理内存的比率不要太大......否则你的系统很容易“崩溃”，性能会下降。）减少系统上运行的进程的数量和大小。
If you got into this situation because you've been increasing -Xmxto combat other OOMEs, then now would be good time to track down the (probable) memory leaks that are the root cause of your problems.
如果您遇到这种情况是因为您一直在增加-Xmx与其他 OOME 的斗争，那么现在是追踪（可能的）内存泄漏的好时机，这些（可能的）内存泄漏是您的问题的根本原因。
回答by Aaron
"ChunkPool::allocate. Out of swap space" usually means the JVM process has failed to allocate memory for its internal processing.
“ChunkPool::allocate.Out of swap space”通常意味着JVM进程未能为其内部处理分配内存。
This is usually not directly related to your heap usage as it is the JVM process itself that has run out of memory. Check the size of the JVM process within windows. You may have hit an upper limit there.
这通常与您的堆使用没有直接关系，因为 JVM 进程本身已耗尽内存。在 Windows 中检查 JVM 进程的大小。您可能在那里达到了上限。
This bug report also gives an explanation. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5004956
这个错误报告也给出了解释。 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5004956
This is usually caused by native, non java objects not being released by your application rather than java objects on the heap.
这通常是由于应用程序未释放本机非 java 对象而不是堆上的 java 对象造成的。
Some example causes are:
一些示例原因是：
- Large thread stack size, or many threads being spawned and not cleaned up correctly. The thread stacks live in native "C" memory rather than the java heap. I've seen this one myself.
- Swing/AWT windows being programatically created and not dispoed when no longer used. The native widgets behind AWT don't live on the heap as well.
- Direct buffers from nio not being released. The data for the direct buffer is allocated to the native process memory, not the java heap.
- Memory leaks in jni invocations.
- Many files opened an not closed.
- 大线程堆栈大小，或产生许多线程但未正确清理。线程堆栈位于本机“C”内存中，而不是 Java 堆中。我自己见过这个。
- Swing/AWT 窗口以编程方式创建，不再使用时不会处理。AWT 背后的本机小部件也不存在于堆中。
- 来自 nio 的直接缓冲区没有被释放。直接缓冲区的数据分配给本机进程内存，而不是 Java 堆。
- jni 调用中的内存泄漏。
- 许多文件打开一个未关闭。
I found this blog helpfull when diagnosing a similar problem. http://www.codingthearchitecture.com/2008/01/14/jvm_lies_the_outofmemory_myth.html
我发现这个博客在诊断类似问题时很有帮助。 http://www.codingthearchitecture.com/2008/01/14/jvm_lies_the_outofmemory_myth.html
回答by Manikandan
Check your setDomainEnv.cmd (.sh)file. there will be three different conditions on PermSize -XX:MaxPermSize=xxxm -XX:PermSize=xxxm. Change everywhere
检查您的 setDomainEnv.cmd (.sh) 文件。PermSize -XX:MaxPermSize=xxxm -XX:PermSize=xxxm 会有三种不同的条件。随处改变
