Possible Best Optimization 64-Bit 8G Intel Core2 Linux

[Idgarad]

After running 240 regressions doing a worldborder fill 100 on ext4 calculating GC times and TPS the following is as far as the metrics show the optimal configuration with the least amount of thrashing on an 8GB physical ram server. 10 Mystcraft worlds were initially set up with a maxed size quarry in each prior to the worldborder fill command being executed. Dynmap is not loaded at this time. This is listed in Linux multiline format and is a direct cut and paste. This test was done with MCPC 1.5.2 with full FTB Unleashed with Millenaire and MoCreatures installed as well as Ruins mod.

java -Dcom.sun.management.jmxremote \
-d64 -XX:+UseCompressedOops -server \
-Xms2G -Xmx3G \
-XX:NewRatio=3 \
-XX:PermSize=150m \
-XX:NewSize=114m  \
        -XX:SurvivorRatio=1 \
        -XX:CompileThreshold=300 \
-XX:+UseConcMarkSweepGC-XX:+UseParNewGC \
-XX:+CMSIncrementalPacing \
-XX:SoftRefLRUPolicyMSPerMB=0 \
-XX:CMSInitiatingOccupancyFraction=80 \
-XX:ParallelGCThreads=4 \
-XX:MaxHeapFreeRatio=25 \
        -XX:MinHeapFreeRatio=21 \
        -XX:+DisableExplicitGC \
        -XX:MaxTenuringThreshold=4 \
        -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution \
        -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log \
-XX:+AggressiveOpts \
        -jar current.jar

Criteria was based on ensuring garbage collection was performed such that no TPS report came back with <20 (All test cases that reported <20 were rejected). While not gospel this does appear to be the "best" configuration of 240 iterations that factored in various configurations. In addition of the 71 successful configurations that passed the TPS requirement this configuration completed a subsequent Dynmap fullrender in the least amount of time. Note prior to the fullrender 50 Millenaire villages were placed and a completed uptime of 120 hours without fail. All villages were within 1000 units of at least 1 other village ensuring all villages were in a chain for interaction testing. Total chunks loaded and active was 100 chunks total without players present.

Next the reported number of chunks processed was tracked and the list sorted by 'throughput' of those chunks. Any configurations that went below 10 chunks per update were culled. The remaining were then tracked with second and third quartile averages compared and ordered. The top 10 were then given a dynmap fullrender to chew on.

Final culling was a combination of Dynmap render time along with reported system load average as reported. This configuration again was top.

World Border size was set at 10000 with a 300 pad.

Java version was current as of 9/11/13.

In addition for stability testing All quarries were feeding into Enderchests and imported into an AE system with a full rack of 64K modules with 100 Quad compressed cobblestones queued up. Dirt was redirected to a void pipe prior to entering the enderchest. Bukkit plugins included:

BOSEEConomy
Creeper Collateral
Dynmap CBBridge
Essentials
mcMMO
mcCore
MobHunting
Modifyworld
PermissionsEX
Vault
WorldBorder

(Dynmap handed via the Forge version)


Lastly a player was logged in within range of a trio Millenaire Village (Norman Bourg deal). With 10 claimed faction chunks.

GC Collection seems to have a ramp up time of about 55 minutes before full stabilization (using visialgc you will see a sawtooth pattern initially for the first 55 minutes).

CPU utilization is apx 60% on average with load never exceeding 1.2 at any report point.

The 240 configurations were prepared courtesy of several really bored java gurus from the banking industry taking queues from various forums as well as work experience (and they wanted to test a new java tool that does regression testing on my shitty living room server before blowing crap up at work) so they abused my machine for minecraft 'science'.

Give it a shot and see if it improves things. Command line is configured for GC reporting as well as allowing Java's VisualVM to connect. Remember to install the visualgc plugin to view your before and after behaviors.

You can remove:
-Dcom.sun.management.jmxremote
-XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution
-XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log

to disabled additional reporting when you are comfortable with your settings. (I leave it in so I can tail -f the log to have something busy looking on my screen when people walk by )

 

[oppositeZERO]

Tested this out on my server tonight, I'm not sure if it's incorrect reporting by mcpc plus, clear lagg and essentials or whether this made it worse, But using similar settings to this I only changed the ram amounts, and the amount of threads, but I seem to be floating around 10-14tps, where I'd usually be at 19.5-20 with this amount of players on.

For reference those tps are with 15 players online, running a dual core intel xeon 5160 with 8GB of Ram for allocated to mcpc-plus-legacy

Got any suggestions?

 

[Idgarad]

Tested this out on my server tonight, I'm not sure if it's incorrect reporting by mcpc plus, clear lagg and essentials or whether this made it worse, But using similar settings to this I only changed the ram amounts, and the amount of threads, but I seem to be floating around 10-14tps, where I'd usually be at 19.5-20 with this amount of players on.

For reference those tps are with 15 players online, running a dual core intel xeon 5160 with 8GB of Ram for allocated to mcpc-plus-legacy

Got any suggestions?

It's very possible it could make it worse. The threads shouldn't be adjusted unless it is really causing issues. The RAM tweaks are more complex. Based on your server's workload likely New Ratio, Perm and New size, as well as the heap ratios also need to be adjusted if you are getting a negative effect.

The Xeon should handle 4 GC threads with no issue with Java 7 but there is enough architectural differences between the Xeon and regular Core2 series for engine optimizations that it may be these optimizations are not proper. Comparing the product specs my rig has a bit more cache which may be influencing the performance. The best thing I can suggest is record your GC.log and read it and make adjustments based on what the log is telling you. I wish I had more for you at this point but I'll see if I can dig around a bit this week and see if there is anything I can find out. If so I'll provide a follow up post.

 

[oppositeZERO]

Well, in general I was receiving poor performance with the 5160, and have since upgraded to an Intel Xeon E5-5160 based system.

I might look into the logging, and see if I can make some improvements, but this is what I'm using now (Stolen from the spigot forums) and it seems to be working fine.

java -Xms8G -Xmx8G -XX:PermSize=128m -XX:MaxPermSize=256m -XX:NewRatio=3
-XX:+UseThreadPriorities -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=1
-XX:SoftRefLRUPolicyMSPerMB=2048 -XX:CMSInitiatingOccupancyFraction=90 -XX:+DisableExplicitGC
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:MaxGCPauseMillis=50
-XX:+UseCompressedOops -XX:+OptimizeStringConcat -XX:+UseFastAccessorMethods -XX:+AggressiveOpts
-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=15 -XX:+UseStringCache -oss4M
-ss4M -XX:UseSSE=4 -XX:+UseLargePages -XX:ParallelGCThreads=2 -XX:+UseAdaptiveGCBoundary
-XX:-UseGCOverheadLimit -XX:+UseBiasedLocking -jar $SERVICE nogui"