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
So I tried using these settings on my server, and it made it so that none of the players/monsters would move fluidly... they would jump around 3-5 blocks at a time instead of a fluid motion. any ideas on how to fix?
*edit,
I run FTB Unleashed 1.1.3
*edit,
I run FTB Unleashed 1.1.3
Its my pc, running on your defined settings, and with an AMD Phenom II x6 1100T 3.30GHz processor
I do also play my client on the same machine, there are no other applications going in the background, and i have tried connecting both with my client and the client on my brothers computer. Had the same problem on his end.
I have 16gb of RAM on this machine
I do also play my client on the same machine, there are no other applications going in the background, and i have tried connecting both with my client and the client on my brothers computer. Had the same problem on his end.
I have 16gb of RAM on this machine
Try changing the compilethreshold to 3000. Both client side and server side if your using the client jvms also.
If you are running your client and server on the same computer, change the core affinity for your server java process to core 4, 5, and 6 (that is a six core processor right?) after you start it and change your client to cores 1, 2, and 3.
Also, be sure you java 7u25 x64 installed.
If you are running your client and server on the same computer, change the core affinity for your server java process to core 4, 5, and 6 (that is a six core processor right?) after you start it and change your client to cores 1, 2, and 3.
Also, be sure you java 7u25 x64 installed.
it seems as though doing those two things made it worse
for not just my client but others as well
for not just my client but others as well
Hrm. I'll have to check some things when I get home in a few hours. I did most of my testing in the 1.1.2 pack since it was recommended. Can you post a copy of the server log to pastebin.com and link it for me. As well as one of the client logs also.
I found a couple of different posts online that have some other information... I wanted to get your take on it and see what you thought on some of these JVM flags. You have commented on some already; however, I am wondering if there is any credibility to these posts. Word of warning: I don't know too much about the JVM Flags so directing questions my way will do no good 
Code:
-Xmx2560M -Xms1G -XX:PermSize=128M -XX:MaxPermSize=256M -XX:NewRatio=3 -Xrs -XX:+UseThreadPriorities -XX:CMSFullGCsBeforeCompaction=1 -XX:SoftRefLRUPolicyMSPerMB=2048 -XX:+CMSParallelRemarkEnabled -XX:+UseParNewGC -XX:+DisableExplicitGC -Xnoclassgc -oss4M -ss4M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseConcMarkSweepGC -XX:UseSSE=4 -XX:+UseCMSCompactAtFullCollection -XX:ParallelGCThreads=4 -Xcheck:jni -Xfuture -XX:+AggressiveOpts -jar ftbserver.jar nogui
Code:
ionice -c1 -n0 nice -n -10 /usr/lib/jvm/jdk1.7.0/bin/java -Djava.library.path=/usr/lib/jvm/jdk1.7.0/lib/amd64 -d64 -server -XX:+UseG1GC -DJINTEGRA_NATIVE_MODE -DJINTEGRA_COINIT_VALUE=0 -Dsun.io.useCanonCaches=false -Djline.terminal=jline.UnsupportedTerminal -XX:ThreadPriorityPolicy=42 -XX:CompileThreshold=1500 -XX:+TieredCompilation -XX:ParallelGCThreads=4 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=15 -XX:+UnlockExperimentalVMOptions -XX:+UseAdaptiveGCBoundary -XX:PermSize=64M -XX:MaxPermSize=256M -XX:+UseGCOverheadLimit -XX:+UseBiasedLocking -Xnoclassgc -Xverify:none -XX:UseSSE=3 -XX:+UseThreadPriorities -Djava.net.preferIPv4Stack=true -XX:+UseLargePages -XX:+UseStringCache -XX:+OptimizeStringConcat -XX:+UseFastAccessorMethods -Xrs -XX:+UseCompressedOops -XX:+AggressiveOpts -jar craftbukkit-0.0.1-SNAPSHOT.jar noguiSome of these I already explained about so ill just hit the ones i havent.
-XX:NewRatio=3 : sets the ratio between the young and old heap. this can actually reduce performance because the younggen may not be able to scale high enough to hold the data it needs to hold
-Xrs : this prevents the JVM from accepting certain expection signals and lets the OS handle them instead. this usually causes a drop in performance
-XX:+UseThreadPriorities : this causes the JVM to use native thread priorities. i say no difference in performance when using this
-XX:CMSFullGCsBeforeCompaction=1 -XX:+UseCMSCompactAtFullCollection : this is basically a defragmentation of the heap in concurrent mode. it made little difference in preformance when i tested it.
-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 : this tells the CMS collector to do a GC at 75% full old generation. the first one makes it only run at 75%. setting the gc to run at 75% is fine, but to only run at 75% is bad for MC.
-XX:SoftRefLRUPolicyMSPerMB=2048: this helps keep some objects alive longer. the person who added this obviously didn't know what they were doing and thought this was a memory value because its set to 2.048 seconds. i have yet to experiment with this option though.
-Xfuture : is for programers to use during program testing to be sure there code is "future proofed" for future revisions of java
-Xcheck:jni : the actual command is -Xcheck:jni[:help][:<option>=<value>] and performs an error check specific to the given instructions for jni. this is not needed and not even used correctly, its a debug tool.
ionice -c1 -n0 nice -n -10 : these are all linux commands. um, its been awhile since I've used linux. IIRC its a data IO handler for disk usage.
-DJINTEGRA_NATIVE_MODE -DJINTEGRA_COINIT_VALUE=0 : the only use I know of for these is if the programer needs to interact with a COM object. in any event, they are not needed as if a program written in java NEEDs these flags, the programer themselves will hardcode these into the program. if they were needed to be added in the JVM arguments, the program would crash without them.
-Dsun.io.useCanonCaches=false this turns the canonicalization cache in java off. this is used to prevent errors if a single method accesses multiple different named files in to short of a time frame. this made no difference in any tests i did.
Djline.terminal=jline.UnsupportedTerminal : this disables jline. jline is a java console library. i dont see any reason to use this. i dont think minecraft uses the jline console. i see it alot with the craftbukkit.jar though, so maybe craftbukkit does.
-XX:MaxTenuringThreshold=15 : i use this in my JVMs in the OP. however 15 is the default so this command is redundant.
-XX:+UnlockExperimentalVMOptions : is used in conjunction with useG1GC in java 6 to enable the G1 collector. it has no other use i know of.
-XX:+UseAdaptiveGCBoundary -XX:+UseGCOverheadLimit : i havent figured out what exactly these do as of yet.
-Xverify:none : this stops java from performing class loading checks. everything ive read says dont turn this off. so ive never used this :p
-Djava.net.preferIPv4Stack=true : this forces java to use IPv4 instead of IPv6. i dont know why you would need this.
i think i got them all.
-XX:NewRatio=3 : sets the ratio between the young and old heap. this can actually reduce performance because the younggen may not be able to scale high enough to hold the data it needs to hold
-Xrs : this prevents the JVM from accepting certain expection signals and lets the OS handle them instead. this usually causes a drop in performance
-XX:+UseThreadPriorities : this causes the JVM to use native thread priorities. i say no difference in performance when using this
-XX:CMSFullGCsBeforeCompaction=1 -XX:+UseCMSCompactAtFullCollection : this is basically a defragmentation of the heap in concurrent mode. it made little difference in preformance when i tested it.
-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 : this tells the CMS collector to do a GC at 75% full old generation. the first one makes it only run at 75%. setting the gc to run at 75% is fine, but to only run at 75% is bad for MC.
-XX:SoftRefLRUPolicyMSPerMB=2048: this helps keep some objects alive longer. the person who added this obviously didn't know what they were doing and thought this was a memory value because its set to 2.048 seconds. i have yet to experiment with this option though.
-Xfuture : is for programers to use during program testing to be sure there code is "future proofed" for future revisions of java
-Xcheck:jni : the actual command is -Xcheck:jni[:help][:<option>=<value>] and performs an error check specific to the given instructions for jni. this is not needed and not even used correctly, its a debug tool.
ionice -c1 -n0 nice -n -10 : these are all linux commands. um, its been awhile since I've used linux. IIRC its a data IO handler for disk usage.
-DJINTEGRA_NATIVE_MODE -DJINTEGRA_COINIT_VALUE=0 : the only use I know of for these is if the programer needs to interact with a COM object. in any event, they are not needed as if a program written in java NEEDs these flags, the programer themselves will hardcode these into the program. if they were needed to be added in the JVM arguments, the program would crash without them.
-Dsun.io.useCanonCaches=false this turns the canonicalization cache in java off. this is used to prevent errors if a single method accesses multiple different named files in to short of a time frame. this made no difference in any tests i did.
Djline.terminal=jline.UnsupportedTerminal : this disables jline. jline is a java console library. i dont see any reason to use this. i dont think minecraft uses the jline console. i see it alot with the craftbukkit.jar though, so maybe craftbukkit does.
-XX:MaxTenuringThreshold=15 : i use this in my JVMs in the OP. however 15 is the default so this command is redundant.
-XX:+UnlockExperimentalVMOptions : is used in conjunction with useG1GC in java 6 to enable the G1 collector. it has no other use i know of.
-XX:+UseAdaptiveGCBoundary -XX:+UseGCOverheadLimit : i havent figured out what exactly these do as of yet.
-Xverify:none : this stops java from performing class loading checks. everything ive read says dont turn this off. so ive never used this :p
-Djava.net.preferIPv4Stack=true : this forces java to use IPv4 instead of IPv6. i dont know why you would need this.
Sorry to bother you again,
Found a post by EvilSeph of the Bukkit Team and he said these things; I am specifically interested in the DisabledExplicitGC part - I know you already talked about it but I wanted to add in the Bukkit perspective. His message is a little bit more than half way down the page. Just trying to bounce things off of you due because I am very interested in making my server run well with 10-20 players online.
https://forums.bukkit.org/threads/o...ay-p-need-feedback-thx-i-am-back.25994/page-3
Just a thought/question - we are running MCPC+ which is the whole spigot/bukkit/forge deal, do you have any thoughts/concerns regarding this script, the one you have provided, and MCPC+?
Found a post by EvilSeph of the Bukkit Team and he said these things; I am specifically interested in the DisabledExplicitGC part - I know you already talked about it but I wanted to add in the Bukkit perspective. His message is a little bit more than half way down the page. Just trying to bounce things off of you due because I am very interested in making my server run well with 10-20 players online.
https://forums.bukkit.org/threads/o...ay-p-need-feedback-thx-i-am-back.25994/page-3
Just a thought/question - we are running MCPC+ which is the whole spigot/bukkit/forge deal, do you have any thoughts/concerns regarding this script, the one you have provided, and MCPC+?
Yes, almost everything in that post is still accurate, but was made for java 6. The only thing wrong is that 64bit java7 defaults to having the -server enabled, making it redundant.
I'll also have to ammend my OP later to add DisabledExplicitGC even though I don't want to. No mod should decide when java should do garbage collection, it can have horribly bad impact on performance even though they think it helps. Ty, for directing me to that thread. I didn't know any mods/plugins were doings this.
Edit: I didn't do any testing specifically with MCPC+ but that shouldn't make a difference. The JVMs I have above are performance at the cost of RAM. As long as you have the RAM needed for your server, it shouldn't matter.
I'll also have to ammend my OP later to add DisabledExplicitGC even though I don't want to. No mod should decide when java should do garbage collection, it can have horribly bad impact on performance even though they think it helps. Ty, for directing me to that thread. I didn't know any mods/plugins were doings this.
Edit: I didn't do any testing specifically with MCPC+ but that shouldn't make a difference. The JVMs I have above are performance at the cost of RAM. As long as you have the RAM needed for your server, it shouldn't matter.
Quite honestly, my choice is MultiMC. This is not because I don't like the FTBLauncher, I just have issues with the JVM arguments it automatically passes when it starts MC because I can't disable them. Two of these arguments make it so it's more RAM friendly and not performance friendly. As of yet, the only real and substantial performance gains I've found through JVM arguments is by sacrificing RAM friendliness.
Updated post and added the DisableExplicitGC flag to prevent mods/plugins forcing the JVM to do any garbage collection before it is supposed to. This is a no no. The JVM does a perfectly fine job of this itself and your not helping it, only disrupting it by pulling things out of memory faster than it should be. When a "performance" mod/plugin does this to "increase" performance, its causing data allocated in the heap to tenure faster and can cause errors and extreme performance drops if a failed tenure event happens because data is being moved to fast and the TO/FROM area of the heap is full.
Sir i have a question here,
-Xmn512m -XX:TargetSurvivorRatio=80 -XX:MaxTenuringThreshold=31 -XX:+UseG1GC -XX:+DisableExplicitGC -XX:MaxGCPauseMillis=40 -XX:GCPauseIntervalMillis=400 -XX:+AggressiveOpts -XXermSize=1024m -XX:+TieredCompilation -XX:ReservedCodeCacheSize=2048m -XX:+UseCodeCacheFlushing -XX:CompileThreshold=1000
**Note**
Xmn needs to be set to ¼ the size you set for your maximum heap size in the MultiMC settings.
The setting of 512m is assuming you have your Maximum Heap size set to 2048m.
So do i set the maximum heap size with parameters to 2048? or i use the one in the MultiMC in the java tab setting? if i use the one in the MultiMC setting in the Java tab what value should i set on the minimum one? do i need to set it as the same as XMN value or not?
-Xmn512m -XX:TargetSurvivorRatio=80 -XX:MaxTenuringThreshold=31 -XX:+UseG1GC -XX:+DisableExplicitGC -XX:MaxGCPauseMillis=40 -XX:GCPauseIntervalMillis=400 -XX:+AggressiveOpts -XX
ermSize=1024m -XX:+TieredCompilation -XX:ReservedCodeCacheSize=2048m -XX:+UseCodeCacheFlushing -XX:CompileThreshold=1000**Note**
Xmn needs to be set to ¼ the size you set for your maximum heap size in the MultiMC settings.
The setting of 512m is assuming you have your Maximum Heap size set to 2048m.
So do i set the maximum heap size with parameters to 2048? or i use the one in the MultiMC in the java tab setting? if i use the one in the MultiMC setting in the Java tab what value should i set on the minimum one? do i need to set it as the same as XMN value or not?
Great thread with lots of good JVM arguments, but I just want to add something. Java 8 preview (http://jdk8.java.net/download.html) is available for download and it helps a lot with performance. It removes the need for the Perm Gen arguments, and it will even give you warnings that they are obsolete if used.
I will NEVER recommend an early release build for java. I've said this more than a few times in various threads. They lack proper security patches. If you use one, you do so at your own risk.