Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- #!/bin/bash
- # Startup for minecraft when using a lot of memory for
- # dynamic maps for re-rendering.
- cd "$( dirname "$0" )"
- # This is set for 2-3 players.
- ## Important: Higher "New" / "Eden" generally improves performance with little to no penalty.
- ## Garbage collection in Eden depends on the living objects (which are important), not on junk.
- ## Higher heap/"tenured" means longer garbage collections. Garbage collecting here depends on
- ## the size of tenured space -- so the more junk, the longer.
- ##
- unused="\
- -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution \
- -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log \
- -XX:+CITime -XX:+PrintCompilation \
- -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses \
- -XX:+TraceClassLoading -XX:+TraceClassUnloading \
- "
- # 7% min free is too low.
- # No indication that "max free" is even listened to -- I've never seen the heap shrink.
- # Remember the goal: Memory when needed, but keep the number of pages allocated low enough that
- # swap does not clobber the other running programs.
- #
- # If you have a 1 or 2 processor system: add incremental.
- # ** UPDATE: Looks like incremental may help a lot more than it should.
- # Need to test -- one feedback so far that it makes big help on a 8 CPU system
- #
- # Dynamic map wants a very large amount. It looks like it wants survivor size
- # of at least 40 *2 = 80 mib; that's up from the previous 12.5.
- # Correction: During render, it wants at least 60, if not 70 * 2 = 120 to 150 mib. For both survivors,
- # plus another 400+ for eden. That's crazy.
- #
- # Update: At least 100 MB during render, for temporaries. So survivor space of 200 MB...
- #
- # The best way to think of "survivor size": How much temporary stuff will you have at a time. If you use
- # more temporary stuff than this, some of it will be considered "permanent".
- #
- # Old was: New 100, survivor 6, so 6+2=8 pieces. Each is 12.5. Target survivor is half that -- 6.25. We want 35
- # instead of 6.25, or 70 instead of 12.5. Thats ... a lot.
- #
- # If we have 6 pieces -- 2 survivors, and 4 for eden -- and each piece is 70, that's 420Mib for new.
- # Survivor ratio is 6-2 = 4.
- #
- # If you don't like doing that calculation, tell oracle to fix sun's old stuff.
- # So lets see if we can play with dynmap.
- # 200 per survivor, 600 for eden.
- # That's 1 gig for new, survivor ratio 3.
- # -Xms165m -Xmx500m \
- # -XX:NewSize=100m -XX:SurvivorRatio=6 \
- java \
- -d32 -server \
- -XX:CompileThreshold=3000 \
- -XX:+UseConcMarkSweepGC -XX:+UseParNewGC \
- -XX:MaxHeapFreeRatio=20 \
- -XX:MinHeapFreeRatio=12 \
- -XX:NewSize=1g -XX:SurvivorRatio=3 \
- -Xms1300m -Xmx2000m \
- -XX:MaxTenuringThreshold=4 \
- -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution \
- -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log \
- -jar server-myst-ebxl.jar nogui test144-final
- exit 0
- # -XX:ParallelCMSThreads=n
- # Comments for that java line: ** WARNING -- BADLY OUT OF DATE **
- java \
- -d32 -server \ # For up to 2.5 GB servers
- -XX:+UseConcMarkSweepGC -Xincgc \ # define the garbage collector
- -XX:ParallelGCThreads=4 \ # Parallel GC
- -Xms300m -Xmx1g \ # Start the server with 300MB. Go up to 1 GB.
- -XX:NewSize=300m \ # Use 300 MB for "new" (eden plus survivor spaces).
- # This means about 650 MB max for long-term.
- # Observed behavior is around 350mb long-term when the server is stable.
- # Things to figure out:
- # How much memory to give to eden (for new and short lived objects) versus survivor
- # How many times an object "survives" before being promoted
- # Tune for the "normal" case of players moving over approximately a 3x3 to 5x5 chunk area
- # (Remember, the game loads r=9 chunks around you for normal (that's 17x17 chunks)
- # up to r=15 for far (31x31!!!!) for far. Yes, you can and probably will move to new areas
- # and flush it all, but that is rare. Tune for the common.
- # Keep in mind: 31x31 * 16x16 * 80 (average world height) * 4 bytes per location
- # is 75MiB! -- 16x16x4 = 1MiB, 31*31*80 is 76880
- # That's minimum long-term memory just for sitting in one chunk
- # Now consider that each time you change a chunk boundary, 16x16x4 x 31x80 -- one row of 31 new chunks
- # is loaded into short term space -- 2MB added to short term/removed from long term every time you move a little.
- #
- # Now consider that 4 bytes per location is probably a low estimate.
- # And, this doesn't take into account animals living in those chunks
- # Animals = longterm, hostile mobs = short term.
- # A large farm will raise this amount.
- #
- # Bottom line: Moving over 40x40 blocks in your base can be 4 chunks by 4 chunks
- # or approximately 16 rows of new data. That's about half of the long-term data for sitting still.
- -XX:+PrintGCHeapAtGC -XX:+PrintTenuringDistribution -XX:MaxTenuringThreshold=6 \
- -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log \ # Log and collect info
- -XX:PermSize=65m -XX:MaxPermSize=95m \ # Classes, VM overhead, etc. Raise this if you add mods.
- -jar server-myst-ebxl.jar nogui main # The server file
- ## java -Xms1250m -Xmx1250m -d32 -server -XX:+PrintGCHeapAtGC -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log -XX:+PrintGCTimeStamps -jar server-myst-ebxl.jar nogui main
- ## -XX:ParallelGCThreads=8 -XX:+TraceClassUnloading -XX:+UseParallelGC
- # -Xms1g -Xmx1g -XX:PermSize65m -XX:MaxPermSize65m -Xmn100m
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement