JVM Arguments for Modded Minecraft (Updated 12/30/13)
- Thread starter Eyamaz
- Start date
-
The FTB Forum is now read-only, and is here as an archive. To participate in our community discussions, please join our Discord! https://ftb.team/discord
Somewhat related to this performance thread; I read this and got a handful of "ah-moments" on the functioning of the server:
http://www.sk89q.com/2013/03/improving-your-minecraft-servers-performance/
http://www.sk89q.com/2013/03/improving-your-minecraft-servers-performance/
I tend to prefer the G1GC since it's methodology classifies memory to scan by areas of largest gap; the previous collectors methodology of promoting objects to older storage is replaced with a more finely grained collection process.
Here's roughly where I'd begin for a system with 2048M of ram, an older CPU (the SSE level) and 2 cores (The parallel threads set to N-1) server.jar is a symlink to whatever the real .jar is, and /run/tmp/ is a tmpfs filesystem on ubuntu (based?) systems. Use another tmpfs mount location for the log if necessary.
Here's roughly where I'd begin for a system with 2048M of ram, an older CPU (the SSE level) and 2 cores (The parallel threads set to N-1) server.jar is a symlink to whatever the real .jar is, and /run/tmp/ is a tmpfs filesystem on ubuntu (based?) systems. Use another tmpfs mount location for the log if necessary.
Code:
java -server \
-XX:+UseG1GC \
-XX:ParallelGCThreads=1 -XX:+UnlockExperimentalVMOptions \
-XX:+UseAdaptiveGCBoundary -XX:PermSize=128M -XX:MaxPermSize=192M -XX:+UseGCOverheadLimit -XX:+UseBiasedLocking -Xnoclassgc \
-XX:UseSSE=2 -XX:+UseThreadPriorities -XX:+UseLargePages -XX:+UseStringCache -XX:+OptimizeStringConcat \
-XX:+UseFastAccessorMethods -XX:+AggressiveOpts -Xmx2048M \
-XX:MaxGCPauseMillis=45 \
-XX:GCPauseIntervalMillis=100 \
-XX:+DisableExplicitGC \
-XX:InitiatingHeapOccupancyPercent=50 \
-Xloggc:/run/tmp/mcgc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps \
-jar server.jar noguiOriginally I was using g1gc, however on larger modpacks it has issues dealing with the Eden space and tenuring through the from/to survivor space causing a rubber banding effect with entities. A few others have attempted to get the g1gc to work and, while it works wonders with enterprise programs, it does not bode well keeping up anything but smaller modpacks or vanilla mc.
Also, parallelgcthreads only affects the parnewgc collector and useSSE defaults to the highest level SSE your computer supports.
UnlockExperimentalVMOptions is also not needed in java 7 so I'm guessing your options are geared toward java 6. If so, you should check into using keybounces arguments he has on the minecraft forums. He does a wonderful job and has a lot of data tracking contained in his thread.
Also, parallelgcthreads only affects the parnewgc collector and useSSE defaults to the highest level SSE your computer supports.
UnlockExperimentalVMOptions is also not needed in java 7 so I'm guessing your options are geared toward java 6. If so, you should check into using keybounces arguments he has on the minecraft forums. He does a wonderful job and has a lot of data tracking contained in his thread.
Yea, I was never able to get good performance from G1GC either. In fairness, I don't know if the J6 implementation is different than the J7 one, and it would not surprise me if J7 has a better version of it.
Now, keep in mind that I've been given a few ideas to check into, but I have not yet had the time:
1. Turn off "-server" -- while I put it on when running the minecraft server, someone said that it tells java "assume you are the only significant thing running, and gobble all the resources you need".
2. By default, G1GC in J6 basically promotes every object to survivor at every minor collection, and has minor collections constantly. Without some way to restrict the frequency of these minor collections, no junk object ever expires.
With that said, I was able to get some improvement by explicitly specifying eden/survivor space size, but I could not get enough time for the "copy until it reaches the threshold or dies off" behavior to actually get the die-off effect (which seems to take somewhere in the 6 to 20 second range ... still investigating that).
So I know that there is room for improvement, I just don't know what flags exist / can be tuned/tweaked.
3. CMS seems to do more of its work in concurrent threads; G1GC seems to do more "stop the world" activity. That's great for web servers, but horrible for response critical gaming. If there is a difference in J6/J7, I suspect this will be the biggest point of change.
Now, keep in mind that I've been given a few ideas to check into, but I have not yet had the time:
1. Turn off "-server" -- while I put it on when running the minecraft server, someone said that it tells java "assume you are the only significant thing running, and gobble all the resources you need".
2. By default, G1GC in J6 basically promotes every object to survivor at every minor collection, and has minor collections constantly. Without some way to restrict the frequency of these minor collections, no junk object ever expires.
With that said, I was able to get some improvement by explicitly specifying eden/survivor space size, but I could not get enough time for the "copy until it reaches the threshold or dies off" behavior to actually get the die-off effect (which seems to take somewhere in the 6 to 20 second range ... still investigating that).
So I know that there is room for improvement, I just don't know what flags exist / can be tuned/tweaked.
3. CMS seems to do more of its work in concurrent threads; G1GC seems to do more "stop the world" activity. That's great for web servers, but horrible for response critical gaming. If there is a difference in J6/J7, I suspect this will be the biggest point of change.
The only arguments I know of that affect g1gc are MaxGCPauseMillis and GCPauseIntervalMillis. Both are soft targets and not explicit. Using them I was able to prevent most WSEs but couldn't work around the rubberbanding mobs issue even with increasing the survivor/eden ratio to 3 times the normal. Maybe it will be viable in j8.
I was also told those flags affected other GCs, but haven't found they do anything to them. I have not had time for any serious testing in the last month though.
I was also told those flags affected other GCs, but haven't found they do anything to them. I have not had time for any serious testing in the last month though.
I'd like to point out, using permsize in arguments of MultiMC AND in the program's settings panel, causes the game to sum both up. Might want to revisit that.
This is what I'm currently using on my FTB server. It runs MCPC+ on a cached SSD VPS that has 4GB of RAM available using the Direwolf20 1.5.2 1.1.6 modpack. I found these params on another performance thread where the author claimed to be a Java guru that did extensive testing. I'll see if I can dig up the thread, but here they are regardless:
I removed the jmx options I normally use for visualvm debugging.
Code:
-Djline.terminal=jline.UnsupportedTerminal -d64 -XX:+UseCompressedOops -XX:NewRatio=3 -XX:PermSize=150m -XX:NewSize=114m -XX:SurvivorRatio=1 -XX:CompileThreshold=300 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSIncrementalPacing -XX:SoftRefLRUPolicyMSPerMB=0 -XX:CMSInitiatingOccupancyFraction=80 -XX:ParallelGCThreads=4 -XX:MaxHeapFreeRatio=25 -XX:MinHeapFreeRatio=21 -XX:+DisableExplicitGC -XX:MaxTenuringThreshold=4 -XX:+AggressiveOptsI removed the jmx options I normally use for visualvm debugging.
I'm no java guru, but I'll give my 2 cents.
If your using java7 64bit from oracle you don't need -d64 -XX:+UseCompressedOops. CompressedOops is true by default and -d64 only forces 64bit mode, which it already runs in. IIRC, -d64 can be used to force using a 64bit java over a 32bit java, but I never tested it so I'm not right sure.
General consensus, that I don't necessarily agree with, is that ParallelGCThreads should be set to N-1 where N is the number of total threads in your cpu. So that a 4 core processor with 1 thread per core would be 3, while a 4 core processor with 2 threads per core would be 7.
I'm actually going to be replacing DisableExplicitGC in my arguments with a different implementation from keybounce that I can't remember off the top of my head.
The jvm arguments in the OP are a little outdated and I'm working on a different set, hopefully with a few others also.
If your using java7 64bit from oracle you don't need -d64 -XX:+UseCompressedOops. CompressedOops is true by default and -d64 only forces 64bit mode, which it already runs in. IIRC, -d64 can be used to force using a 64bit java over a 32bit java, but I never tested it so I'm not right sure.
General consensus, that I don't necessarily agree with, is that ParallelGCThreads should be set to N-1 where N is the number of total threads in your cpu. So that a 4 core processor with 1 thread per core would be 3, while a 4 core processor with 2 threads per core would be 7.
I'm actually going to be replacing DisableExplicitGC in my arguments with a different implementation from keybounce that I can't remember off the top of my head.
The jvm arguments in the OP are a little outdated and I'm working on a different set, hopefully with a few others also.
That makes perfect sense. I haven't tried ParallelGCThreads using your formula before, but it's definitely worth a shot. I'm running on a VPS, so I can only see the cores the way they are presented to me, but I can still try it a few different ways and see which works out better.
I'm definitely going to be watching this thread very closely. Thanks for sharing!
I'm going to be doing more research into parallelGCthreads when I have time because I keep getting conflicting answers as to how it works even through documentation. Untill I have to to sit down and go ever it in the actuall jvm source code, I'm partial to defer to my peers on it.
Thankfully, the jvm source code is well commented and writen in C++. Even then, as a link keybounce posted earlier, intended operation is not always the result.
Thankfully, the jvm source code is well commented and writen in C++. Even then, as a link keybounce posted earlier, intended operation is not always the result.
he means what the update number is. Java 6 and 7 are still being updated. "most recent" is a useless descriptor.
It's taken so long for you to respond. Idr, what your issue was and the pastebin expired. :/