If you are running the Minecraft server on a multi-processor or multi-core system, there are some things you can do with Java's garbage collector settings to help speed things up (perhaps significantly in some cases). For example, lag spikes that were occurring on my server disappeared after I made these adjustments. ricin in particular gave me a heads up about trying a different GC.
Without getting into technical details, you can use the following two flags that should increase your server's performance:
Applied to your entire command line, it may look like this:
The -server flag forces Java to use the "server JVM," which runs a bit more optimized than the regular client JVM. Your server may already run with the server flag -- it depends on your system's specifications.
Note that these flags will overall consume more CPU and memory, but your Minecraft server will run better on the other hand.
On another note, you should run the 64-bit version of Java if you are on a 64-bit machine. This should increase performance.
It's been on my server for a few hours now (just -XX:+UseConcMarkSweepGC -XX:+UseParNewGC for now), and it's so far working better than other improvement suggestions. Of course, "other improvement suggestions" would be the guy who is convinced you can run a large server on 128mb RAM :tongue.gif:
You prolly wanna go with the document above over the whitepaper from 2005 they have published. (Having just read it and seeing it conflicts with the above doc they've also published, I am unimpressed. Heh.)
The server should run with only one core without this tweak (as far as the GC is concerned), unless your system was previously detected as a server-class machine (in which case, it was already running with a parallel GC).
However, the actual Minecraft server itself does not really use more than one core. It is not even thread safe at the moment.
In a RAM rich environment, would it be logical to keep -Xms 2048(or whatever the value -Xmx is) in the command line?
I don't see a difference with or without it, aside from the commit size being constant with -Xms while it is dynamic without -Xms .
Having -Xms prevents the JVM from needing to resize its memory allocation occasionally, so if there is free RAM, -Xms should stay. I don't know if there is a big hit from resize operations, but the articles I read noted it as a potential point of optimization.
With the new methods of Garbage Collection, does it come at any expense, such as CPU usage as it runs?
-XX:ParallelGCThreads=2 would allow faster GC correct? but would it double the amount of CPU GC can use?
I'm messing around with the settings you suggested, but I don't have enough data yet to tell much.
Your mileage with ParallelGCThreads might vary, as you can only have so many threads before it stops helping. Having just one thread has already done wonders for me.
There *are* some downsides with the Concurrent Low Pause Collector though. It does consume more CPU. To quote this article:
The concurrent collector trades processor resources (which would otherwise be available to the application) for shorter major collection pause times. The concurrent part of the collection is done by a single garbage collection thread. On an N processor system when the concurrent part of the collection is running, it will be using 1/ Nth of the available processor power. On a uniprocessor machine it would be fortuitous if it provided any advantage (see the section on Incremental mode for the exception to this statement). The concurrent collector also has some additional overhead costs that will take away from the throughput of the applications, and some inherent disadvantages (e.g., fragmentation) for some types of applications. On a two processor machine there is a processor available for applications threads while the concurrent part of the collection is running, so running the concurrent garbage collector thread does not "pause" the application. There may be reduced pause times as intended for the concurrent collector but again less processor resources are available to the application and some slowdown of the application should be expected. As N increases, the reduction in processor resources due to the running of the concurrent garbage collector thread becomes less, and the advantages of the concurrent collector become more.
You can also use the Throughput Collector (default one) but with parallel collection threads, but my personal experience with that has not been as good. (The flag is -XX:+UseParallelGC, but you have to make sure that you are not using the flags that I noted in this thread as those are for the CLPC.)