Is setting xmx == xms is still good practice in java-11 with G1 gc?
I ask this in the context of web applications.
For G1 GC, it is recommended to explicitly set the maximum and minimum heap size to the same value to avoid dynamic shrinking and growing of the heap during the applications lifecycle.
https://backstage.forgerock.com/knowledge/kb/article/a75965340
Related
I want to know if I use Spring-Native, do I still need to configure what garbage collector to use, how much heap memory to set and other JVM startup parameters, do I not need to configure any of these at all? If so, then the actual memory occupied by the application is the actual memory used and no more space will be opened up in advance because of setting the heap size?
Depending on the nature of the automated workflow and the number of active threads at any given time the Heap size requirement for JMeter can vary and in the testing I am doing there is some ambiguity with respect to the affect of Heap size on the test results. The initial Heap size and the maximum Heap size of the server hosting JMeter is shown in the attached screenshot.
Upon executing the test for a large set of current users (eg:100) the in built JMeter report does not render however the results can be seen in the CSV output. Will increasing the Heap size solve this issue and if so to how much should we increase the Heap size?. Note that this issue does not happen for a small user count such as 10 or 15.
What is the recommended industrial standard value for Heap size and other system variables for a server used for commercial performance testing using JMeter.
There is no "recommended industrial standard".
Each test is individual and you need to tune JMeter appropriately.
As of JMeter 5.5 default heap size is 1GB which is sufficient for tests development and debugging but might be not sufficient for the load you're trying to conduct.
According to this article:
"If the occupancy of the Java heap is too high, garbage collection occurs frequently. If the occupancy is low, garbage collection is infrequent but lasts longer... Try to keep the memory occupancy of the Java heap between 40% and 70% of the Java heap size... The highest point of occupancy of the Java heap is preferably not above 70% of the maximum heap size, and the average occupancy is between 40% and 70% occupancy. If the occupancy goes over 70%, resize the Java heap."
So I would recommend checking what's going on with your heap using JVisualVM or equivalent and adjusting it up or down as needed.
If your test runs fine and you're experiencing OOM issues only during dashboard generation you can increase it temporarily by setting the relevant HEAP environment variable value.
As per IBM link (https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/openj9/xgcpolicy/index.html), the gc policy can be specified by setting by -Xgcpolicy. Default gcpolicy is gencon (-Xgcpolicy:gencon). WAS is 9.0 and JVM is IBM J9 (Java version 1.8).
Next, from the below link of IBM it seems that the setting of the gc algorithm is also possible using flag -XX, like in other JVM. E.g: -XX:+UseG1GC can work.
https://www.ibm.com/support/knowledgecenter/en/SS3KLZ/com.ibm.java.diagnostics.visualizer.doc/verbosegc.html
My intention is to apply the gc behavior like of UseG1GC. The heap size is -Xms16G to -Xmx20G. So, I wish to go for Garbase First and concurrent that is UseG1GC. The -Xgcpolicy:gencon also does somewhat similar but it cause the "stop the world". When gc is running the application gets suspension.
Little confused that even if I set the -XX:+UseG1GC, will it follow and be effective to UseG1GC behavior or it will follow the mechanism of -Xgcpolicy:gencon? Or the gcpolicy and gc algorithm are two different things?
There is no effect of using -XX:+UseG1GC on IBM JVM. It will just be silently swallowed. The JVM will default to Gencon GC policy.
You can verify that by running -verbose:gc, what will reported GC policy being used.
The closest IBM's GC policy to Hotspot's G1GC is Balanced one, the main distinguishing characteristics being they are region based (unlike Gencon that has two distinct ares of heap for old and new objects).
As far as concurrency, all 3 (G1GC, Balanced, Gencon) are similar: global GCs are mostly concurrent and partial/local GCs are STW (Stop-The-World).
Reasons to use region based GC policy are to reduce worst case pause time. They are capable of doing some global type operations incrementally in partial GCs. Most notably, they can incrementally de-fragment heap, unlike Gencon, that it does in global GC via optional STW compact operation. Most of applications will not require such global compact, hence Gencon is default. But, if long pauses due to global compaction are observed in Gencon run, Balanced should be tried. Balanced GC will however slightly compromise the application throughput.
1) Our application: Spring boot, Java 8
2) Parameters we use: xms = 256 MB, xmx = 2 GB
We have been seeing that used heap size of our java8 applications are not shrinking back down when appropriate.
Any other parameters that we should be using along with #2 above, when launching our spring boot/Java 8 application, so that GC can do a better job?
Thanks for your help!
The above options have the following effect:
-Xms, -Xmx: Places boundaries on the heap size to increase the predictability of garbage collection. The heap size is limited in replica servers so that even Full GCs do not trigger SIP retransmissions. -Xms sets the starting size to prevent pauses caused by heap expansion.
-XX:+UseG1GC: Use the Garbage First (G1) Collector.
-XX:MaxGCPauseMillis: Sets a target for the maximum GC pause time. This is a soft goal, and the JVM will make its best effort to achieve it.
-XX:ParallelGCThreads: Sets the number of threads used during parallel phases of the garbage collectors. The default value varies with the platform on which the JVM is running.
-XX:ConcGCThreads: Number of threads concurrent garbage collectors will use. The default value varies with the platform on which the JVM is running.
-XX:InitiatingHeapOccupancyPercent: Percentage of the (entire) heap occupancy to start a concurrent GC cycle. GCs that trigger a concurrent GC cycle based on the occupancy of the entire heap and not just one of the generations, including G1, use this option. A value of 0 denotes 'do constant GC cycles'. The default value is 45.
Oracle JDK provides inbuilt Java VisualIVM tool to analyze and tune GC factors
I am trying to build a large Maven-GWT project on a virtual host, which has a limit amount of RAM and cannot use swap space.
The GWT compile stage (where it computes permutations) uses a massive amount of the CPU and memory, and I was wondering if there was any way I could impose a limit on how much of each it uses, even if it takes much longer to compile.
Thanks
If you are using more than one worker thread, decrease it to just one worker thread - that will decrease the memory required. however, the compile will be correspondingly slower. Otherwise, there isn't much you can do to decrease the memory requirements. Setting the xmx to a lower number will work too, but that will cause OOME if it is too low. i think about 256m is the minimum, tho 128m works for most projects of a small to medium size.
add -Dgwt-plugin.localWorkers="1" and -Dgwt-plugin.extraJvmArgs="-Xmx128m -Xms16m" to your MAVEN_OPTS, and tweak those numbers till it works nicely.