In this video I explain some 21 JVM parameters which are suited for most server applications. If you have any questions, you can read those links below for more information or just ask in the comments section.
I run several Java enterprise server applications. I often wondered – what are the best „default“ JVM settings for a server application to start with in production? I read a lot on the web and tried several things myself and wanted to share what I found out, so far. Links containing more information about JVM optimization can be found here:
http://blog.sokolenko.me/2014/11/javavm-options-production.html
http://www.petefreitag.com/articles/gctuning/
http://stas-blogspot.blogspot.de/2011/07/most-complete-list-of-xx-options-for.html
So let’s start:
-server
Use „-server“: All 64-bit JVMs use the server VM as default anyway. This setting generally optimizes the JVM for long running server applications instead of startup time. The JVM will collect more data about the Java byte code during program execution and generate the most efficient machine code via JIT.
-Xms=<heap size>[g|m|k] -Xmx=<heap size>[g|m|k]
The „-Xmx/-Xms“ settings specify the maximum and minimum values for the JVM heap memory. For servers, both params should have the same value to avoid heap resizing during runtime. I’ve applications running with 16GB heap sizes without an issue.
Depending on your application, you will have to try out how much memory will be best suited for your use case.
-XX:MaxMetaspaceSize=<metaspace size>[g|m|k]
Java 8 has no „Permanent Generation“ (PermGen) anymore but requires additional „Metaspace“ memory instead. This memory is used, in addition to the heap memory we specified before, for storing class meta data information.
The default size will be unlimited – I tend to limit MaxMetaspaceSize with a somewhat high value. Just in case something goes wrong with the application, the JVM will not hog all the memory of the server.
I suggest: Let your application run for a couple of days to get a feeling for how much Metaspace Size it uses normally. Upon next restart of the application set the limit to e.g. double the value.
-XX:+CMSClassUnloadingEnabled
Additionally, you might want to allow the JVM to unload classes which are held in memory but no code is pointing to them any more. If your application generates lots of dynamic classes, this is what you want.
-XX:+UseConcMarkSweepGC
This option makes the JVM use the ConcurrentMarkSweepGC – It can do much work in parallel to program execution but in some circumstances a „full GC“ with a „STW pause“ might still occur. I’ve read many articles and came to the conclusion that this GC is still the best one for server workloads.
-XX:+CMSParallelRemarkEnabled
The option CMSParallelRemarkEnabled means the remarking is done in parallel to program execution – which is what you want if your server has many cores (and most servers do).
-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=<percent>
Normally the GC will use heuristics to know when it’s time to clear memory. GC might kick in too late with default settings (causing full-Gcs).
Some sources say it might be a good idea to disable heuristics altogether and just use generation occupancy to start a CMS collection cycle. Setting values around 70% worked fine for all of my applications and use cases.
-XX:+ScavengeBeforeFullGC
The first option tells the GC to first free memory by clearing out the „young generation“ or fairly new objects before doing a full GC.
-XX:+CMSScavengeBeforeRemark
CMSScavengeBeforeRemark does attempt a minor collection before the CMS remark phase – thus keeping the remark pause afterwards short.
-XX:+CMSClassUnloadingEnabled
The option „-XX:+CMSClassUnloadingEnabled“ here tells the JVM to unload classes, which are not needed any more by the running application. If you deploy war files to an application server like wildfly, tomcat or glassfish without restarting the server after the deployment, this flag is for you.
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
The option „-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses“ is especially important if your application uses RMI (remote method invocation). The usage of RMI will cause the JVM to do a FULL-GC EVERY HOUR! This might be a very bad idea for large heap sizes because the FULL-GC pause might take up to several seconds. It would be better to do a concurrent GC and try to unload unused classes to free up more memory – which is exactly what the second option does.
-XX:+PrintGCDateStamps -verbose:gc -XX:+PrintGCDetails -Xloggc:"<path to log>"
These options shown here will write out all GC related information to a specified log file. You can see how well your GC configuration works by looking into it.
I personally prefer to use the „Visual GC“ plug in for the „Visual VM“ tool to monitor the general JVM and GC behavior.
-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path to dump>`date`.hprof
When your JVM runs out of memory, you will want to know why. Since the OOM error might be hard to reproduce and you want to get your production server up and running again – you should specify a path for a heap dump. When things have settled down, you can analyze the dump afterwards.
-Djava.rmi.server.hostname=<external IP> -Dcom.sun.management.jmxremote.port=<port>
These options will help you to specify an IP and port for JMX – you will need those ports open to connect remotely to a JVM running on a server for tools like VisualVM. You can gain deep insights over cpu and memory usage, gc behaviour, class loading, thread count and usage of your application this way.
Lastly, I would like to recommend to you the VisualVM tool which is bundled with the Java 8 JDK. You can use it to gain more insights about your specific application behaviour on the JVM – like cpu and memory usage, thread utilisation and much more.
VisualVM can be extended with a plug in called „Visual GC“. It will briefly show you VERY detailed information about the usage of the young and old generation object spaces. You can easily spot problems with garbage collection simply by analyzing these graphs during application runtime.
Thank you very much for watching! If you liked the video you might consider giving it a „thumbs up“. If you have any questions – just put them in the comments section. I will reply as quickly as possible.
-------------------------------------------------------
-XX:+UseCompressedOops [If Max Heap allocation is less than 32GB]
This can save a significant amount of memory and this option should already be enabled by default on recent java 8 versions. This option allowes object references to be stored as 32-bit values instead of 64-bit on 64-bit JVMs. This leads to before mentioned memory savings.
-XX:+AggressiveOpts
This option will enable performance options which are hoped to become enabled by default in upcoming released of the JVM. This option sets some performance settings but is marked as experimental! So you should only enable it, when you have to possibility to test your application thoroughly before enabling this flag on an production server.
-XX:+UseStringDeduplication
Since Java 8 update 20 you can use this option to reduce the memory usage of your application. The JVM will spot identical strings in memory, remove the duplicated and point all references to the remaining, single instance of the string.
-XX:+UseG1GC
Will tell the JVM to use the most recent G1 garbage collector. You are trading better application response times (due to shorter gc times with G1) against lower throughput (compared against good old ConcMarkSweepGC / CMS). If your application can deliver more value through short gc times, then G1 is definately better suited. Otherwise on Java 8, I’d recommend sticking with CMS.
Concerning your Tomcat 8 question, I’d suggest you have a look into it with the „VisualVM“ tool. Look at memory usage, GC times (visual GC plugin), pull and analyse stack traces or thread dumps to find the weak spot. You might also consider attaching a debugger to tomcat to find the bug.
https://www.maknesium.de/21-most-important-java-8-vm-options-for-servers
]]>
Optimising Your Minecraft: Jvm Arguments
https://xealgaming.net/threads/optimising-your-minecraft-jvm-arguments.4758/
]]>
PermantSpace涓昏璐熻矗瀛樻斁鍔犺澆鐨?a style="color: #075db3;">Class綾葷駭瀵硅薄濡俢lass鏈韓錛?a style="color: #075db3;">method錛宖ield絳夊弽灝勫璞★紝涓鑸笉鐢ㄩ厤緗?/p>
JVM鐨凥eap鍖哄彲浠ラ氳繃-X鍙傛暟鏉ヨ瀹氥侶eapSpace= {Old + NEW {= Eden , from, to } }
褰撲竴涓猆RL琚闂椂錛屽唴瀛樼敵璇瘋繃紼嬪涓嬶細
- JVM浼氳瘯鍥句負鐩稿叧Java瀵硅薄鍦‥den涓垵濮嬪寲涓鍧楀唴瀛樺尯鍩?nbsp;
- 褰揈den絀洪棿瓚沖鏃訛紝鍐呭瓨鐢寵緇撴潫銆傚惁鍒欏埌涓嬩竴姝?nbsp;
- JVM璇曞浘閲婃斁鍦‥den涓墍鏈変笉媧昏穬鐨勫璞★紙榪欏睘浜?鎴栨洿楂樼駭鐨勫瀮鍦懼洖鏀訛級, 閲婃斁鍚庤嫢Eden絀洪棿浠嶇劧涓嶈凍浠ユ斁鍏ユ柊瀵硅薄錛屽垯璇曞浘灝嗛儴鍒咵den涓椿璺冨璞℃斁鍏urvivor鍖?/li>
- Survivor鍖鴻鐢ㄦ潵浣滀負Eden鍙奜LD鐨勪腑闂翠氦鎹㈠尯鍩燂紝褰揙LD鍖虹┖闂磋凍澶熸椂錛孲urvivor鍖虹殑瀵硅薄浼氳縐誨埌Old鍖猴紝鍚﹀垯浼氳淇濈暀鍦⊿urvivor鍖?nbsp;
- 褰揙LD鍖虹┖闂翠笉澶熸椂錛孞VM浼氬湪OLD鍖鴻繘琛屽畬鍏ㄧ殑鍨冨溇鏀墮泦錛?綰э級
- 瀹屽叏鍨冨溇鏀墮泦鍚庯紝鑻urvivor鍙奜LD鍖轟粛鐒舵棤娉曞瓨鏀句粠Eden澶嶅埗榪囨潵鐨勯儴鍒嗗璞★紝瀵艱嚧JVM鏃犳硶鍦‥den鍖轟負鏂板璞″垱寤哄唴瀛樺尯鍩燂紝鍒欏嚭鐜?#8221;out of memory閿欒”
Xms/Xmx錛氬畾涔塏EW+OLD孌電殑鎬誨昂瀵革紝ms涓篔VM鍚姩鏃禢EW+OLD鐨勫唴瀛樺ぇ灝忥紱mx涓烘渶澶у彲鍗犵敤鐨凬EW+OLD鍐呭瓨澶у皬銆傘傚湪鐢ㄦ埛鐢熶駭鐜涓婁竴鑸皢榪欎袱涓艱涓虹浉鍚岋紝浠ュ噺灝戣繍琛屾湡闂寸郴緇熷湪鍐呭瓨鐢寵涓婃墍鑺辯殑寮閿錛?nbsp;
NewSize/MaxNewSize錛氬畾涔夊崟鐙琋EW孌電殑灝哄錛孨ewSize涓篔VM鍚姩鏃禢EW鐨勫唴瀛樺ぇ灝忥紱MaxNewSize涓烘渶澶у彲鍗犵敤鐨凬EW鐨勫唴瀛樺ぇ灝忋傚湪鐢ㄦ埛鐢熶駭鐜涓婁竴鑸皢榪欎袱涓艱涓虹浉鍚岋紝浠ュ噺灝戣繍琛屾湡闂寸郴緇熷湪鍐呭瓨鐢寵涓婃墍鑺辯殑寮閿錛?/span>
Xms/Xmx鍜孨ewSize/MaxNewSize瀹氫箟濂藉悗錛孫LD鍖洪棿涔熻嚜鐒跺畾涔夊畬姣曚簡錛屽嵆OLD鍖哄垵濮嬪ぇ灝?錛圶ms-NewSize錛夛紝OLD鍖烘渶澶у彲鍗犵敤澶у皬=錛圶mx-MaxNewSize錛夛紱
PermSize/MaxPermSize錛氬畾涔塒erm孌電殑灝哄錛孭ermSize涓篔VM鍚姩鏃禤erm鐨勫唴瀛樺ぇ灝忥紱MaxPermSize涓烘渶澶у彲鍗犵敤鐨凱erm鍐呭瓨澶у皬銆傚湪鐢ㄦ埛鐢熶駭鐜涓婁竴鑸皢榪欎袱涓艱涓虹浉鍚岋紝浠ュ噺灝戣繍琛屾湡闂寸郴緇熷湪鍐呭瓨鐢寵涓婃墍鑺辯殑寮閿銆?/span>
]]>