分佈式搜索引擎Elasticsearch性能優化與配置

1、參數優化

文件句柄

Linux中，每一個進程默認打開的最大文件句柄數是1000,對於服務器進程來講，顯然過小，經過修改/etc/security/limits.conf來增大打開最大句柄數

* - nofile 65535

虛擬內存設置

max_map_count定義了進程能擁有的最多內存區域

sysctl -w vm.max_map_count=262144

修改/etc/elasticsearch/elasticsearch.yml

bootstrap.mlockall: true

修改/etc/security/limits.conf, 在limits.conf中添加以下內容

* soft memlock unlimited
* hard memlock unlimited

memlock 最大鎖定內存地址空間， 要使limits.conf文件配置生效，必需要確保pam_limits.so文件被加入到啓動文件中。

確保/etc/pam.d/login文件中有以下內容

session required /lib/security/pam_limits.so

驗證是否生效

curl localhost:9200/_nodes/stats/process?pretty

磁盤緩存相關參數

vm.dirty_background_ratio 這個參數指定了當文件系統緩存髒頁數量達到系統內存百分之多少時（如5%）就會觸發pdflush/flush/kdmflush等後臺回寫進程運行，將必定緩存的髒頁異步地刷入外存；

vm.dirty_ratio

• 該參數指定了當文件系統緩存髒頁數量達到系統內存百分之多少時（如10%），系統不得不開始處理緩存髒頁（由於此時髒頁數量已經比較多，爲了不數據丟失須要將必定髒頁刷入外存）；在此過程當中不少應用進程可能會由於系統處理文件IO而阻塞
• 把該參數適當調小。若是cached的髒數據所佔比例（這裏是佔MemTotal的比例）超過這個設置，系統會中止全部的應用層的IO寫操做，等待刷完數據後恢復IO。因此萬一觸發了系統的這個操做，對於用戶來講影響很是大的

sysctl -w vm.dirty_ratio=10
sysctl -w vm.dirty_background_ratio=5

爲了將設置永久保存，將上述配置項寫入/etc/sysctl.conf文件中

vm.dirty_ratio = 10
vm.dirty_background_ratio = 5

swap調優

swap空間是一塊磁盤空間，操做系統使用這塊空間保存從內存中換出的操做系統不經常使用page數據，這樣能夠分配出更多的內存作page cache。這樣一般會提高系統的吞吐量和IO性能，但一樣會產生不少問題。頁面頻繁換入換出會產生IO讀寫、操做系統中斷，這些都很影響系統的性能。這個值越大操做系統就會更加積極的使用swap空間。

調節swappniess方法以下

sudo sh -c 'echo "0">/proc/sys/vm/swappiness'

io sched

若是集羣中使用的是SSD磁盤，那麼能夠將默認的io sched由cfq設置爲noop

sudo sh -c 'echo "noop">/sys/block/sda/queue/scheduler'

在bin/elasticsearch.in.sh中進行配置

修改配置項爲儘可能大的內存：

ES_MIN_MEM=8g
ES_MAX_MEM=8g

二者最好改爲同樣的，不然容易引起長時間GC（stop-the-world）

elasticsearch默認使用的GC是CMS GC，若是你的內存大小超過6G，CMS是不給力的，容易出現stop-the-world，建議使用G1 GC

JAVA_OPTS=」$JAVA_OPTS -XX:+UseParNewGC」
JAVA_OPTS=」$JAVA_OPTS -XX:+UseConcMarkSweepGC」

JAVA_OPTS=」$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75″
JAVA_OPTS=」$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly」

#修改成：

JAVA_OPTS=」$JAVA_OPTS -XX:+UseG1GC」
JAVA_OPTS=」$JAVA_OPTS -XX:MaxGCPauseMillis=200″

G1 GC優勢是減小stop-the-world的概率，可是CPU佔有率高

2、服務器配置

一、節點配置

cluster.name: es-cluster  //這個是配置集羣的名字，爲了能進行自動查找
node.name: "node-100" //這個是配置當前節點的名字，固然每一個節點的名字都應該是惟一的
node.master: false
node.data: true 
//這兩個配置有4種配置方法，表示這個節點是否能夠充當主節點，這個節點是否充當數據節點。
//若是你的節點數目只有兩個的話，爲了防止腦裂的狀況，須要手動設置主節點和數據節點。
//其餘狀況建議直接不設置，默認兩個都爲true

network.host: "0.0.0.0" //綁定host，0.0.0.0表明全部IP，爲了安全考慮，建議設置爲內網IP'
transport.tcp.port: 9300 //節點到節點之間的交互是使用tcp的，這個設置設置啓用的端口
http.port: 9200  //這個是對外提供http服務的端口，安全考慮，建議修改，不用默認的9200

• 當master爲false，而data爲true時，會對該節點產生嚴重負荷；

• 當master爲true，而data爲false時，該節點做爲一個協調者；

• 當master爲false，data也爲false時，該節點就變成了一個負載均衡器。

二、自動發現　

es提供了四種選擇，一種是默認實現，其餘都是經過插件實現。

• Azure discovery 插件方式，多播

• EC2 discovery 插件方式，多播

• Google Compute Engine (GCE)discovery 插件方式多播

• zen discovery默認實現 多播/單播

elasticsearch的集羣是內嵌自動發現功能的。

單播配置下，節點向指定的主機發送單播請求，配置以下：

discovery.zen.ping.multicast.enabled: false
discovery.zen.fd.ping_timeout: 100s
discovery.zen.ping.timeout: 100s
discovery.zen.minimum_master_nodes: 2
discovery.zen.ping.unicast.hosts: ["172.31.26.200", "172.31.26.222"] 

多播配置下，意思就是說，你只須要在每一個節點配置好了集羣名稱，節點名稱，互相通訊的節點會根據es自定義的服務發現協議去按照多播的方式來尋找網絡上配置在一樣集羣內的節點。和其餘的服務發現功能同樣，es是支持多播和單播的。多播和單播的配置分別根據這幾個參數：

discovery.zen.ping.multicast.enabled: true
discovery.zen.fd.ping_timeout: 100s
discovery.zen.ping.timeout: 100s
discovery.zen.minimum_master_nodes: 2
discovery.zen.ping.unicast.hosts: ["172.31.26.200"] 

• discovery.zen.ping.multicast.enabled  //這個設置把組播的自動發現給關閉了，爲了防止其餘機器上的節點自動連入。

• discovery.zen.fd.ping_timeout和discovery.zen.ping.timeout是設置了節點與節點之間的鏈接ping時長

• discovery.zen.minimum_master_nodes //這個設置爲了不腦裂。好比3個節點的集羣，若是設置爲2，那麼當一臺節點脫離後，不會自動成爲master。

• discovery.zen.ping.unicast.hosts //這個設置了自動發現的節點。

• action.auto_create_index: false //這個關閉了自動建立索引。爲的也是安全考慮，不然即便是內網，也有不少掃描程序，一旦開啓，掃描程序會自動給你建立不少索引。

多播是須要看服務器是否支持的，因爲其安全性，其實如今基本的雲服務（好比阿里雲）是不支持多播的，因此即便你開啓了多播模式，你也僅僅只能找到本機上的節點。單播模式安全，也高效，可是缺點就是若是增長了一個新的機器的話，就須要每一個節點上進行配置才生效了。

三、自動選舉

elasticsearch集羣一旦創建起來之後，會選舉出一個master，其餘都爲slave節點。可是具體操做的時候，每一個節點都提供寫和讀的操做，你不論往哪一個節點中作寫操做，這個數據也會分配到集羣上的全部節點中。

若是是從節點掛掉了

那麼首先關心，數據會不會丟呢？不會。若是你開啓了replicate，那麼這個數據必定在別的機器上是有備份的。別的節點上的備份分片會自動升格爲這份分片數據的主分片。

這裏要注意的是這裏會有一小段時間的yellow狀態時間

若是是主節點掛掉了

從節點發現和主節點鏈接不上了，那麼他們會本身決定再選舉出一個節點爲主節點。可是這裏有個腦裂的問題，假設有5臺機器，3臺在一個機房，2臺在另外一個機房，當兩個機房之間的聯繫斷了以後，每一個機房的節點會本身聚會，推舉出一個主節點。這個時候就有兩個主節點存在了，當機房之間的聯繫恢復了以後，這個時候就會出現數據衝突了

解決的辦法就是設置參數：discovery.zen.minimum_master_nodes爲3(超過一半的節點數)，那麼當兩個機房的鏈接斷了以後，就會以大於等於3的機房的master爲主，另一個機房的節點就中止服務了

對於自動服務這裏不難看出，若是把節點直接暴露在外面，無論怎麼切換master，必然會有單節點問題。因此通常咱們會在可提供服務的節點前面加一個負載均衡。

四、Too many open files

查看max_file_descriptors

curl http://localhost:9200/_nodes/process\?pretty
{
  "cluster_name" : "elasticsearch",
  "nodes" : {
    "qAZYd8jbSWKxFAcOu9Ax9Q" : {
      "name" : "Masque",
      "transport_address" : "127.0.0.1:9300",
      "host" : "127.0.0.1",
      "ip" : "127.0.0.1",
      "version" : "2.2.1",
      "build" : "d045fc2",
      "http_address" : "127.0.0.1:9200",
      "process" : {
        "refresh_interval_in_millis" : 1000,
        "id" : 31917,
        "mlockall" : true
      }
    }
  }
}

然而並無

# ps -ef | grep 'Xms' | grep -v grep | awk '{print $2}'
31917

# cat /proc/31917/limits  | grep 'Max open files'
Max open files            102400               102400               files  

官方文檔建議

Make sure to increase the number of open files descriptors on the machine (or for the user running elasticsearch). Setting it to 32k or even 64k is recommended.　

最簡單的作法, 在bin/elasticsearch文件開始的位置加入

ulimit -n 102400

五、設置合理的刷新時間　

創建的索引，不會立馬查到，這是由於elasticsearch爲near-real-time，須要配置index.refresh_interval參數，默認是1s

index.refresh_interval：1s

這樣全部新建的索引都使用這個刷新頻率

六、大量unassigned shards

其實剛搭完運行時就是status: yellow(全部主分片可用，但存在不可用的從分片), 只有一個節點, 主分片啓動並運行正常, 能夠成功處理請求, 可是存在unassigned_shards, 即存在沒有被分配到節點的從分片.(只有一個節點.....)

curl -XGET http://localhost:9200/_cluster/health\?pretty
{
  "cluster_name" : "elasticsearch",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 1,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 15,
  "active_shards" : 15,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 15,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 50.0
}

處理方式: 找臺內網機器, 部署另外一個節點， 再次檢查集羣健康, 發現unassigned_shards減小, active_shards增多，操做完後, 集羣健康從yellow恢復到 green

七、fix unassigned shards

找出UNASSIGNED分片

curl -s "http://localhost:9200/_cat/shards" | grep UNASSIGNED
index                3 p UNASSIGNED
index                3 r UNASSIGNED
index                1 p UNASSIGNED
index                1 r UNASSIGNED

查詢獲得master節點的惟一標識　

curl 'localhost:9200/_nodes/process?pretty'

{
  "cluster_name" : "elasticsearch",
  "nodes" : {
    "AfUyuXmGTESHXpwi4OExxx" : {
      "name" : "Master",

執行reroute(分屢次, 變動shard的值爲UNASSIGNED查詢結果中編號, 上一步查詢結果是1和3)

curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
        "commands" : [ {
              "allocate" : {
                  "index" : "pv-2015.05.22",
                  "shard" : 1,
                  "node" : "AfUyuXmGTESHXpwi4OExxx",
                  "allow_primary" : true
              }
            }
        ]
    }'

3、插件的安裝

集羣安裝成功以後，須要對集羣中的索引數據、運行狀況等信息進行查看，索引須要安裝一些插件，方面後續工做

一、head

經過head，能夠查看集羣幾乎全部信息，還能進行簡單的搜索查詢，觀察自動恢復的狀況等等

ES_HOME/bin/plugin -install mobz/elasticsearch-head

安裝成功以後訪問 ： http://ip:9200/_plugin/head/ 

好比：cluster health:green (2, 20) : 表示該集羣目前處於健康狀態，集羣包含2臺機器，索引總共20個分片。粗線綠框表示主分片，細線綠框爲備份分片

二、bigdesk

 bigdesk是集羣監控插件，經過該插件能夠查看整個集羣的資源消耗狀況，cpu、內存、http連接等等

ES_HOME/bin/plugin -install lukas-vlcek/bigdesk       

安裝完成以後輸入：http://ip:9200/_plugin/bigdesk/#nodes便可

能夠查看單個節點的資源使用狀況，包括JVM、Thread Pools、OS、Process、HTTP&Transport、Indice、File system

插件大全：http://www.searchtech.pro/elasticsearch-plugins

 

參考文檔

http://m.blog.csdn.net/article/details?id=51203276https://www.elastic.co/blog/performance-considerations-elasticsearch-indexinghttp://blog.csdn.net/napoay/article/details/52002180http://blog.csdn.net/napoay/article/details/52012249http://blog.csdn.net/laigood/article/details/7421173http://www.yalasao.com/77/elasticsearch-config-tuninghttp://keenwon.com/1359.htmlhttp://es.xiaoleilu.com/080_Structured_Search/40_bitsets.htmlhttp://lxw1234.com/archives/2015/12/582.htmhttp://www.wklken.me/posts/2015/05/23/elasticsearch-issues.htmlhttp://chrissimpson.co.uk/elasticsearch-yellow-cluster-status-explained.htmlhttps://www.elastic.co/guide/en/elasticsearch/reference/2.2/cluster-health.htmlhttp://zhaoyanblog.com/archives/732.htmlhttp://www.cnblogs.com/huangpeng1990/p/4364341.htmlhttp://zhaoyanblog.com/archives/555.html http://kibana.logstash.es/content/elasticsearch/principle/auto-discovery.htmlhttps://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-zen.htmlhttp://www.cnblogs.com/yjf512/p/4897294.html