Spigot (Bukkit) Java startup options don't need to be tuned that much
As the title says. It is a story when I did various Java startup options when running Spigot on VPS.
The boot options are usually OK as per the official Wiki
The startup script can be found at Spigot Installation. The Linux version is quoted below as an example.
start.sh
#!/bin/sh
java -Xms1G -Xmx1G -XX:+UseConcMarkSweepGC -jar spigot.jar
The initial allocation size of 1GB of the memory pool corresponds to -Xms1G, and the maximum allocation size of 1GB corresponds to -Xmx1G. However, this is only ** in an environment with sufficient memory **.
Execution in an environment with limited memory
If you deploy a 1GB class box with VPS etc., the memory will be sucked into the system by several hundred MB. As it is, Spigot may not work with the above startup script, so naturally allocate virtual memory and swap memory as it is called in Windows. (* This section assumes a Linux-based OS.) At first, ** 4GB is enough, and if necessary, you can add it later **. With VPS, the disk capacity is limited, so I think this area is safe. ~~ However, Build Tools may not work with ʻOutOfMemoryError`. Since my environment was so, I obediently built it locally. ~~
It was solved by allocating memory + α to Maven.
build.sh
#!/bin/sh
export MAVEN_OPTS="-Xmx2G -XX:+UseG1GC"
java -Xmx2G -XX:+UseG1GC -jar BuildTools.jar
Just less efficient
Swap memory will be used if the initial allocation size of the memory pool is 1GB. As I wrote above, I think that the system will use about several hundred MB and the rest will be about 700 MB or so. If the initial allocation size is 1GB with the remaining 700MB, about 300MB of swap memory will be used.
Using swap memory means reading and writing to the disk. If there is a delay in writing, it may cause lag or rewind.
If possible, remove the initial allocation option -Xms *, or take a look at half the -Xms512M and the initial allocation at about 512MB.
By the way, reading and writing of the disk was suppressed in my environment.
Is it okay to turn off (erase) or reduce -Xms *, but that's not a problem. ** If you allocate memory first, it will be faster when you use it (when you create an instance etc. in the program) ** It is not a required option. If you have enough memory, there is no reason to turn it off.
Can garbage collection remain CMS?
To briefly explain garbage collection, it frees up the unnecessary part of the used memory to free up memory. It is a place to clean the memory.
reference:
-Mechanism of garbage collection in 5 minutes | geechs magazine --This article is very easy to understand about garbage collection. -Organize Java VM Garbage Collection -How to check OutOfMemoryError --Qiita
So, ** CMS ** is an abbreviation for ** Concurrent Mark Sweep ** and is one of the garbage collection algorithms. This is also a cleaning method. We will release the memory by a cleaning method called CMS.
By the way, the startup script written above has -XX: + UseConcMarkSweepGC as an option to use this CMS.
It seemed that there was no problem with CMS in particular, but I was worried that Full GC occurred a little in my environment. ʻOutOfMemoryError` has not occurred, but it is possible if it swells.
In fact, ** CMS may become unusable in the future **. Please read the continuation for details.
Don't over-season your CMS
Don't use incremental mode (-XX: + CMSIncrementalMode).
The CMS collector can be used in a mode where the concurrent phase is incremental. As mentioned earlier, the garbage collector thread is using one or more processors during the concurrent phase. Incremental mode is intended to mitigate the effects of the long-running concurrent phase by ** periodically stopping the concurrent phase ** and returning the processor to the application.
There was a possibility that lag etc. had occurred due to this "regular stop". Or rather
Incremental mode has been deprecated in Java SE 8 and may be removed in future major releases.
Because there is, I do not use incremental mode.
Source: https://docs.oracle.com/javase/jp/8/docs/technotes/guides/vm/gctuning/cms.html
Kurofune visits G1GC
Garbage First Garbage Collector, G1GC for short. This is also one of the garbage collection algorithms. However, this is a new guy!
It is officially implemented from Java7 (java7u4), and this is used as standard from Java9. And ** CMS has been deprecated **.
Garbage First (G1) Garbage Collector is intended to replace most uses of CMS.
Is there a possibility that the CMS will be deleted in the future by replacing it?
Source:
- Java SE 7 Update 4 Release Notes -[Java Platform, Standard Edition Oracle JDK 9, New Features, Release 9](https://docs.oracle.com/javase/jp/9/whatsnew/toc.htm#GUID-B6CD8C25-FD93-4CAA-9286- 19A39CC0F26A)
It's a little difficult to set, so the default is fine
reference:
-Tuning the Garbage First Garbage Collector -JVM Tuning: How to Use G1 GC and Migrate from CMS GC
The G1 GC is an adaptive garbage collector that can be used and worked effectively without changing the default values.
First of all, please take a look at the situation without adding anything, which is the default because it says "effectively works".
Summary: Don't use startup scripts that claim to be "optimized" or "accelerated"
As long as you have enough memory pool allocation, the Java VM will do the rest automatically. Great!
In the JVM, the garbage collector, heap size, and runtime compiler default choices vary from platform to platform. These choices address the needs of different applications without much command line tuning. In addition, behavior-based tuning dynamically adjusts the heap size to suit specific application behaviors.
Source: Ergonomics
The processing speed does not increase beyond the specifications of the machine. Rather, it is an article that tells you that adding strange Java startup options without understanding it will result in inefficiency and cause lag and rewind.
Also, which one to use, CMS or G1GC, depends on the environment. As I wrote above, CMS has been deprecated in Java 9, so it might be a good idea to shift to G1GC. However, in a low spec environment, G1GC feels a bit harsh (because G1GC has a slightly higher CPU usage than CMS). Read the following reference article for the reason!
reference:
-Mostly Concurrent Collector --[Java Garbage Collection --Software Engineering --Torutk](http://www.torutk.com/projects/swe/wiki/Java Garbage Collection)
When using G1GC, use the following options. In Java 9 and above it's just a spell.
start.sh
#!/bin/sh
java -Xms1G -Xmx1G -XX:+UseG1GC -jar spigot.jar
One of the features of G1GC is "Pause time target". The default is 200 milliseconds, which is quite low, but in my environment I thought that it would be possible to minimize the lag by changing it to 50 milliseconds and setting the lag small.
start.sh
#!/bin/sh
java -Xms1G -Xmx1G -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -jar spigot.jar
If you want to tune, it may be better to keep it down to this level. It feels a little placebo effective. However, it is not good if it is too small, so if you have a problem, try increasing it. Currently, Full GC does not occur in our environment.
Since there are various things, I welcome Tsukkomi if there is something wrong. Ignore any other "what should I do?" please note that.