1戒幔、bootstrap check

經(jīng)常會(huì)碰到一些es的用戶诗茎，遇到一些奇怪的問題敢订，主要是因?yàn)樗麄儧]有配置一些重要的設(shè)置。在es以前的老版本中昭齐，對這些設(shè)置錯(cuò)誤的配置阱驾，會(huì)在日志里記錄一些warning告警怪蔑。但是有時(shí)候用戶會(huì)忽略這些日志中的告警信息饮睬。為了確保說這些設(shè)置的錯(cuò)誤配置告警信息可以引起用戶的注意，es的新版本中引入了bootstrap check割去，也就是啟動(dòng)時(shí)檢查呻逆。

這些啟動(dòng)時(shí)檢查操作咖城，會(huì)檢查許多es和系統(tǒng)的設(shè)置呼奢，將這些配置的值跟es期望的安全值去進(jìn)行比較握础。如果es在development mode下，那么失敗的檢查僅僅在日志中打印warning简烘。如果es運(yùn)行在生產(chǎn)模式下孤澎，任何啟動(dòng)時(shí)檢查的失敗都會(huì)導(dǎo)致es拒絕啟動(dòng)覆旭。

2、development mode vs. production mode

默認(rèn)情況下絮供，es綁定到localhost hostname壤靶，來進(jìn)行http和內(nèi)部通信贮乳。這對于下載es并簡單試用一下恬惯，包括日常的開發(fā)酪耳，都是非常方便的，但是對于生產(chǎn)環(huán)境是不行的颈将。如果要組件一個(gè)es集群晴圾，es實(shí)例必須能夠通過內(nèi)部通信協(xié)議互相連通噪奄，所必須綁定通信到一個(gè)外部的接口上勤篮。因此如果一個(gè)es實(shí)例沒有綁定通信到外部接口（默認(rèn)情況下），那么就認(rèn)為es是處于開發(fā)模式下账劲。反之涤垫，如果綁定通信到外部接口竟终，那么就是處于生產(chǎn)模式下统捶。

可以通過http.host和transport.host，單獨(dú)配置http的傳輸匆绣。這就可以配置一個(gè)es實(shí)例通過http可達(dá)崎淳，但是卻不觸發(fā)生產(chǎn)模式愕把。

因?yàn)橛袝r(shí)用戶需要將通信綁定到外部解耦來測試client的調(diào)用。對于這種場景嚣镜，es提供了single-node恢復(fù)模式（將discovery.type設(shè)置為single-node）菊匿，配置過后计福，一個(gè)節(jié)點(diǎn)會(huì)選舉自己作為master，而且不會(huì)跟其他任何節(jié)點(diǎn)組成集群疹蛉。

如果在生產(chǎn)模式下運(yùn)行一個(gè)single node實(shí)例可款，就可以規(guī)避掉啟動(dòng)時(shí)檢查（不要將通信綁定到外部接口闺鲸，或者將通信綁定到外部接口，但是設(shè)置discovery type為single-node）摸恍。在這種場景下立镶，可以設(shè)置es.enforce.bootstrap.checks為true（通過jvm參數(shù)來設(shè)置）媚媒，來強(qiáng)制bootstrap check的執(zhí)行。

3缭召、heap size check

如果jvm啟動(dòng)的時(shí)候設(shè)置的初始隊(duì)大小和最大堆大小不同嵌巷，可能會(huì)導(dǎo)致es運(yùn)行期間的暫停，因?yàn)閖vm堆在系統(tǒng)運(yùn)行期間可能會(huì)改變大小靡努。為了避免這種jvm resize導(dǎo)致的es進(jìn)程暫停晓折，建議啟動(dòng)jvm時(shí)已维，將初始堆大小和最大堆大小設(shè)置的相等垛耳。除此之外，如果bootstrap.memory_lock被啟用了栈雳，jvm會(huì)在啟動(dòng)期間鎖定jvm的初始大小哥纫。

如果要通過heap size check痴奏，就必須合理設(shè)置heap size读拆。

默認(rèn)情況下，es的jvm堆的最小和最大大小都是2g暑诸。如果在生產(chǎn)環(huán)境中使用个榕，應(yīng)該配置合理的heap size確保es有足夠的堆內(nèi)存可以使用芥喇。

在jvm.options中設(shè)置的Xms和Xmx會(huì)用來分配jvm堆內(nèi)存帶澳。

這些設(shè)置的值依賴于服務(wù)器上可用的總內(nèi)存大小苛让。下面是一些最佳實(shí)踐的建議：

（1）將heap的最小和最大大小設(shè)置為一樣大
（2）es有更多的heap大小狱杰，就有更多的內(nèi)存用來進(jìn)行緩存厅须，但是過大的jvm heap可能會(huì)導(dǎo)致長時(shí)間的gc停頓
（3）不要設(shè)置最大heap size超過物理內(nèi)存的50%，很專業(yè)昂才能給核心的file system cache留下足夠的內(nèi)存
（4）不要將Xmx設(shè)置超過32GB错沽，否則jvm無法啟用compressed oops眶拉，將對象指針進(jìn)行壓縮忆植，確認(rèn)日志里有heap size [1.9gb], compressed ordinary object pointers [true]
（5）更好的選擇是朝刊，heap size設(shè)置的小于zero-based compressed ooops，也就是26GB冯挎，但是有時(shí)也可以是30GB房官。通過-XX:+UnlockDiagnosticVMOptions -XX:+PrintCompressedOopsMode開啟對應(yīng)易阳，確認(rèn)有heap address: 0x000000011be00000, size: 27648 MB, zero based Compressed Oops吃粒，而不是heap address: 0x0000000118400000, size: 28672 MB, Compressed Oops with base: 0x00000001183ff000
（6）在jvm.options文件中事示，可以通過如下方式來配置heap size

-Xms2g
-Xmx2g

（7）也可以通過ES_JAVA_OPTS環(huán)境變量來設(shè)置heap size

ES_JAVA_OPTS="-Xms2g -Xmx2g"

4僻肖、file descriptor check

file descriptor是unix操作系統(tǒng)的一種數(shù)據(jù)結(jié)構(gòu)臀脏，用來track打開的文件。在unix操作系統(tǒng)中秒啦，所有東西都是file余境。比如，file可以是物理文件含末，虛擬文件佣盒，或者網(wǎng)絡(luò)socket沼撕。es需要大量的file descriptor务豺，比如說每個(gè)shard都由多個(gè)segment和其他文件組成，還有跟其他節(jié)點(diǎn)之間的網(wǎng)絡(luò)通信連接笼沥。

因?yàn)閑s要使用大量的file descriptor奔浅，所以如果file descriptor耗盡的話汹桦，會(huì)是一場災(zāi)難舞骆，甚至可能會(huì)導(dǎo)致數(shù)據(jù)丟失督禽。盡量給es的file descriptor提升到65536总处，甚至更高鹦马。

可以在/etc/security/limits.conf中，設(shè)置nofile為65536

GET _nodes/stats/process?filter_path=**.max_file_descriptors

可以用上面這行代碼檢查每個(gè)node上的file descriptor數(shù)量

lucene會(huì)使用大量的文件客冈，同時(shí)es也會(huì)使用大量的socket在節(jié)點(diǎn)間和client間進(jìn)行通信蔑滓，這些都是需要大量的file descriptor的。但是通常來說遇绞，現(xiàn)在的linux操作系統(tǒng)键袱，都是給每個(gè)進(jìn)程默認(rèn)的1024個(gè)file descriptor的，這對于一個(gè)es進(jìn)程來說是遠(yuǎn)遠(yuǎn)不夠的摹闽。

我們需要將es進(jìn)程的file descriptor增加到非常非常大蹄咖，比如說65535個(gè)。一般需要根據(jù)我們的操作系統(tǒng)的文檔來查看如何設(shè)置file descriptor付鹿。然后可以直接對es集群查看GET澜汤，來確認(rèn)file descriptor的數(shù)量：

{
  "cluster_name": "elasticsearch",
  "nodes": {
    "nLd81iLsRcqmah-cuHAbaQ": {
      "timestamp": 1471516160318,
      "name": "Marsha Rosenberg",
      "transport_address": "127.0.0.1:9300",
      "host": "127.0.0.1",
      "ip": [
        "127.0.0.1:9300",
        "NONE"
      ],
      "process": {
        "timestamp": 1471516160318,
        "open_file_descriptors": 155,
        "max_file_descriptors": 10240, 
        "cpu": {
          "percent": 0,
          "total_in_millis": 25084
        },
        "mem": {
          "total_virtual_in_bytes": 5221900288
        }
      }
    }
  }
}

5、memory lock check

如果jvm進(jìn)行一個(gè)major gc的話舵匾，那么就會(huì)涉及到heap中的每一個(gè)內(nèi)存頁俊抵，此時(shí)如果任何一個(gè)內(nèi)存頁被swap到了磁盤上徽诲，那么此時(shí)就會(huì)被swap回內(nèi)存中。這就會(huì)導(dǎo)致很多的磁盤讀寫開銷钱贯，而這些磁盤讀寫開銷如果節(jié)省下來，可以讓es服務(wù)更多的請求。有很多方法可以配置系統(tǒng)禁止swap拿愧。其中一種方法就是讓jvm去lock heap內(nèi)存在物理內(nèi)存中券敌，設(shè)置bootstrap.memory_lock即可卑雁。

GET _nodes?filter_path=**.mlockall

檢查一下，mlockall是否開啟扣甲，如果是false，那么說明lock memory失敗了，而且日志里可能會(huì)有unable to lock jvm memory的字樣

可能就是因?yàn)檫\(yùn)行es的用戶沒有l(wèi)ock memory的權(quán)限，此時(shí)就需要進(jìn)行授權(quán)

/etc/security/limits.conf

設(shè)置memlock為unlimited即可完成授權(quán)

另外一個(gè)原因?qū)е耹ock memory失敗，可能是因?yàn)榕R時(shí)目錄胰耗，/tmp用noexec option來mount了

那么就需要設(shè)置ES_JAVA_OPTS费尽，export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djava.io.tmpdir=/path/to/temp/dir"

或者在jvm.options中設(shè)置這個(gè)參數(shù)

6、maximum number of thread check

es會(huì)將每個(gè)請求拆分成多個(gè)stage匀油，然后將stage分配到不同的線程池中去執(zhí)行。在es中有多個(gè)線程池來執(zhí)行不同的任務(wù)弛车。所以es會(huì)創(chuàng)建許多的線程啃勉。最大線程數(shù)量的檢查會(huì)確保說双妨，es實(shí)例有權(quán)限去創(chuàng)建足夠的線程。如果要通過這個(gè)檢查，必須允許es進(jìn)程能夠創(chuàng)建超過2048個(gè)線程膏孟。

/etc/security/limits.conf噪舀，在這個(gè)文件中界逛，用nproc來設(shè)置

7该溯、maximum size virtual memory check

es使用mmap來將索引映射到es的address space中，這可以讓jvm heap外但是內(nèi)存中的索引數(shù)據(jù)，可以有非常告訴的讀寫速度。因此es需要擁有unlimited address space。最大虛擬內(nèi)存大小的檢查，會(huì)要求es進(jìn)程有unlimited address space曙咽。

/etc/security/limits.conf洒嗤，設(shè)置as為unlimited

8吉挣、maximum map count check

要高效使用mmap的話终吼，es同樣要求創(chuàng)建許多memory-mapped area姆打。因此要求linux內(nèi)核允許進(jìn)程擁有至少262144個(gè)memory-mapped area痊剖，需要通過sysctl設(shè)置vm.max_map_count至少超過262144叮贩。

9杨箭、client jvm check

jvm有兩種模式呛牲，client jvm和server jvm涮阔。不同的jvm會(huì)用不同的編譯器來從java源碼生成可執(zhí)行機(jī)器代碼伟阔。client jvm被優(yōu)化了來減少startup time和內(nèi)存占用奏夫，server jvm被優(yōu)化了來最大化性能。兩種jvm之間的性能區(qū)別是很明顯的。client jvm check會(huì)確保es沒有運(yùn)行在client jvm下增炭。必須使用server jvm模式來啟動(dòng)es哎甲，而server jvm是默認(rèn)的。

10、use serial collector check

針對不同的工作負(fù)載码党，jvm提供了不同的垃圾回收器。串行化垃圾回收期對于單cpu機(jī)器或者小內(nèi)存耻姥，是很有效的。但是對于es來說，用串行化垃圾回收器，會(huì)成為一場性能上的災(zāi)難缀雳。因此這個(gè)check會(huì)確保es沒有被配置使用串行化垃圾回收器。es默認(rèn)的就是cms垃圾回收器竞膳。

11、system call filter check

es會(huì)根據(jù)不同的操作系統(tǒng)來安裝system call filter，用來阻止執(zhí)行作為defense機(jī)制的fork相關(guān)system call八秃，進(jìn)而避免任意代碼執(zhí)行的攻擊纳本。這個(gè)check會(huì)檢查是否允許system call filter混移，然后安裝這些system call filter。避免bootstrap.system_call_filter設(shè)置為false验残。

12、OnError and OnOutOfMemoryError check

jvm參數(shù)肢础，OnError和OnOutOfMemoryError允許在jvm遇到了fatal error或者是OutOfMemoryErro的時(shí)候，執(zhí)行我們預(yù)定義的命令通砍。然而泡徙，默認(rèn)情況下杉辙，es system call filter是啟用的，這些filter是阻止forking操作的兔毙。因此祭饭，用OnError和OnOutOfMemroyError和system call filter是不兼容的胆建。這個(gè)check會(huì)檢查沿侈，如果啟用了system call filter篡腌，還設(shè)置了這兩個(gè)jvm option限匣，那么就不能啟動(dòng)鼎俘。所以不要在jvm option中設(shè)置這兩個(gè)參數(shù)脯丝。

13晕拆、early-access check

jdk提供了early-access快照堤器，為即將到來的版本表蝙。這些版本不適合用作生產(chǎn)環(huán)境寸齐。這個(gè)check會(huì)檢查有沒有使用jdk的early-access快照版本伴网。我們應(yīng)該用jdk穩(wěn)定版本返奉，而不是試用版本崖堤。

14捷犹、G1 GC check

jdk 8的jvm早期版本中的g1 gc，有已知的問題可能導(dǎo)致索引破損澜公。在JDK 8u40之前的版本都有這個(gè)問題姆另。這個(gè)check會(huì)檢查是否使用了那種早期的JDk版本。