GET _cat/indices/post?vhealth status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open post_two vVGUNqf9RfyqPwIei7VD4A 5 2 10011876 2774293 12.2gb 3.9gb
/** Expert: scores one merge; subclasses can override. */protected MergeScore score(List<SegmentCommitInfo> candidate, boolean hitTooLarge, long mergingBytes, IndexWriter writer) throws IOException {long totBeforeMergeBytes = 0;long totAfterMergeBytes = 0;long totAfterMergeBytesFloored = 0;for(SegmentCommitInfo info : candidate) {final long segBytes = size(info, writer);totAfterMergeBytes += segBytes;totAfterMergeBytesFloored += floorSize(segBytes);totBeforeMergeBytes += info.sizeInBytes();}// Roughly measure "skew" of the merge, i.e. how// "balanced" the merge is (whether the segments are// about the same size), which can range from// 1.0/numSegsBeingMerged (good) to 1.0 (poor). Heavily// lopsided merges (skew near 1.0) is no good; it means// O(N^2) merge cost over time:final double skew;//這里如果大段置位了，也就是這一組曾經(jīng)超過(guò)過(guò)大段，雖然后來(lái)又替換，但是應(yīng)該是接近大段的。這樣下次就不用合并了，所以給的優(yōu)先級(jí)比較高// 這樣的話就會(huì)給更高的優(yōu)先級(jí)if (hitTooLarge) {// Pretend the merge has perfect skew; skew doesn't// matter in this case because this merge will not// "cascade" and so it cannot lead to N^2 merge cost// over time:skew = 1.0/maxMergeAtOnce;} else {//對(duì)于其他情況，就用這個(gè)組合中最大的segment的size 除以組合內(nèi)所有元素的size,理論上除非組合中所有元素一樣大，否則，skew肯定大于0.1, 段的差異越大，這個(gè)值越大skew = ((double) floorSize(size(candidate.get(0), writer)))/totAfterMergeBytesFloored;}// Strongly favor merges with less skew (smaller// mergeScore is better):// mergeScore 越小越好double mergeScore = skew;// Gently favor smaller merges over bigger ones. We// don't want to make this exponent too large else we// can end up doing poor merges of small segments in// order to avoid the large merges://對(duì)merge后的總量size取指數(shù)運(yùn)算,這樣說(shuō)來(lái)，合并后總量越大對(duì)應(yīng)計(jì)算的mergeScore越大，優(yōu)先級(jí)也就越低， 越小則優(yōu)先級(jí)越高，但是，因?yàn)橹笖?shù)很小，所以影響不是很大，也就是更偏向于先合并小段// 輕輕地偏愛(ài)較小的合并而不是較大的合并，我們不想使此指數(shù)太大，否則我們最終可能會(huì)因?yàn)闉榱吮苊獯蠛喜⒍鴮?duì)小段進(jìn)行不良合并mergeScore *= Math.pow(totAfterMergeBytes, 0.05);// Strongly favor merges that reclaim deletes://這個(gè)是保留率，就是刪除以后的總量和執(zhí)行刪除前的總量final double nonDelRatio = ((double) totAfterMergeBytes)/totBeforeMergeBytes;//這里看對(duì)壓縮比還是比較重視的，保有率越低越好，reclaimDeletesWeight是一個(gè)設(shè)置值，用來(lái)控制壓縮率在打分中所占的權(quán)重，默認(rèn)是2，建議的是不超過(guò)3，如果是0的話，壓縮率就不影響打分了mergeScore *= Math.pow(nonDelRatio, reclaimDeletesWeight);final double finalMergeScore = mergeScore;return new MergeScore() {@Overridepublic double getScore() {return finalMergeScore;}@Overridepublic String getExplanation() {return "skew=" + String.format(Locale.ROOT, "%.3f", skew) + " nonDelRatio=" + String.format(Locale.ROOT, "%.3f", nonDelRatio);}};}
