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

Henry Link

Popular Member
Dec 23, 2012
2,601
553
128
USA - East Coast
Ah brilliant trick there, the pause lets me see the error. Ok so the error I'm getting is -
"Unrecognized VM option 'permSize=256m'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit."

I'm such a noob.

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
 

SamB167

New Member
Jul 29, 2019
7
0
0
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
 

SamB167

New Member
Jul 29, 2019
7
0
0
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
 

Henry Link

Popular Member
Dec 23, 2012
2,601
553
128
USA - East Coast
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

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.
 

SamB167

New Member
Jul 29, 2019
7
0
0
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!
 

keybounce

New Member
Jul 29, 2019
1,925
0
0
My brain hurts,

This is what my .bat file looks like, it doesn't seem to load so I've done something wrong.
"java -Xms2048m -Xmx2048m -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
-jar ftbserver.jar nogui"

How should my file look?

Thanks again

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.
 

Ederlezi

New Member
Jul 29, 2019
7
0
0
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.
 

keybounce

New Member
Jul 29, 2019
1,925
0
0
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.
 

DZCreeper

New Member
Jul 29, 2019
1,469
0
1
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.
 

Ederlezi

New Member
Jul 29, 2019
7
0
0
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.

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"


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.

:) 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 ;)
 

DZCreeper

New Member
Jul 29, 2019
1,469
0
1
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.
 

Revemohl

New Member
Jul 29, 2019
595
0
0
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.
 

obscurehero

New Member
Jul 29, 2019
17
0
0
@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.
 

keybounce

New Member
Jul 29, 2019
1,925
0
0
The extra cores don't necessarily affect MC itself, but they do help with the GC and compiler.
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.

It's not clear that explicitly indicating tenuring threshold max does anything. The JVM dynamically adjust this value to promote to tenured.
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.

Why use CMSInitiatingOccupancyFraction? 80% is default and its not clear that starting collection earlier will improve performance
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]
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.

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.
 
  • Like
Reactions: un worry and Eyamaz

obscurehero

New Member
Jul 29, 2019
17
0
0
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.
Thanks! Super thoughtful response.

Sent from my Nexus 5 using Tapatalk
 

Henry Link

Popular Member
Dec 23, 2012
2,601
553
128
USA - East Coast
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.
 

Henry Link

Popular Member
Dec 23, 2012
2,601
553
128
USA - East Coast
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.
 

obscurehero

New Member
Jul 29, 2019
17
0
0
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.
You can always profile the GC to see how it's handling. These are my recommended arguments.