JVM Arguments for Modded Minecraft (Updated 12/30/13)
- Thread starter Eyamaz
- Start date
sorry, i haven't had much time to get into it yet. thanksgiving and FTB stuff.
edit: are you using the arguments exactly as specified and only increasing Xms and Xmx to the needed amount? your running into oom
ermgen errors which shouldn't be happening unless you are lowering your permgen or not giving following the rule of you need at least a 1GB buffer between what you want your heap at and what it should be.
ie if you have 7GB of RAM available to allocate, you should only be allocating 6GB at the most.
if your running this server along side the client, your just going to get into a lot of issues. these arguments are not designed for that.
edit: are you using the arguments exactly as specified and only increasing Xms and Xmx to the needed amount? your running into oom
ermgen errors which shouldn't be happening unless you are lowering your permgen or not giving following the rule of you need at least a 1GB buffer between what you want your heap at and what it should be.ie if you have 7GB of RAM available to allocate, you should only be allocating 6GB at the most.
if your running this server along side the client, your just going to get into a lot of issues. these arguments are not designed for that.
Last edited:
It "shouldn't" if you have a decent computer to do it off of, but the extra compiler threads I'm forcing make using these less than an ideal set up for doing it.
Oh god no, incremental mode was horrible in my testing...
You could try just removing the CICompilerCountPerCPU from both client and server, but it's going to take longer for classes/methods to compile and possibly hurt performance for an extended period of time. If you're not having any issues, I wouldn't worry about it.
I haven't had a chance to test these in a VPS environment, but that would be the only flag that would cause issues I believe.
You could try just removing the CICompilerCountPerCPU from both client and server, but it's going to take longer for classes/methods to compile and possibly hurt performance for an extended period of time. If you're not having any issues, I wouldn't worry about it.
I haven't had a chance to test these in a VPS environment, but that would be the only flag that would cause issues I believe.
Not using a VPS either, just my home machine. It's the cheapest option
I was giving the clients the arguments mostly because "if it's good for the server it can't be that bad for the client". Didn't think they could possibly conflict.
It's not an issue of client/server, it's an issue of multiple VMs running on the same machine. Unless you have a good computer, you're going to have a lot of contention between them.
Oh, how much more contention can it be compared to any two multi-threaded programs when either or both might want to use NUM_CPU's for a temporary batch of multi-threading that normally lasts only a fraction of a second, occasionally 2-3 seconds, and every 60-300 seconds for 10-15 seconds?
A lot actually. Java is getting better about how threads are handled, but there can still be issues with GC threads from different VMs fighting for CPU threads. Add in all the OS threads, and you get issues.
This is actually why I don't use the ParallelGCThreads = n-1.
If one VM happens to hog a cpu for garbage collection during a full gc, and the thread of a second VM's CMS is on the same core, your second VM may well end up with a stop the world event.
If anything, I would have to recommend ParallelCMSThreads=n, but I haven't been able to do proper tests on it yet.
Actually gave it a test run today... the client suffered from microstutter (still FPS over 100 but constant intermittent stuttering) when I did not have your arguments in place (or only just some basic ones). Whatever contention there may be, it seems that the server is much more aggressively hogging resources when the client is not "hogging back", so to speak. I've put the arguments back in now since that gives me perfectly smooth gameplay, and in the end that's what counts
Thanks for the code! But I seem to have a little problem with it :S . As soon s I launch the server with it, it immediately closes, it doesn't even open really.
I checked that my system met all the requirements (Windows x64, Latest x64 Java, and I have 3 extra GB free to allocate to the server) But for some reason it just won't work. Any idea how to fix this?
I play on the same computer I run it on (Not by choice :S ).
Edit: Ok, i used "Pause" (Woo, I learned something) After the code to see what the cmd prompt said, and it said "'-Xms2048m' is not recognized as an internal or external command, operable program or batch file".
I checked that my system met all the requirements (Windows x64, Latest x64 Java, and I have 3 extra GB free to allocate to the server) But for some reason it just won't work. Any idea how to fix this?
I play on the same computer I run it on (Not by choice :S ).
Edit: Ok, i used "Pause" (Woo, I learned something) After the code to see what the cmd prompt said, and it said "'-Xms2048m' is not recognized as an internal or external command, operable program or batch file".
Last edited:
Ohhhh, I see, I accidentally wrote over the first part of the command. Thanks! Heh.....
well, not really asking for support, i just know nothing about java and had previously put some arguments in the vanilla launcher that didn't seem to cause any harm, if i had not seen the different iterations of code for different launchers I would've just pasted it in to see if it worked, which i will probably do anyway, but since I don't know anything about them, i thought I'd ask if it would work or not.
Out of memory when creating a world?
1. Do you have PermGen raised up to at least 128 mb? (I put -XX:MaxPermSize=150m in my configs).
2. Heap space ... well, single player, ATG can easily consume 400 MB, and today I had 600 MB while testing a world with underground biomes and giant hills. So, make sure you've got enough.
I guess the best answer is: pay attention to the amount of memory your modpack needs.
-XX:+PrintHeapAtGC -XX:+PrintGCDetails
1. Do you have PermGen raised up to at least 128 mb? (I put -XX:MaxPermSize=150m in my configs).
2. Heap space ... well, single player, ATG can easily consume 400 MB, and today I had 600 MB while testing a world with underground biomes and giant hills. So, make sure you've got enough.
I guess the best answer is: pay attention to the amount of memory your modpack needs.
-XX:+PrintHeapAtGC -XX:+PrintGCDetails
I'm running 32-bit 3GB RAM , and modified the server arguments from the from the front page.
Decreased ram to 768m (-Xmx768m) and PermSize to 128m (-XX
ermSize=128) and removed Reserved Code Cache argumentIn my case, this led to no more out of memory problems. It seemed counter-intuitive to reduce ram, but using F3 - my RAM utilization never exceeds 75%, the world and new chunks now loads smoothly and FPS has more than doubled