1. This section of the forums is now closed. You can post and answer support requests on the new support site here

JVM Arguments for Modded Minecraft (Updated 12/30/13)

Discussion in '[Archived] Tech Support' started by Eyamaz, Aug 13, 2013.

  1. Eyamaz

    Eyamaz New Member

    Use the server settings in the vanilla launcher.
     
  2. Nighthawk4123

    Nighthawk4123 New Member

    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
     
  3. Eyamaz

    Eyamaz New Member

    Hrm. Yours is the first issue I've had pop up. I have a few other servers running them fine. What are the specs on yours and is it dedicated or nondedicated.
     
  4. Nighthawk4123

    Nighthawk4123 New Member

    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
     
  5. Eyamaz

    Eyamaz New Member

    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.
     
  6. Nighthawk4123

    Nighthawk4123 New Member

    it seems as though doing those two things made it worse
    for not just my client but others as well
     
  7. Eyamaz

    Eyamaz New Member

    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.
     
  8. Spencefoz

    Spencefoz New Member

    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 nogui
     
  9. Eyamaz

    Eyamaz New Member

    Some 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.
     
  10. Spencefoz

    Spencefoz New Member

    I appreciate the response and sorry for posting so many! Thanks for touching on them!


    EDIT**

    I've read this -XX:+DisableExplicitGC is important to use and beneficial to all - any thoughts?
     
    Eyamaz likes this.
  11. Eyamaz

    Eyamaz New Member

    It prevents a full gc from being done when a reference is made to system.gc. I used this for a bit because it was recommended, but I found using it can actually cause issues if you have a heavy load on your heap.
     
  12. Spencefoz

    Spencefoz New Member

    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+?
     
  13. Eyamaz

    Eyamaz New Member

    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.
     
  14. reddvilzz

    reddvilzz New Member

    Great post finally pops out. :D. Thanks.
    So with the java arguments is it different performance playing ftb using the multiMC and ftb launcher itself? And which launcher is better?
     
  15. Eyamaz

    Eyamaz New Member

    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.
     
    reddvilzz likes this.
  16. Eyamaz

    Eyamaz New Member

    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.
     
    reddvilzz likes this.
  17. reddvilzz

    reddvilzz New Member

    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 -XX:permSize=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?
     
  18. Eyamaz

    Eyamaz New Member

    Use the memory settings in multimc. You shouldn't need more than 2048, but set them both the same.
     
  19. GuildMaster

    GuildMaster New Member

    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.
     
  20. Eyamaz

    Eyamaz New Member

    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.
     
    Staxed, Ashzification and Vauthil like this.

Share This Page