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. Henry Link

    Henry Link Popular Member

    Noob is not bad. It is how you learn. So change the permsize command to

    Code:
    -XX:PermSize=256m
    Make sure there is a space before and after. If it still doesn't work. Post the contents of your batch files again. But use the CODE button so you don't get :p
     
  2. SamB167

    SamB167 New Member

    Cheers for the help, it will be so nice to get the server not to lag. I'm learning slowly. I will try all those and fingers crossed it works
     
  3. SamB167

    SamB167 New Member

    I could still be being a bit simple :). your correction fixed the first problem, It was because I hadn't put the uppercase 'P' in permSize. I should have picked that up.

    The error I'm getting now is - Error: Could not find or load main class FTBServer-1.6.4-965.jar

    is the FTBServer-1.6.4-965.jar generic, or is it something specific to my server, if it's something specific, where can I find what it should be?

    Thanks ever so much for helping me
     
  4. Henry Link

    Henry Link Popular Member

    It should be the .jar file that is in the same directory as the batch file. Just copy the name of that file in and it should start working.
     
  5. SamB167

    SamB167 New Member

    Yup it looks like it's working now I changed it to "-jar ftbserver.jar" thanks again.
    I would still be stuck where I was last night struggling to make sense of the whole console window.

    Cheers all for your help!
     
  6. keybounce

    keybounce New Member

    The other thing, if you are still having problems: Your "-jar ftbserver.jar nogui" segment is on its own line, and needs to be on the same line.
     
  7. Ederlezi

    Ederlezi New Member

    Hi guys,

    I've been looking for the best arguments and i have to admit i dont have enough knowledge. If someone could gimme a bit of help, i'd much appreciate.

    I run a monster server 1.0.10 on a 1950 dell server, 4-5 players. The server only runs ftb and can use all ressources.

    2 quad core cpu xeon 5435, 16g of ram, ubuntu server 64Bit, openjdk7.
     
  8. keybounce

    keybounce New Member

    For a 16 GB machine?

    I'd personally toss 13 GB at minecraft, leaving 3 for the OS / etc. That's way more than it needs.

    For only 5 players? 6 GB for tenured is probably sufficient; another 6 GB at new is way overkill.

    6 tenured, 6 new, that's 12 GB -- so you have a 12 GB heap, you have whatever space java needs for itself and the bytecode, etc.

    So, that would be maxPerm of 250 (or whatever it takes for monster), New/MaxNew of 6000, and Xmx of 12000.

    EDIT: AFTER letting this run for a week or so, you should have a better idea of how much tenured space is needed, and you can give more space to new as a result.
     
  9. DZCreeper

    DZCreeper New Member

    Keep in mind, having 8 cores is useless for Minecraft. It will only use 1 core most of the time and 2 at the most.
     
  10. Ederlezi

    Ederlezi New Member

    Thank you for your very fast answer :) So if i understand you and the first post of eyamaz well, arguments should look like :

    -Xms12000m -Xmx12000m -XX:permSize=256m -XX:NewRatio=3 -XX:SurvivorRatio=3 -XX:TargetSurvivorRatio=80 -XX:MaxTenuringThreshold=8 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxGCPauseMillis=10 -XX:GCPauseIntervalMillis=50 -XX:MaxGCMinorPauseMillis=7 -XX:+ExplicitGCInvokesConcurrent -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=60 -XX:+BindGCTaskThreadsToCPUs -Xnoclassgc

    New will be 4000m with -XX:NewRatio=3 ?

    Which makes my service looks like :

    SERVICE='FTBServer-1.6.4-965.jar'
    OPTIONS='nogui'
    USERNAME='minecraft'
    WORLD='world'
    MCPATH='/home/minecraft/MonsterServer'
    BACKUPPATH='/home/minecraft/MonsterBackup'
    MAXHEAP=12000
    MINHEAP=12000
    HISTORY=1024
    INVOCATION="java -Xmx${MAXHEAP}M -Xms${MINHEAP}M -XX:permSize=256m -XX:NewRatio=3 -XX:SurvivorRatio=3 -XX:TargetSurvivorRatio=80 -XX:MaxTenuringThreshold=8 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxGCPauseMillis=10 \
    -XX:GCPauseIntervalMillis=50 -XX:MaxGCMinorPauseMillis=7 -XX:+ExplicitGCInvokesConcurrent -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=60 -XX:+BindGCTaskThreadsToCPUs -Xnoclassgc -XX:+AggressiveOpts \
    -jar $SERVICE $OPTIONS"


    :) i agree but when u see the price of an i7/i5 compared to an old good RoadRunner refurb 1950 on ebay http://www.ebay.co.uk/itm/Dell-Powe...2?pt=UK_Computing_Servers&hash=item5d43e01930 , u think different :)

    At some point, i'll install a zoneminder/ zwave thingy to really try to use it ;)
     
  11. DZCreeper

    DZCreeper New Member

    At that price its a pretty nice deal. Not great for modded Minecraft because of the low per core speeds and high power consumption but if you put a couple vanilla servers on there and rent them out, it would pay for itself and leave enough room to run one or two servers for yourself.
     
  12. Eyamaz

    Eyamaz New Member

    The extra cores don't necessarily affect MC itself, but they do help with the GC and compiler.
     
    un worry likes this.
  13. Revemohl

    Revemohl New Member

    What about anything for small, poor 32 bit systems? Currently I'm only using the ConcMarkSweepGC, and that's because I randomly found out about it while googling, but even that alone has been helping with the memory usage, especially when I go to different dimensions. As for the RAM allocation, it's set to 512M min, 812M max, 96M permgen because it's really that poor. Still manages to run a small pack with 68 mods in the folder and 107 in the title screen just well enough.
    Yeah yeah I know I should upgrade my computer and all that but that's not an option at the moment, so I'd like to try getting the best of what I have right now.
     
  14. obscurehero

    obscurehero New Member

    @Eyamaz -

    I just went through these arguments with a fine toothed comb and I'm quite curious how you arrived at these values. It seems to me a lot of this could be system specific and mod specific. Specifically in regards to the server arguments.

    I tried these without actually understanding a ton of them initially and it ground the server into the ground. I didn't take the time to profile the garbage collector, I just ditched the arguments and went back to using ConcMarkSweep and letting the JVM handle the rest. Vast improvement.

    It's not clear that explicitly indicating tenuring threshold max does anything. The JVM dynamically adjust this value to promote to tenured.

    I'm most concerned with your use of MaxGCPauseMillis/MaxGCMinorPauseMillis. Doing this can increase the number of pauses based on how the parallel collector ranks its goals. It's possible you may need to increase GCPauseIntervalMillis. Furthermore, I think that MaxGCPauseMillis is less important as using the parallel gc on the new gen only ensures you're only using minor collections as you're using concurrent gc and not compaction for old gen.

    Why use CMSInitiatingOccupancyFraction? 80% is default and its not clear that starting collection earlier will improve performance

    Why BindGCTaskThreadsToCPUs? It reduces sync time, but again that's not clear if it really increases latency it might just be easier to explicitly declare the number of threads you'd like to use.

    Why not GC classes? It might save time, but is it ideal?

    I think you should pare back these heavily and then give a few pointers on system specific profiling for more accurate tuning.
     
  15. keybounce

    keybounce New Member

    Actually, the compiler is a big thing. You could, for example, add in flags to force a lot of extra compilation and data flow analysis, and there's CPU to spare.

    This one I can tell you. Minecraft's memory allocation can vary significantly. The JVM wants to have tenuring threshold as high as possible. This means that all of a sudden, very large amounts of memory can be tenured at once -- everything from generation 2 to generation 15.

    This will confuse the CMS collector -- it doesn't start a collection soon enough. It doesn't cause concurrent failure, but it does trigger "I need to allocate more memory".

    This in turn will cause problems on smaller machines. Not so much if you have a 16 GB machine only running minecraft. But if you have a 4 GB machine, with a client, a server, a voice chat, a screen recorder, etc., then I really needed to keep minecraft from unnecessarily expanding it's memory allocation. I needed to know that it _could_ allocate more if it had to, but would not do so "just because".

    So I learned. Experimental behavior -- the system worked better if the combination of:
    Tenuring threshold
    Survivor space
    Eden space
    were such that objects would expect to last at least 30 seconds before leaving survivor into tenuring.

    This meant that the size of eden (determines the frequency of minor collections), times the copy threshold, was at least 30 seconds. Holding stuff in survivor longer did NOT help reduce tenuring enough to be worth the extra memory allocation.

    Additionally, when moving from point A to point B, and loading chunks, then stuff would tenure faster. Unavoidable. But I could make sure that the size was enough that it never overflowed survivor -- letting survivor fill up to the point that any surviving object must be copied into tenured space even if it's a short-term temporary is a disaster in CMS -- even when moving through an extreme hill, or a cave world/nether.

    What I learned, and this will be modpack dependent, is roughly this:
    1. If you have a good handle on new (eden+survivor), and the minfree/maxfree settings (hint: Java's defaults for free space are way too high, something like 50% free, it can be happy with about 20-25%), then tenured will not grow excessively.
    2. You can monitor the program/modpack, and determine what you need for survivor (how much stuff will survive for 30 seconds)
    3. By raising eden as large as you can afford, for that given level of tenured plus survivor, you can determine how big to make new -- and then give it a little bit more just-in-case
    4. And this will minimize the total memory used by Java, and the best "system friendly" behavior.

    My thinking on this one isn't quite the same as Eyamaz's. I don't use occupancy fraction only. I let Java adjust it's timing on this.

    What I do pay attention to is minfree. If I have minfree of 15, and occupancy of 80, then it will do constant minor collections; if I have minfree of 22, and occupancy of 80, then it will expand memory allocation. I'm still trying to figure out how to say "Don't over allocate, but don't over run the collector".

    The rest of the flags that Eyamaz uses I can't comment on. Eya has been working with J7 longer than I have -- I was on J6 until recently.[DOUBLEPOST=1392863763][/DOUBLEPOST]
    Poor? Ha.

    32 bit J6 performed better than 64bit J6.

    J7 on the mac only comes in 64 bit.

    32 bit systems have smaller data structures and overhead. They are actually able to run in smaller space.

    For my modpack, I think I needed 200 MB for tenured, 120 MB for new (ratio of 1), so that was set at 350 MB to start, 550MB max, and it ran nicely. That was for the server -- client needed different figures (bigger new, bigger max) and had additional graphics overhead.
     
    un worry and Eyamaz like this.
  16. obscurehero

    obscurehero New Member

    Thanks! Super thoughtful response.

    Sent from my Nexus 5 using Tapatalk
     
  17. Henry Link

    Henry Link Popular Member

    So if I am reading this correctly, it sounds like the server that has 32 GB available might be better off without some of the extra arguments. I would be interested in your recommendations for a E3 3.4 GHz zeon with 32 GB RAM running ubuntu 13.10.
     
  18. Henry Link

    Henry Link Popular Member

    Decided to an experiment. I went from using the current recommended server arguments to:

    Code:
    INVOCATION="java -Xms8G -Xmx8G -XX:PermSize=512m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -jar $SERVICE nogui"
    I saw about a 4 to 5 ms improvement in tick rate (used /cofh tps). So I am seriously considering leaving it this way. I do have the server scheduled to reboot twice a day in case there is memory leaks.
     
  19. obscurehero

    obscurehero New Member

    You can always profile the GC to see how it's handling. These are my recommended arguments.
     
  20. Derpysauce

    Derpysauce Well-Known Member

    I can't wait to get on my already beastily laptop and use this though I'll be "forced" to update my java
     

Share This Page