Kindly tell me the purpose of those options.
After googling I think:
MinHeapFreeRatio tells "specified minimum percentage of space will be ensured to be free in heap memory after a GC"
and
MaxHeapFreeRatio tells "no more than specified percentage of space will be free in heap memory after a GC" [if there is excess free memory than the specified percentage, those memory will be returned to OS]
When i tried these options with 10 as value for both, even where there is more than 80 percentage of free heap memory, it was not released back to OS.
Details:
Java HotSpot(TM) 64-Bit Server VM (1.5.0_15-b04, mixed mode)
ParallelGC (otherwise known as throughput collector which is the default collector in server class VM)
i specified -Xms50M and -Xmx1000M as jvm arguments
OS: windows 7 professional (8 GB memory 64 bit OS)
Note: i just tried with SerialGC too, those min and max heap free ratio options were ignored.
The best explanation of the parameters -XX:MinHeapFreeRatio and -XX:MaxHeapFreeRatio parameters are available in the oracle garbage documentation:
https://docs.oracle.com/javase/10/gctuning/factors-affecting-garbage-collection-performance.htm
-XX:MinHeapFreeRatio=40
-XX:MaxHeapFreeRatio=70
With these options, if the percent of free space in a generation falls below 40%, then the generation expands to maintain 40% free space, up to the maximum allowed size of the generation. Similarly, if the free space exceeds 70%, then the generation contracts so that only 70% of the space is free, subject to the minimum size of the generation.
I combine it with the G1GC in this way:
-XX:+UseG1GC -XX:MinHeapFreeRatio=2 -XX:MaxHeapFreeRatio=10
With this result:
Java very rarely releases memory back to the OS.
Generally speaking, applications use more memory over time rather than less. Are you sure you memory is so limited that you need this? Are you sure you are checking the resident memory not the virtual memory size which will be about 1.2 GB in your case all the time.
Related
i have sent heap size to -Xmx512m -XX:MaxPermSize=14336m but still i'm getting out of memory error.
could you please help me in explaining that how much heapmemory can we set in windows8 machine(Ram size 16GB)
As discussed in This question here, the MaxPermSize argument is the
maximum size for the permanent generation heap, a heap that holds the byte code of classes and is kept separated from the object heap containing the actual instances
While the flag Xmx is responsible for the memory where instances are created. Now I don't understand your application but I personally do not believe you need ~14GB of byte-code cached in it. Try potentially changing your Max heap Size (Xmx) rather than perm size and see how that turns out, seeing as the most likely cause is that you are creating too many instances for the memory you have allocated.
As much as your physical ram + virtual memory. See my virtual memory below.
Do not forget that all of this memory is shared among your processes, therefore you should close all unnecessary applications when your memory hungry processes work.
To see your virtual memory information.
System -> Advanced System Settings -> Advanced Tab
See following Microsoft help for more information.
Change the size of virtual memory
.
You seem to misunderstand what heap and what permgen space really does:
Perm space vs Heap space
You need to increase heap size: e.g. -Xmx1g. MaxPermSize should be limited to maybe 300m. The value you used like 14G is simply too high and IMHO of no practical use.
Watch out for your Java VM. 32Bit JavaVM can only address around 1.2G (sum of heap and perm gen) while 64Bit Java could address larger heaps like e.g. 8g.
If you are looking at sonars documentation: http://docs.codehaus.org/display/SONAR/Analyzing+with+SonarQube+Runner you see, they mention 128m perm size.
I have an application running with -mx7000m. I can see it's allocated 5.5 GB heap. Yet for some reasons it's GCing constantly, and that being CMS it turns out to be quite CPU intensive. So, it has 5.5 GB heap already allocated, but somehow it's spending all the CPU time trying to keep the used heap as small as possible, which is around 2 GB - and the other 3.5G are allocated by JVM but unused.
I have a few servers with the exact same configuration and 2 out of 5 are behaving this way. What could explain it?
It's Java 6, the flags are: -server -XX:+PrintGCDateStamps -Duser.timezone=America/Chicago -Djava.awt.headless=true -Djava.io.tmpdir=/whatever -Xloggc:logs/gc.log -XX:+PrintGCDetails -mx7000m -XX:MaxPermSize=256m -XX:+UseConcMarkSweepGC
The default threshold for triggering a CMS GC is 70% full (in Java 6). A rule of thumb is that the heap size should be about 2.5x the heap used after a full GC (but your use case is likely to be different)
So in your case, say you have
- 2.5 GB of young generation space
- 3 GB of tenured space.
When you tenured space reached 70% or ~2.1GB, it will start cleaning up the region.
The setting involved is the -XX:CMSInitiatingOccupancyFraction=70
However, if you want to reduce the impact GC, the simplest thing to do is to create less garbage. i.e. use a memory profiler and ensure you allocation rate is as low as possible. Your system will run very different if you are creating as much garbage as the CPUs can handle to say 100 MB/s or 1 MB/s or less.
The reason you might have different servers running differently as the relative sizes of the region might be different, say you have 0.5 young and 5.0 GB tenured, you shouldn't be seeing this. The difference could be purely down to how busy the machine was when you started the process or what it did since then.
Suppose the maximum size of a JVM heap is 2GB (-Xmx2048m -Xms100m), we find that the peak used usage of this heap is 1GB and the peak committed usage is 1.2GB after it finishes. So, my question is whether the free space (2GB - 1.2GB) can be consumed by other applications while the JVM is running.
I think the free space cannot be used by others but I'm not sure currently: The operating system reserves 2GB free space before the JVM runs. The reserved space may not be consumed by other applications though the JVM cannot use it up.
JVM checks whether OS has enough address space for -Xmx, but OS won't actually allocate the memory until that much is requested by JVM. JVM will only reserve -Xms memory but can extend upto -Xmx provided that much memory is available.
Runtime.getRuntime().totalMemory() will return the current size of the heap, which will not exceed the maximum size specified on the command line.
That is approximately the amount of memory assigned to the JVM (not including non-heap JVM memory) by the operating system. Other memory is free for use by other applications.
Of course that is grossly oversimplified -- total system memory is total physical memory + total available swap, with other complications (e.g. Linux makes promises of memory to processes but doesn't actually commit it to that process unless it is touched, also simplified). In any case though, the short answer is: Yes, you specify a maximum size on the command line, but the current size is what is allocated to the JVM; the rest is available for other applications.
The memory seen by Java process is virtual memory. The operating system doesn't need to really reserved 2GB free physical memory for Java process.
I am using below GC memory parameters :
export MEM_OPTS="-Xmx2900m -Xms2900m -XX:NewSize=786m -XX:MaxNewSize=786m -XX:+UseTLAB -XX:MaxPermSize=128m"
I am using 32 bit JVM.My server RAM is 10 GB.
From Oracle site, I got
Why can't I get a larger heap with the 32-bit JVM?
The maximum theoretical heap limit for the 32-bit JVM is 4G. Due to various additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower. On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G. On 64-bit operating systems running the 32-bit VM, the max heap size can be higher, approaching 4G on many Solaris systems.
As of Java SE 6, the Windows /3GB boot.ini feature is not supported.
If your application requires a very large heap you should use a 64-bit VM on a version of the operating system that supports 64-bit applications. See Java SE Supported System Configurations for details.
Ok.Now lets assume my 32 bit server can take 3.2 GB.As i know :
-Xmx is the total heap memory
-XX:NewSize / -XX:MaxNewSize is the range of the size of the new generation inside that heap
the difference is the range of the size of the old generation
-XX:PermSize / -XX:MaxPermSize is the range of the size of the permanent generation, which is the non-heap memory
According to this, 3.2 GB should not include PermSize as this is a not a heap content.Right ?
Let me know if am wrong.
I can divide 3.2 GB in Xmx and NewSize . Right ?
The NewSize is a portion of the maximum heap size. It must be smaller.
I would use the 64-bit JVM if you have Java 6 as it will make your life simpler. ;) Unless you have to use 32-bit share libraries, there is little down side.
BTW -XX:+UseTLAB is the default.
I have a java app that uses about 15G on a machine with 16G. I don't know if I should set the max heap size.
If set will the jvm eat all the ram up to the limit and then start garbage collecting and stop everything while it churns through 15G of heap objects?
If not will the jvm hurt performance by not using all of the available ram on the machine.
My specific vm is: Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode).
Thanks
-Xmx15G will set the maximum heap size to 15 gig. Java will only allocate what it needs as it runs. If you don't set it, it will only use the default. For info on the default, see this post.
-Xms15G sets the minimum heap to 15 gig. This forces java to allocate 15 gig of heap space before it starts executing, whether it needs it or not.
Usually you can set them both to appropriate values depending on how you're tuning the JVM.
In Java 6, the default maximum heap size is determined by the amount of system memory present.
According to the Garbage Collector Ergonomics page, the maximum heap size is:
Smaller of 1/4th of the physical
memory or 1GB. Before J2SE 5.0, the
default maximum heap size was 64MB.
By using the -Xmx switch can be used to change the maximum heap size. See the java - the Java application launcher documentation for usage details.
If you don't set a max heap size (with -Xmx), isn't the default maximum only 64MB?
So won't your application fail with OutOfMemoryErrors if you don't set it? I'm confused on this question. How can your application run without this switch?