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.2: We now play with -XX:TargetSurvivorRatio=n to reduce waste in new, permitting more | |
| 6 | ## space to be used | |
| 7 | ||
| 8 | # Configurables: | |
| 9 | # -d32 is for heap size up to 2.5gb. | |
| 10 | # Change to "-d64 XX:+UseCompressedOops" if you use more. | |
| 11 | # ** Mention that flag specifically, do not rely on it being autoset. | |
| 12 | # ** Known and documented JVM bug -- https://forums.oracle.com/forums/thread.jspa?messageID=10017916 | |
| 13 | ||
| 14 | # CMSInitiatingOccupancyFraction: Determine how frequently to do a full CMS | |
| 15 | # sweep. Lines like: | |
| 16 | # 1308.811: [Full GC (System) ... | |
| 17 | # indicate "CMS failure". This means a full "pause the app and full GC". | |
| 18 | # Too many: Lower the percentage. | |
| 19 | # Too low a percentage: More CMS full sweeps (looks like:) | |
| 20 | # 171.808: [GC [1 CMS-initial-mark: 212329K(367040K)] ... | |
| 21 | # and usually many, many more lines after that, ending with | |
| 22 | # 173.156: [CMS-concurrent-reset: 0.003/0.003 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] | |
| 23 | # Note the time stamps between those. | |
| 24 | ||
| 25 | # -XX:+UseAdaptiveGCBoundary -- apparently, adjust the boundary between new and tenured as needed. | |
| 26 | # Nice to see; did not know about it before. | |
| 27 | # Sadly, it seems to have no effect. | |
| 28 | ||
| 29 | # -XX:+CMSIncrementalMode: Tells the garbage collector to break the job into many small parts. | |
| 30 | # May result in better performance. Essential on systems with few cores. | |
| 31 | ||
| 32 | # Memory tuning: | |
| 33 | # Command line controls total heap, and "new". "Tenured" is the difference. | |
| 34 | # Bigger "new": Less frequent collections. | |
| 35 | ||
| 36 | # These numbers are in "Megabytes", the java "m" suffix. | |
| 37 | ||
| 38 | # The rule of memory tuning: | |
| 39 | # SurvivorSpace * (SurvivorRatio + 2) = New | |
| 40 | # ("SurvivorSpace" is twice the actual surviving threshold.)
| |
| 41 | # SurvivorSpace * SurvivorRatio = Eden. | |
| 42 | # Two additional survivor spaces are used to copy surviving objects across minor collections. | |
| 43 | ||
| 44 | # MAX: Maximum heap space used. | |
| 45 | # Does not include permanent (byte/compiled code) | |
| 46 | # Does not include JVM overhead | |
| 47 | MAX=800 | |
| 48 | ||
| 49 | # Tenured: Desired long-term storage space | |
| 50 | # Will vary based on mods, and "loaded chunks" | |
| 51 | # -- how many parties of players close to each other. | |
| 52 | # | |
| 53 | # Starting assumption: 250 for 1 person, plus 50 per group | |
| 54 | # of players near each other. | |
| 55 | # | |
| 56 | # That is a guess. Please report what numbers work for your server. | |
| 57 | Tenured=350 | |
| 58 | ||
| 59 | # Most important tuning number. Survivor. | |
| 60 | # Making this higher: Fewer full collections, but more wasted space. | |
| 61 | # During startup, expect this to overflow frequently. | |
| 62 | # Dynamic maps wants this at least 100, preferrably 125. | |
| 63 | # Actual space allocated is 2 spaces, each one twice this size. | |
| 64 | # "waste/overhead" will be two about to three times this number. | |
| 65 | # *** Maximum of 1/6rd of "new" | |
| 66 | # Pay attention to the tenuring distribution logs. | |
| 67 | # *** This should be enough for generation 3 95%+ of the time. *** | |
| 68 | # ** TOO SMALL WILL KILL YOUR GARBAGE COLLECTION ** | |
| 69 | # ** TOO BIG WILL WASTE SPACE ** | |
| 70 | SurvivorCopySize=12 | |
| 71 | ||
| 72 | # Survivor target ratio. Java defaults to 50%, which wastes a lot of space. If you know how much | |
| 73 | # you need (see below), you can set this value higher; this gives less waste and "better performance". | |
| 74 | ||
| 75 | TargetSurvivorRatio=90 | |
| 76 | ||
| 77 | ## Notes on "SurvivorCopySize": | |
| 78 | # Flying around in creative mode, in already generated chunks will want | |
| 79 | # at least 30-35, preferrably 40 meg. | |
| 80 | # Standing around, single player, can be happy with less than 1. | |
| 81 | # Even in Mystcraft, with massive amounts of decay everywhere, 95% of the time 1 meg suffices. | |
| 82 | # Moving around a little, doing basic building/digging, about 3. | |
| 83 | # | |
| 84 | # The rule: You want to see "new threshold 4 (max 4)" most of the time. | |
| 85 | # The total value at age three -- | |
| 86 | # - age 3: 36712 bytes, 5897520 total | |
| 87 | # should be less than this 95% of the time. | |
| 88 | # 12 meg is more than enough for one person with EBXL, Mystcraft, Twilight Forest, | |
| 89 | # and Custom Ore Gen. Even in EBXL's extreme jungle with Mystcraft's decay littering the ground. | |
| 90 | # | |
| 91 | # The single biggest factor is chunks loaded; that will depend more on parties than on players, | |
| 92 | # and the speed at which they move. Adjust to your server, and your mods. | |
| 93 | # | |
| 94 | # Single player won't need that much. Really. | |
| 95 | - | # Summary: Approximately desiredEden, plus 4 times SurvivorCopySpace, |
| 95 | + | |
| 96 | # Second most important tuning. Eden. | |
| 97 | # Making this bigger means less frequent small collections. | |
| 98 | # General rule: Make this as big as your memory can handle. | |
| 99 | # Must be at least 2x SurvivorCopySize. Java requires it to be | |
| 100 | # an integer multiple of that value. | |
| 101 | ||
| 102 | desiredEden=100 | |
| 103 | ||
| 104 | # Summary: Approximately desiredEden, plus 2 times Survivor, | |
| 105 | # plus 100, will be used by java to start the heap. Up to a max of MAX. | |
| 106 | # Script will attempt to ensure at least Tenured space exist; | |
| 107 | # should exit with a message if it cannot. | |
| 108 | # | |
| 109 | # In theory, Java will allocate extra space to new or tenured as needed. | |
| 110 | # In practice, I've never seen it increase "new". | |
| 111 | - | Survivor=$((2 * $SurvivorCopySize)) |
| 111 | + | |
| 112 | # I suspect I've now gotten it to increase "new" as demand goes up. | |
| 113 | # | |
| 114 | # See the bottom of the config section for more. | |
| 115 | ||
| 116 | # If your shell cannot do math, replace these with an appropriate constant | |
| 117 | ||
| 118 | MaxNew=$(($MAX - $Tenured)) | |
| 119 | ||
| 120 | ## Survivor=$((2 * $SurvivorCopySize)) | |
| 121 | ## Working with survivor target. "2" is for 50%. For 90%, it's much closer to 1. | |
| 122 | ## What we want is 100 / target percentage, as the ratio instead of 2. | |
| 123 | ## For integer only shell math, we re-write as (100 * survivor) / target, which gives us | |
| 124 | ## close integer to the desired result -- as close as we can get in the shell. | |
| 125 | ||
| 126 | Survivor=$(( ($SurvivorCopySize * 100 ) / $TargetSurvivorRatio )) | |
| 127 | ||
| 128 | ## Equally, the "3" in sanity test is from 3 bins -- two survivors, one eden. | |
| 129 | - | MaxRatio=$(($MaxNew / $Survivor - 2 )) |
| 129 | + | ## But that does NOT change here -- it's still the sanity test lower limit. |
| 130 | - | desiredRatio=$(($desiredEden / $Survivor)) |
| 130 | + | |
| 131 | sanityTest=$((3 * $Survivor)) | |
| 132 | if [ $sanityTest -gt $MaxNew ] | |
| 133 | then | |
| 134 | echo Memory config error >& 2 | |
| 135 | exit 1 | |
| 136 | fi | |
| 137 | - | echo Debug: Max ratio $MaxRatio, desiredRatio $desiredRatio, Max new $MaxNew |
| 137 | + | |
| 138 | - | echo Debug: desired eden $desiredEden, survivor $Survivor |
| 138 | + | |
| 139 | - | echo Debug: desiredNew: $desiredNew, bigger new: $biggerNew. Compare to eden/max. |
| 139 | + | |
| 140 | # The idea: | |
| 141 | # 1. Find the multiple of Survivor that is bigger than S and less than MN. | |
| 142 | # 2. Determine survivor ratio from that. Subtract 2 (java.) | |
| 143 | # 3. Specify -Xmn for new, and survivor ratio, to set eden and new. | |
| 144 | ||
| 145 | # "New" will be Eden plus 2* Survivor. | |
| 146 | ||
| 147 | # MaxRatio -- what the ratio is if we use all of maxnew. | |
| 148 | MaxRatio=$(( ($MaxNew / $Survivor) - 2 )) | |
| 149 | # DesiredRatio -- what the ratio is based on declared eden space | |
| 150 | # There is no "-2" here -- this will allocate eden plus 2* survivor. | |
| 151 | desiredRatio=$(( ($desiredEden / $Survivor) )) | |
| 152 | ||
| 153 | # SurvivorSpace * (SurvivorRatio + 2) = New | |
| 154 | ||
| 155 | # Now check for "desired Eden". If survivor is not an exact multiple of DE, | |
| 156 | # then we have just rounded down. Test for this, and if so, see if we can | |
| 157 | # raise it up (watch out for maxnew) | |
| 158 | ||
| 159 | ## TODO! FIXME! This is a cheap approximation | |
| 160 | if ( [ $(( $desiredRatio + 1 )) -le $MaxRatio ] ) | |
| 161 | then desiredRatio=$(( $desiredRatio + 1 )) | |
| 162 | - | START=$(($NEW + 50)) |
| 162 | + | |
| 163 | ||
| 164 | desiredNew=$(($Survivor * ($desiredRatio + 2) )) | |
| 165 | biggerNew=$(($Survivor * ($MaxRatio + 2) )) | |
| 166 | ||
| 167 | echo Debug: Max ratio $MaxRatio, desiredRatio $desiredRatio | |
| 168 | echo Debug: biggerNew $biggerNew, should be less than MaxNew $MaxNew | |
| 169 | echo Debug: desired eden $desiredEden, survivor $Survivor, actual new $desiredNew | |
| 170 | ||
| 171 | # desiredNew: Gives an eden up to, not bigger, than desiredEden. | |
| 172 | # biggerNew: Gives an eden at least as big as desiredEden. | |
| 173 | # FIXME: DesiredNew / ratio should be smallest at least as big as desiredEden | |
| 174 | # This means, if less, then add 1 to ratio and add to new. | |
| 175 | # | |
| 176 | # "Bigger" assigns ALL non-tenured memory to new. | |
| 177 | ||
| 178 | - | -XX:MinHeapFreeRatio=12 \ |
| 178 | + | |
| 179 | ||
| 180 | # Choose one of these pairs | |
| 181 | ||
| 182 | - | -jar new_server.jar nogui |
| 182 | + | |
| 183 | NEW=$desiredNew | |
| 184 | RATIO=$desiredRatio | |
| 185 | ||
| 186 | # Tenured is small -- specified tenured space. | |
| 187 | ## Should Not Be Needed -- "NewSize" and "MaxNewSize" specified separately. | |
| 188 | # In theory, Java should now adjust new as neeed. | |
| 189 | #NEW=$biggerNew | |
| 190 | #RATIO=$MaxRatio | |
| 191 | ||
| 192 | START=$(($NEW + 100)) | |
| 193 | ||
| 194 | ## TESTME: Does "MaxNewSize" matter if we have adaptive GC boundary? Does it hurt? | |
| 195 | ||
| 196 | exec java \ | |
| 197 | -d32 -server \ | |
| 198 | -Xms${START}m -Xmx${MAX}m \
| |
| 199 | -XX:NewSize=${NEW}m -XX:MaxNewSize=${MaxNew}m \
| |
| 200 | -XX:+UseAdaptiveGCBoundary \ | |
| 201 | -XX:SurvivorRatio=$RATIO \ | |
| 202 | -XX:TargetSurvivorRatio=$TargetSurvivorRatio \ | |
| 203 | -XX:CompileThreshold=3000 \ | |
| 204 | -XX:CMSInitiatingOccupancyFraction=95 \ | |
| 205 | \ | |
| 206 | -XX:MaxPermSize=150m \ | |
| 207 | -XX:+UseConcMarkSweepGC -XX:+UseParNewGC \ | |
| 208 | -XX:MaxHeapFreeRatio=20 \ | |
| 209 | -XX:MinHeapFreeRatio=15 \ | |
| 210 | -XX:MaxTenuringThreshold=4 \ | |
| 211 | -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution \ | |
| 212 | -XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log \ | |
| 213 | -jar new_server.jar nogui 147test | |
| 214 | ||
| 215 | # The last word of that exec statement -- '147test' -- is just something that shows up in | |
| 216 | # the process list, so I can tell which process is which server (each copy of this script | |
| 217 | # has a different name in that field). |