Differences

This shows you the differences between two versions of the page.

--- java [2012/12/05 00:07]
a [Tunning]
+++ java [2012/12/07 12:29] (current)
a
@@ Line 12: / Line 12: @@
-===== Tunning  =====
+===== Tuning  =====
 {{ :memoryjvm.png?nolink |}}
 ^ switch ^ description ^
-| **-Xmx**   | **maximum java heap size** - defines the max memory size that the heap can reach for the JVM. You must know your program well and see how it performs under load and set this parameter accordingly. A low value can cause OutOfMemoryExceptions or a very poor performance if your program's heap memory is reaching the maximum heap size. If your program is running in dedicated server you can set this parameter higher because it wont affect other programs |
+| **-Xmx**   | **Maximum Java heap size** - defines the maximum memory size that the heap can reach in the JVM. You must know your program well and see how it performs under load and set this parameter accordingly. A low value will probably cause OutOfMemoryExceptions or very poor performance if your programs heap memory is reaching the maximum heap size. On a dedicated server this should be set as high as available memory allows (within reason). |
-| **-Xms**   | **initial java heap size**  - sets the initial heap memory size for the JVM. This means that when you start your program the JVM will allocate this amount of memory instantly. This is useful if your program will consume a large amount of heap memory right from the start. This avoids the JVM to be constantly increasing the heap and can gain some performance there. If you don't know if this parameter is going to help you, **don't use it**.  |
+| **-Xms**   | **Initial Java heap size**  - sets the initial heap memory size for the JVM. This means that when you start your program the JVM will allocate this amount of memory instantly. This is useful if your program consumes large amount of memory right after starting up. This avoids constant heap expansion (via memory reallocations) and result in significant performance gains at startup if the program does alot of small allocations. If you don't know if this parameter is going to help you, **don't use it**.  |
-| **-Xmn** | **the size of the heap for the young generation** -Young generation represents all the objects which have a short life of time. Young generation objects are in a specific location into the heap, where the garbage collector will pass often. All new objects are created into the young generation region (called "eden"). When an object survive is still "alive" after more than 2-3 gc cleaning, then it will be swap has an "old generation" : they are "survivor" . Good size is 33%  |
+| **-Xmn** | **Size of the heap for the young generation** - young generation represents all the objects which have a short life of time. Young generation objects are allocated in a specific location into the heap, where the garbage collector will pass often. All new objects are created into the young generation region (called "eden"). When an object survives after more than 2-3 gc cleaningsit will be moved into "survivor" heap space and later to "tenured" space. Small eden size speeds up GC passes, however you need to make sure you can fit short-lived objects into that space. Good size is 33% of all heap space. |
-| **-Xss** | the stack size for each thread |
+| **-Xss** | ** Stack size for each thread ** - This sets size of preallocated stack for each thread. If you set this too low your program will crash with StackOverflowExceptions. Setting this too high will cause excessive memory usage - this amount of memory gets allocated for **each** thread in the JVM. The default for most JVMs is 512k. Note: When increasing this number on Linux, you will probably have to also increase native stack size to same amount with "ulimit -s" |
 | ||
-| **-XX:NewRatio** | the same as Wmn, but using a % (dynamic fs static -Xmn option) **-XX:NewRatio=3** means that the ratio between the old and young generation is 1:3 |
+| **-XX:NewRatio** | Same as Xmn, but using a % (dynamic fs static -Xmn option) **-XX:NewRatio=3** means that the ratio between the old and young generation is 1:3 |
 | **-XX:NewSize**  | Size of the young generation at JVM init. Calculated automatically if you specify -XX:NewRatio |
 | **-XX:MaxNewSize** | The largest size the young generation can grow to (unlimited if this v alue is not specified at command line) |
-| **-XX:SurvivorRatio** | "old generation" called tenured generation, ratio, in %. For example, -XX:SurvivorRatio=6 sets the ratio between each survivor space and eden to be 1:6 (eden is where new objects are created) |
+| **-XX:SurvivorRatio** | "survivor" generation ratio, in %. For example, -XX:SurvivorRatio=6 sets the ratio between each survivor space and eden to be 1:6 (eden is where new objects are created) |
-| **-XX:MinHeapFreeRatio** | default is 40%. JVM will allocate memory to always have as minimum 40% of free memory. When -Xmx = -Xms, it's useless. |
+| **-XX:MinHeapFreeRatio** | When JVM heap usage reaches this percentage of allocated heap JVM will allocate additional memory up to the Xmx limit. When Xmx == Xms, it's useless. Default is 40%. |
-| **-XX:MaxHeapFreeRatio:** | default is 70%. The same as Min, to avoid unecessary memory allocation. |
+| **-XX:MaxHeapFreeRatio:** | When JVM heap usage passes below this treshold, JVM will release allocated heap memory to the OS to avoid unecessary memory allocation. Default is 70%. |
 <note important>
 **A nice gotcha...** \\
-Major collection don't run until tenured is full.
+Full-heap major garbage collection **will not** run until the tenured part of heap is full. This means if you have heap size (Xmx) of 1024MB with 750MB of heap allocated and your program has only 250MB of objects actually reachable ("alive") GC **still** won't run until whole 1024MB of heap is filled up.
-This mean that using -Xmx1024, current heap could be 750MB with 500MB of "dead" object. If the JVM is idle, it could stay like that during a very long time => wasting 500MB or RAM for an idle JVM !
+This is by design - it improves performance. Don't give JVM more heap space than you're actually willing to lose.
 </note>
@@ Line 41: / Line 42: @@
 </note>
-==== Good/best practices ====
+==== Choosing the garbage collector ====
-==== Examples ====
+In Sun/Oracle JVM you have a choice of three garbage collectors, each built for different use case.
+  * **Serial collector** - single-threaded, **+XX:UseSerialGC**
+  * **Parallel collector** - does small passes in parallel, **+XX:UseParallelGC** and **+XX:UseParallelOldGC**
+  * **Concurrent collector** - does most of the collection in other threads, minimizes pauses, **+XX:UseConcMarkSweepGC**
+=== Serial collector ===
+Is the efficient (no intra-thread communication) of the three. Stops the world while running collection.
+**Best for**: applications running on single-core, applications with small datasets (up to 100MB), applications with no pause-time requirements
+=== Parallel collector ===
+Does minor collection (eden) in parallel thus greatly reducing garbage collection overhead on multi-core machines. With **+XX:UseParallelOldGC** is also does major collection and compation in parallel thus further reducing pause time for garbage collection on multi-core machines. It uses more memory and has slower full-passes than serial collector.
+**Best for**: applications with medium to large datasets (100MB+), applications that run on multi-core machines, application where peak throughput is the priority and pauses of 1 sec are acceptable.
+=== Concurrent collector ===
+Does most of it's work concurrently while other application threads are still running. It keeps garbage collection pauses the shortest possible at the expense of total garbage collection time and increased memory usage. The maximum response time is achieved at the cost of total application throughput so this GC may reduce total application performance at the expense of maximizing response time.
+**Best for**: applications with medium to large datasets (100MB+) which require minimal response time (with pauses required to be less than 1 sec).
+<note important>
+** Concurrent GC on machines with 2 cores **
+During each concurrent GC phase a whole core is pinned to the GC and is not available to the rest of the application. Due to long running passes of concurrent GC this may not be desireable on machines with only two cores.
+Enabling **incremental mode** for concurrent GC will cause the GC to do each pass in several phasses while relinquishing CPU to the application inbetween. This causes the core to be available to the application for more time at the expense of further prolonging the GC passes. Incremental mode is enabled with **-XX:+CMSIncrementalMode**.
+</note>
+[[http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html|More information on Java GC tuning at Oracle.]]
+===== Good/best practices =====
+. OpenJDK 1.6 and 1.7 may (as of now, 6. 12. 2012) still be unstable in stressful production environments leading up to segmentation faults and unintended behaviour. Use Sun/Oracle JVM for maximum stability and performance.
+===== Examples =====
 tying to limit jvm to ~2G of RAM (java x86_64)
@@ Line 50: / Line 90: @@
 java (i386)
     java -Xms1400m -Xmx2G -XX:MaxPermSize=128m -server
-==== Troubleshooting ====
+===== Troubleshooting =====
 === Resolving java.lang.OutOfMemoryError: PermGen ===
@@ Line 63: / Line 104: @@
 (Note that Xmx is separate from the PermGen space, so increasing Xmx will not help with the PermGen errors). \\
 **The PermGen memory in addition to the Xmx memory.  e.g. -Xmx128m and MaxPermSize=128m would use up to 256MB.**