原文連結： https://qbox.io/blog/elasticsearch-performance-tuning-part-2-zen ES性能調優權威指南（篇二）
注：本文是ES性能調優權威指南三篇中的第二篇，第一篇翻譯參考這裡http://blog.csdn.net/kimichen123/article/details/77477812。
如果我們使用ES做主要搜尋，或者我們組織搜尋是面向使用者的特征，我們應該監視查詢延遲，并在超過門檻值的情況下采取行動。
Zen發現
Zen發現是ES狀态改變時使用的算法。它可以坐主節點選舉、故障檢測、叢集狀态維護和釋出。它是ES叢集發現和通信的預設機制。另外Azure,EC2和GCE還有其他的發現機制。
ES是基于P2P的，如果操作被代理/廣播那麼節點之間就會直接通信。索引的主API（索引、删除、搜尋）不會與主節點通信。主節點的責任是管理全局叢集狀态，并通過重新配置設定分片來執行節點加入或離開叢集。每當叢集狀态發生變化時，叢集中的其他節點會被通知新的狀态。
cluster.name允許建立隔離的叢集。預設的叢集名是elasticsearch，建議更改它以反映叢集的邏輯組名稱。
在0.x和1.x版本都支援單點傳播和多點傳播，多點傳播是預設設定。這兩個版本要使用單點傳播或者禁用多點傳播，我們可以設定
discovery.zen.ping.multicast.enabled
為false。從2.0版本單點傳播是Zen發現的唯一選擇。
資料節點和主節點通過兩種不同的方式去偵察對方：
1、Ping -它是一個節點使用發現機制發現其他節點的過程，主節點通過ping叢集中所有的其他節點以驗證其是否正在運作。
2、單點傳播-單點傳播發現需要一個主角清單來使用它作為绯聞路由器。可以設定discovery.zen.ping.unicast.hosts
為數組或者逗号分隔。節點也會ping主節 點以驗證它們是否已啟動并運作，或者是否需要啟動一個選舉過程。 Zen發現配置可以使用Cluster Update Settings API更新：
主節點選舉
discovery.zen.ping_timeout （預設3s）允許調整選舉時間來應對緩慢或者擁擠的網絡環境（更高的值以降低失敗可能）。一旦一個節點加入，它将向主節點發送一個預設為ping（discovery.zen.join_timeout）逾時時間20倍的加入請求。如果網絡較慢，就把值設大一些。值越大，發現失敗的可能就越小。
如果discovery.zen.master_election.filter_client是true，主節點選舉期間用戶端的ping會被忽略；這個設定預設是true；如果discovery.zen.master_election.filter_data是true，非主候選節點（node.data為ture，node.master為false的節點）在選舉期間會被忽略；預設值為false。
discovery.zen.minimum_master_nodes
控制一個節點應該“看到”的候選主節點的最小數量。當叢集運作炒個兩個節點時建
錯誤檢測
有兩個錯誤檢測程序正在運作。第一種是主節點ping叢集中的所有其他節點，并驗證它們是否存在。另外每個節點都要對ping主節點，以驗證其是否仍然存在，或者是否需要啟動一個選舉過程。
以下以
discovery.zen.fd
為字首的設定可以改變錯誤檢測過程:
- ping_interval - 節點ping的頻率，預設是1s.
- ping_timeout - 等待ping的響應時間，預設是 30s.
- ping_retries - 多少次失敗/逾時判斷為節點失敗，預設是3.
通知所有節點叢集變更
主節點是叢集中唯一可以對叢集狀态進行更改的節點。主節點一次處理一個叢集狀态更新，應用必要的更改，并将更新後的叢集狀态釋出到叢集中的所有其他節點。每個節點接收已釋出的消息，更新它自己的叢集狀态，并對主節點進行應答，主節點等待所有節點響應，直到逾時，然後繼續處理隊列中的下一個更新。discovery.zen.publish_timeout預設設定為30 seconds，可以通過叢集更新設定api動态更改。
無存活主節點
discovery.zen.no_master_block設定控制在無存活主節點時應該拒絕哪些操作。discovery.zen.no_master_block設定有兩個有效選項:
- all - 該節點的所有操作—包括讀寫—都會被拒絕。
- write - 寫操作會拒絕 (預設)。基于最後一個已知的叢集配置的讀取操作可以執行。
基礎的 ES discovery.zen 配置如下：
discovery.zen.fd.ping_timeout: 10sdiscovery.zen.minimum_master_nodes: 2
Discovery.zen.ping.unicast.hosts: ["master_node_01″,"master_node_02″,"master_node_03″] discovery.zen.fd.ping_timeout表明節點逾時時間是10秒。單點傳播主機是 "master_node_01 ","master_node_02", "master_node_03"。此外，完成一個選舉至少需要兩個主節點加入，并讓當選的節點作為主要節點。我們有3個主節點。
允許Doc Values 或者列存儲壓縮
對字段排序時，ES需要通路每一個比對查詢的文檔的值。反向索引在搜尋時表現得很好，但它不是對字段值進行排序的理想結構: 當搜尋時,我們需要能夠将詞比對到文檔清單，但是在排序和聚合時或者腳本通路字段時，我們需要比對文檔的詞。換言之，我們需要 ”uninvert“反向索引。這個“uninverted” 結構往往稱為”column-store“，并将單個字段的所有值存儲在一個單獨的資料列中，這樣就可以非常高效地進行排序之類的操作。
Doc values是磁盤資料結構，在索引文檔時就建立使得資料通路模式成為可能。他們存儲類似_source的值，但是一種更易于排序和聚合的面向列的方式。
參考 - Kubernetes Series: Understanding Why Container Architecture is Important to the Future of Your Business
Doc values支援除analyzed string的所有字段類型。Doc values在索引生成，同時建立了反向索引。這意味着Doc values是在每個段上生成的并且不可變的，就像用于搜尋的反向索引一樣。而且與反向索引一樣，doc values被序列号到磁盤。這對性能和伸縮性來說至關重要。
在磁盤上序列話持久資料，我們可以依靠作業系統的檔案系統緩存管理記憶體，而不是在JVM堆上保留結構。當資料的“工作集”小于可用記憶體的情況下，作業系統将自然地将doc values儲存在記憶體中。這提供了與堆資料結構相同的性能。
但是當工作集大于可用記憶體時，作業系統按需對doc values頁換出換入。這顯然比純記憶體結構更慢，但是它的優點是伸縮性遠遠超過了伺服器的記憶體容量。如果這些資料結構完全在堆中，那麼唯一的選擇便是OutOfMemory （或者像作業系統一樣實作頁）。
支援doc values的字段預設是開啟的。我們我們确認不需要排序或聚合或者通過script通路字段，為了節約磁盤空間可以禁用doc values。
設定doc_values: false以禁用doc values。例如我建立了一個新索引，其中"user_id"字段禁止doc values。設定doc_values: false使得該字段不能用于聚合、排序或者scripits。
curl -XPUT localhost:9200/my_index -d '{
"mappings": {
"my_type": {
"properties": {
"user_id": {
"type": "string",
"index": "not_analyzed",
"doc_values": false
}
}
}
}
}' 也可以通過配置反向配置：通過doc values為字段提供聚合，但是禁用反向索引使其無法搜尋。例如以下是啟用聚合但是索引是禁用的，使得字段無法被查詢或者搜尋。
curl -XPUT localhost:9200/my_index -d'{
"mappings": {
"my_type": {
"properties": {
"user_id": {
"type": "string",
"index": "not_analyzed",
"doc_values": true,
"index": "no"
}
}
}
}
}'
ES在以下情形下應使用doc values:
- 字段排序；
- 字段聚合；
- 特定過濾器 (例如 geolocation filters)；
- fields使用了Scripts。
禁止、小心DELETE_all
删除索引API允許删除存在的索引。
curl -XDELETE 'localhost:9200/index_one/' 上例删除了索引名為index_one的索引。指定索引、别名或者通配符是必須的。删除API适用于通過逗号分隔清單的多個索引，或者使用_all or *删除所有索引（慎用）。
參考: Why Is the Supergiant Packing Algorithm Unique? How Does It Save Me Money?
為了禁止使用通配符或者_all删除索引，可以設定action.destructive_requires_name為true。這個設定也可通過叢集更新設定API改變。更新的設定可以是永久的（适用于重新開機）也可以是臨時的（重新開機時無效）。以下是執行個體：
永久更新：
curl -XPUT localhost:9200/_cluster/settings -d '{
"persistent" : {
"action.destructive_requires_name" : true
}
}'
臨時更新：
curl -XPUT localhost:9200/_cluster/settings -d '{
"transient" : {
"action.destructive_requires_name" : true
}
}' 叢集會傳回更新後的配置，上一個請求的傳回結果是：
{
"persistent" : {},
"transient" : {
"action.destructive_requires_name" : "true"
}
}' 叢集設定傳回：
curl -XGET localhost:9200/_cluster/settings
Transient cluster settings take precedence over persistent cluster settings, which take precedence over settings configured in the elasticsearch.yml config file. For this reason it is preferable to use the elasticsearch.yml file only for local configurations, and set all cluster-wider settings with the settings API.
臨時叢集設定優于永久叢集設定，這些設定優于在elasticsearch.yml中的設定配置。由于該原因 elasticsearch.yml 适合本地配置，而使用settings API設定叢集的設定。
禁用或最小化重新整理映射請求到主節點
如果在字段映射中頻繁更改或将新字段添加到索引中，那麼ES叢集可能會被大量的refresh_mappings 請求所淹沒。這并不是很重要，但是它可以影響叢集的性能。這個問題在2.0版本之前更常見。 配置參數可以這樣使用（/etc/elasticsearch.yml）：
indices.cluster.send_refresh_mapping: false 這是什麼?它是如果工作的？
當一個節點在處理索引請求時檢測到一個新字段時它将更新自己的映射，并将映射發送到主節點。當主節點發送下一個叢集狀态時，新的映射可能仍然存在于主的等待任務隊列中。在這種情況下，資料節點将接收到映射的“舊”版本。 盡管這是一個沖突，但并不是很差：叢集最終會有一個正确的mapping。 就資料節點而言，主節點擁有較早版本的映射，是以向主節點發送一個重新整理映射請求。 如果一個系統更新映射十分頻繁，這會産生驚人的部落效應，是以禁用這個功能是有意義的。indices.cluster.send_refresh_mapping 允許我們禁止這種敏感行為，進而消除資料節點到主節點的重新整理映射請求。即使沒有配置 send_refresh_mapping ，主節點最終也會看到原始的映射變更并發送一個更新後的叢集狀态。 注意，當發生相反情況時，發送重新整理映射十分重要。由于某種原因，主節點和存在索引的實際節點相比處于領先或者沖突，在這種情況下，重新整理映射将在主節點上記錄警告。
![Jmeter監聽器圖形結果插件[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)