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). |