View difference between Paste ID: 9czuNyPP and FBsDCHXW
SHOW: | | - or go back to the newest paste.
1
#!/bin/bash 
2
# This line is for starting from mac os icon double click
3
cd "$( dirname "$0" )" 
4
5-
## V1.4: 64 bit version, and ** LOTS OF MEMORY ALLOCATION **
5+
## V1.5-corrected: 64 bit version, and ** LOTS OF MEMORY ALLOCATION **
6
# This is to give information for data collection.
7
# Determine how much your system uses, and then adjust numbers down to avoid waste
8
#
9
# Specifically: By making the memory pools large, we see how much is used.
10
# Then, we can determine what to cut them down to.
11
#
12
# This will probably be the last CMS version; G1GC next.
13
14
java=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Commands/java
15
16
## V1.4: Java is now customizable (see the above line), thank you oracle for a
17
## java (1.7) that does not support 32 bit servers for reduced memory consumption. 
18
19
## V1.3: The -XX:SoftRefLRUPolicyMSPerMB=0 flag got lost! Back in now.
20-
# -d32 is for heap size up to 2.5gb.
20+
21
22
## V1.2: We now play with -XX:TargetSurvivorRatio=n to reduce waste in new, permitting more
23
## space to be used
24
25
# Configurables:
26
# -d32 is for heap size up to 2.5gb. (NB: apparently only 1.5 gb on microsoft windows?)
27
# Change to "-d64 XX:+UseCompressedOops" if you use more.
28
# ** Mention that flag specifically, do not rely on it being autoset.
29
# ** Known and documented JVM bug -- https://forums.oracle.com/forums/thread.jspa?messageID=10017916
30
31-
# sweep. Lines like:
31+
32-
# 1308.811: [Full GC (System) ...
32+
33-
# indicate "CMS failure". This means a full "pause the app and full GC".
33+
34-
# Too many: Lower the percentage. 
34+
35-
# Too low a percentage: More CMS full sweeps (looks like:)
35+
# Special: New "Most important". This primarily affects long-term growth
36-
# 171.808: [GC [1 CMS-initial-mark: 212329K(367040K)] ...
36+
# of the heap. The percentage of used space before CMS starts a collection.
37-
# and usually many, many more lines after that, ending with
37+
# 95 is sufficient for general stuff. 85 is useful for things that suddenly
38-
# 173.156: [CMS-concurrent-reset: 0.003/0.003 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
38+
# need a lot.
39-
# Note the time stamps between those. 
39+
# Dynamic maps, in particular, no longer needs 125 MB of survivor -- it can
40
# get by with 60-75. It can go much lower, but then the garbage collections
41
# need to be started sooner, or else it will never have enough memory and
42
# always grow the heap.
43
#
44
# To clarify: This is obsolete -- completely -- in G1GC. 
45
# This needs to be low enough that sudden spurts of temporary memory trigger
46
# garbage collection first. 
47
# This should be re-worked as a "MB safety level" -- for example, if you have
48
# 300 MB of tenured, and want at least 30 MB free. But Java don't work that way.
49
# As tenured increases, this will also increase the "keep free" level.
50
CMSInitiatingOccupancyFraction=80
51
52
# Memory tuning:
53
# Command line controls total heap, and "new". "Tenured" is the difference.
54
# Bigger "new": Less frequent collections.
55
56
# These numbers are in "Megabytes", the java "m" suffix.
57
58
# The rule of memory tuning:
59
# SurvivorSpace * (SurvivorRatio + 2) = New
60
# ("SurvivorSpace" is twice the actual surviving threshold.)
61
# SurvivorSpace * SurvivorRatio = Eden.
62
# Two additional survivor spaces are used to copy surviving objects across minor collections.
63-
MAX=2500	
63+
64
# MAX: Maximum heap space used.
65
# Does not include permanent (byte/compiled code)
66
# Does not include JVM overhead
67
MAX=3000	
68
69
# Tenured: Desired long-term storage space
70
# Will vary based on mods, and "loaded chunks"
71
# -- how many parties of players close to each other.
72
#
73-
Tenured=350
73+
74
# of players near each other. 
75
#
76
# That is a guess. Please report what numbers work for your server.
77
Tenured=450
78-
# Dynamic maps wants this at least 100, preferably 125.
78+
79
# Most important tuning number. Survivor.
80
# Making this higher: Fewer full collections, but more wasted space.
81
# During startup, expect this to overflow frequently.
82
# Dynamic maps wants this at least 100, preferrably 125.
83
# Actual space allocated is 2 spaces, each one twice this size.
84
# "waste/overhead" will be two about to three times this number.
85
# *** Maximum of 1/6rd of "new" 
86-
SurvivorCopySize=60
86+
87
# *** This should be enough for generation 3 95%+ of the time. ***
88
# ** TOO SMALL WILL KILL YOUR GARBAGE COLLECTION **
89
# ** TOO BIG WILL WASTE SPACE **
90
## SurvivorCopySize=26
91
## 26 is too small -- memory consumption keeps going up with dynamic maps
92
#
93
# To clarify: You can easily use 12 here if you do not use dynamic maps.
94
# You can even use less, but the memory savings are not significant.
95
# You can use less if you use lowres maps.
96
# The big memory consumer is low-angle maps; the 30 degree maps of high res,
97
# or the 20 degree maps I use on my server are the big memory consumers.
98
SurvivorCopySize=100
99
100
# Survivor target ratio. Java defaults to 50%, which wastes a lot of space. If you know how much
101
# you need (see below), you can set this value higher; this gives less waste and "better performance".
102
103
TargetSurvivorRatio=90
104
105
## Notes on "SurvivorCopySize":
106
# Flying around in creative mode, in already generated chunks will want
107
#   at least 30-35, preferrably 40 meg.
108
# Standing around, single player, can be happy with less than 1.
109
# Even in Mystcraft, with massive amounts of decay everywhere, 95% of the time 1 meg suffices.
110
# Moving around a little, doing basic building/digging, about 3.
111
#
112
# The rule: You want to see "new threshold 4 (max 4)" most of the time.
113
# The total value at age three -- 
114
# - age   3:      36712 bytes,    5897520 total
115
# should be less than this 95% of the time.
116
# 12 meg is more than enough for one person with EBXL, Mystcraft, Twilight Forest,
117
# and Custom Ore Gen. Even in EBXL's extreme jungle with Mystcraft's decay littering the ground.
118-
desiredEden=200
118+
119
# The single biggest factor is chunks loaded; that will depend more on parties than on players,
120
# and the speed at which they move. Adjust to your server, and your mods.
121
#
122
# Single player won't need that much. Really.
123
124
# Second most important tuning. Eden.
125
# Making this bigger means less frequent small collections.
126
# General rule: Make this as big as your memory can handle.
127-
# ** Update! Just found a config flag conflict, and updated.
127+
128-
# I suspect I've now gotten it to increase "new" as demand goes up.
128+
129
130
desiredEden=250
131
132
# Summary: Approximately desiredEden, plus 2 times Survivor,
133
# plus 100, will be used by java to start the heap. Up to a max of MAX. 
134
# Script will attempt to ensure at least Tenured space exist;
135
# should exit with a message if it cannot.
136
#
137
# In theory, Java will allocate extra space to new or tenured as needed.
138
# In practice, I've never seen it increase "new".
139
#
140
# See the bottom of the config section for more.
141
142
# If your shell cannot do math, replace these with an appropriate constant
143
144
MaxNew=$(($MAX - $Tenured))
145
146
## Survivor=$((2 * $SurvivorCopySize))
147
## Working with survivor target. "2" is for 50%. For 90%, it's much closer to 1.
148
## What we want is 100 / target percentage, as the ratio instead of 2.
149
## For integer only shell math, we re-write as (100 * survivor) / target, which gives us
150
## close integer to the desired result -- as close as we can get in the shell.
151
152
Survivor=$(( ($SurvivorCopySize * 100 ) / $TargetSurvivorRatio ))
153
154
## Equally, the "3" in sanity test is from 3 bins -- two survivors, one eden.
155
## But that does NOT change here -- it's still the sanity test lower limit.
156
157
sanityTest=$((3 * $Survivor))
158
if [ $sanityTest -gt $MaxNew ]
159
then
160
	echo Memory config error >& 2
161
	exit 1
162
fi
163
164
# We cannot use more than MaxNew.
165
166
# The idea:
167
# 1. Find the multiple of Survivor that is bigger than S and less than MN.
168
# 2. Determine survivor ratio from that. Subtract 2 (java.)
169
# 3. Specify -Xmn for new, and survivor ratio, to set eden and new.
170
171
# "New" will be Eden plus 2* Survivor.
172
173
# MaxRatio -- what the ratio is if we use all of maxnew.
174
MaxRatio=$(( ($MaxNew / $Survivor) - 2 ))
175
# DesiredRatio -- what the ratio is based on declared eden space
176
# There is no "-2" here -- this will allocate eden plus 2* survivor.
177
desiredRatio=$(( ($desiredEden / $Survivor)  ))
178
179
# SurvivorSpace * (SurvivorRatio + 2) = New
180
181
# Now check for "desired Eden". If survivor is not an exact multiple of DE,
182
# then we have just rounded down. Test for this, and if so, see if we can
183
# raise it up (watch out for maxnew)
184
185
## TODO! FIXME! This is a cheap approximation
186
if ( [ $(( $desiredRatio + 1 )) -le $MaxRatio ] )
187
then	desiredRatio=$(( $desiredRatio + 1 ))
188
fi
189
190
desiredNew=$(($Survivor * ($desiredRatio + 2) ))
191
biggerNew=$(($Survivor * ($MaxRatio + 2) ))
192
193
echo Debug: Max ratio $MaxRatio, desiredRatio $desiredRatio
194
echo Debug: biggerNew $biggerNew, should be less than MaxNew $MaxNew
195
echo Debug: desired eden $desiredEden, survivor $Survivor, actual new $desiredNew
196
197
# desiredNew: Gives an eden up to, not bigger, than desiredEden.
198
# biggerNew: Gives an eden at least as big as desiredEden.
199
# FIXME: DesiredNew / ratio should be smallest at least as big as desiredEden
200
# This means, if less, then add 1 to ratio and add to new.
201
#
202
# "Bigger" assigns ALL non-tenured memory to new.
203
204
# Q: Desired numbers? Bigger/Max numbers?
205
206
# Choose one of these pairs
207
208-
START=$(($NEW + 100))
208+
209
NEW=$desiredNew
210
RATIO=$desiredRatio
211
212-
exec java \
212+
213-
	$JVM_SIZE \
213+
214
# In theory, Java should now adjust new as neeed.
215
#NEW=$biggerNew
216
#RATIO=$MaxRatio
217
218
START=$(($NEW + 130))
219
220-
        -XX:CMSInitiatingOccupancyFraction=95 \
220+
221
222
# A few more notes ...
223
224
# -XX:+UseAdaptiveGCBoundary -- apparently, adjust the boundary between new and tenured as needed.
225
# Nice to see; did not know about it before. 
226
# Sadly, it seems to have no effect.
227
228
# -XX:+CMSIncrementalMode: Tells the garbage collector to break the job into many small parts.
229
# May result in better performance. Essential on systems with few cores.
230-
	-jar new_server.jar nogui 147test
230+
231
exec $java \
232
	-d32 -server \
233
	-Xms${START}m -Xmx${MAX}m \
234
	-XX:NewSize=${NEW}m -XX:MaxNewSize=${MaxNew}m \
235
	-XX:+UseAdaptiveGCBoundary \
236
	-XX:SurvivorRatio=$RATIO \
237
	-XX:TargetSurvivorRatio=$TargetSurvivorRatio \
238
	-XX:CompileThreshold=3000 \
239
        -XX:CMSInitiatingOccupancyFraction=$CMSInitiatingOccupancyFraction \
240
\
241
	-XX:SoftRefLRUPolicyMSPerMB=0 \
242
        -XX:MaxPermSize=150m \
243
	-XX:+UseConcMarkSweepGC -XX:+UseParNewGC \
244
	-XX:MaxHeapFreeRatio=20 \
245
	-XX:MinHeapFreeRatio=15 \
246
	-XX:MaxTenuringThreshold=4 \
247
	-XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution \
248
	-XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log \
249
	-jar new_server.jar nogui 147MystTest
250
251
# The last word of that exec statement -- '147test' -- is just something that shows up in
252
# the process list, so I can tell which process is which server (each copy of this script
253
# has a different name in that field).