如何進行Elasticsearch調優實踐

今天給大家介紹一下如何進行Elasticsearch調優實踐。文章的內容小編覺得不錯，現在給大家分享一下，覺得有需要的朋友可以了解一下，希望對大家有所幫助，下面跟著小編的思路一起來閱讀吧。

sed -i '/swap/s/^/#/' /etc/fstab
swapoff -a

• noatime：禁止記錄訪問時間戳，提高文件系統讀寫性能

• data=writeback： 不記錄data journal，提高文件系統寫入性能

• barrier=0：barrier保證journal先于data刷到磁盤，上面關閉了journal，這里的barrier也就沒必要開啟了

• nobh：關閉buffer_head，防止內核打斷大塊數據的IO操作

mount -o noatime,data=writeback,barrier=0,nobh /dev/sda /es_data

echo noop > /sys/block/sda/queue/scheduler

indices.memory.index_buffer_size: 15%
thread_pool.bulk.queue_size: 1024

在規模比較大的集群中，可以防止新建shard時掃描所有shard的元數據，提升shard分配速度。

cluster.routing.allocation.disk.include_relocations: false

ES底層使用Lucene存儲數據，主要包括行存（StoreFiled）、列存（DocValues）和倒排索引（InvertIndex）三部分。 大多數使用場景中，沒有必要同時存儲這三個部分，可以通過下面的參數來做適當調整：

• StoreFiled： 行存，其中占比最大的是source字段，它控制doc原始數據的存儲。在寫入數據時，ES把doc原始數據的整個json結構體當做一個string，存儲為source字段。查詢時，可以通過source字段拿到當初寫入時的整個json結構體。 所以，如果沒有取出整個原始json結構體的需求，可以通過下面的命令，在mapping中關閉source字段或者只在source中存儲部分字段，數據查詢時仍可通過ES的docvaluefields獲取所有字段的值。

  注意：關閉source后， update, updatebyquery, reindex等接口將無法正常使用，所以有update等需求的index不能關閉source。

  
  

# 關閉 _source
PUT my_index 
{
  "mappings": {
    "my_type": {
      "_source": {
        "enabled": false
      }
    }
  }
}
# _source只存儲部分字段，通過includes指定要存儲的字段或者通過excludes濾除不需要的字段
PUT my_index
{
  "mappings": {
    "_doc": {
      "_source": {
        "includes": [
          "*.count",
          "meta.*"
        ],
        "excludes": [
          "meta.description",
          "meta.other.*"
        ]
      }
    }
  }
}

• docvalues：控制列存。

  ES主要使用列存來支持sorting, aggregations和scripts功能，對于沒有上述需求的字段，可以通過下面的命令關閉docvalues，降低存儲成本。

PUT my_index
{
  "mappings": {
    "my_type": {
      "properties": {
        "session_id": { 
          "type": "keyword",
          "doc_values": false
        }
      }
    }
  }
}

• index：控制倒排索引。

  ES默認對于所有字段都開啟了倒排索引，用于查詢。對于沒有查詢需求的字段，可以通過下面的命令關閉倒排索引。

PUT my_index
{
  "mappings": {
    "my_type": {
      "properties": {
        "session_id": { 
          "type": "keyword",
          "index": false
        }
      }
    }
  }
}

• all：ES的一個特殊的字段，ES把用戶寫入json的所有字段值拼接成一個字符串后，做分詞，然后保存倒排索引，用于支持整個json的全文檢索。

  這種需求適用的場景較少，可以通過下面的命令將all字段關閉，節約存儲成本和cpu開銷。（ES 6.0+以上的版本不再支持_all字段，不需要設置）

PUT /my_index
{
  "mapping": {
    "my_type": {
      "_all": {
        "enabled": false   
      }
    }
  }
}

• fieldnames：該字段用于exists查詢，來確認某個doc里面有無一個字段存在。若沒有這種需求，可以將其關閉。

  
  

PUT /my_index
{
  "mapping": {
    "my_type": {
      "_field_names": {
        "enabled": false   
      }
    }
  }
}

對于打開了上述_source字段的index，可以通過下面的命令來把lucene適用的壓縮算法替換成 DEFLATE，提高數據壓縮率。

PUT /my_index/_settings
{
    "index.codec": "best_compression"
}

寫入數據時盡量使用下面的bulk接口批量寫入，提高寫入效率。每個bulk請求的doc數量設定區間推薦為1k~1w，具體可根據業務場景選取一個適當的數量。

POST _bulk
{ "index" : { "_index" : "test", "_type" : "type1" } }
{ "field1" : "value1" }
{ "index" : { "_index" : "test", "_type" : "type1" } }
{ "field1" : "value2" }

默認情況下，translog的持久化策略是，對于每個寫入請求都做一次flush，刷新translog數據到磁盤上。這種頻繁的磁盤IO操作是嚴重影響寫入性能的，如果可以接受一定概率的數據丟失（這種硬件故障的概率很小），可以通過下面的命令調整 translog 持久化策略為異步周期性執行，并適當調整translog的刷盤周期。

PUT my_index
{
  "settings": {
    "index": {
      "translog": {
        "sync_interval": "5s",
        "durability": "async"
      }
    }
  }
}

寫入Lucene的數據，并不是實時可搜索的，ES必須通過refresh的過程把內存中的數據轉換成Lucene的完整segment后，才可以被搜索。默認情況下，ES每一秒會refresh一次，產生一個新的segment，這樣會導致產生的segment較多，從而segment merge較為頻繁，系統開銷較大。如果對數據的實時可見性要求較低，可以通過下面的命令提高refresh的時間間隔，降低系統開銷。

PUT my_index
{
  "settings": {
    "index": {
        "refresh_interval" : "30s"
    }
  }
}

ES的一個index由多個shard組成，而一個shard其實就是一個Lucene的index，它又由多個segment組成，且Lucene會不斷地把一些小的segment合并成一個大的segment，這個過程被稱為merge。默認值是Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2))，當節點配置的cpu核數較高時，merge占用的資源可能會偏高，影響集群的性能，可以通過下面的命令調整某個index的merge過程的并發度：

PUT /my_index/_settings
{
    "index.merge.scheduler.max_thread_count": 2
}

當用戶顯示指定id寫入數據時，ES會先發起查詢來確定index中是否已經有相同id的doc存在，若有則先刪除原有doc再寫入新doc。這樣每次寫入時，ES都會耗費一定的資源做查詢。如果用戶寫入數據時不指定doc，ES則通過內部算法產生一個隨機的id，并且保證id的唯一性，這樣就可以跳過前面查詢id的步驟，提高寫入效率。 所以，在不需要通過id字段去重、update的使用場景中，寫入不指定id可以提升寫入速率。基礎架構部數據庫團隊的測試結果顯示，無id的數據寫入性能可能比有_id的高出近一倍，實際損耗和具體測試場景相關。

# 寫入時指定_id
POST _bulk
{ "index" : { "_index" : "test", "_type" : "type1", "_id" : "1" } }
{ "field1" : "value1" }
# 寫入時不指定_id
POST _bulk
{ "index" : { "_index" : "test", "_type" : "type1" } }
{ "field1" : "value1" }

對于數據量較大的index，一般會配置多個shard來分攤壓力。這種場景下，一個查詢會同時搜索所有的shard，然后再將各個shard的結果合并后，返回給用戶。對于高并發的小查詢場景，每個分片通常僅抓取極少量數據，此時查詢過程中的調度開銷遠大于實際讀取數據的開銷，且查詢速度取決于最慢的一個分片。開啟routing功能后，ES會將routing相同的數據寫入到同一個分片中（也可以是多個，由index.routingpartitionsize參數控制）。如果查詢時指定routing，那么ES只會查詢routing指向的那個分片，可顯著降低調度開銷，提升查詢效率。 routing的使用方式如下：

# 寫入
PUT my_index/my_type/1?routing=user1
{
  "title": "This is a document"
}
# 查詢
GET my_index/_search?routing=user1,user2 
{
  "query": {
    "match": {
      "title": "document"
    }
  }
}

• 存為text類型的字段（string字段默認類型為text）： 做分詞后存儲倒排索引，支持全文檢索，可以通過下面幾個參數優化其存儲方式：

• norms：用于在搜索時計算該doc的_score（代表這條數據與搜索條件的相關度），如果不需要評分，可以將其關閉。

• indexoptions：控制倒排索引中包括哪些信息（docs、freqs、positions、offsets）。對于不太注重score/highlighting的使用場景，可以設為 docs來降低內存/磁盤資源消耗。

• fields: 用于添加子字段。對于有sort和聚合查詢需求的場景，可以添加一個keyword子字段以支持這兩種功能。

PUT my_index
{
  "mappings": {
    "my_type": {
      "properties": {
        "title": { 
          "type": "text",
          "norms": false,
          "index_options": "docs",
          "fields": {
            "raw": { 
              "type":  "keyword"
            }
          }
        }
      }
    }
  }
}

• 存為keyword類型的字段： 不做分詞，不支持全文檢索。text分詞消耗CPU資源，冗余存儲keyword子字段占用存儲空間。如果沒有全文索引需求，只是要通過整個字段做搜索，可以設置該字段的類型為keyword，提升寫入速率，降低存儲成本。 設置字段類型的方法有兩種：一是創建一個具體的index時，指定字段的類型；二是通過創建template，控制某一類index的字段類型。

# 1. 通過mapping指定 tags 字段為keyword類型
PUT my_index
{
  "mappings": {
    "my_type": {
      "properties": {
        "tags": {
          "type":  "keyword"
        }
      }
    }
  }
}
# 2. 通過template，指定my_index*類的index，其所有string字段默認為keyword類型
PUT _template/my_template
{
    "order": 0,
    "template": "my_index*",
    "mappings": {
      "_default_": {
        "dynamic_templates": [
          {
            "strings": {
              "match_mapping_type": "string",
              "mapping": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          }
        ]
      }
    },
    "aliases": {}
  }

默認情況下，ES通過一定的算法計算返回的每條數據與查詢語句的相關度，并通過score字段來表征。但對于非全文索引的使用場景，用戶并不care查詢結果與查詢條件的相關度，只是想精確的查找目標數據。此時，可以通過query-bool-filter組合來讓ES不計算score，并且盡可能的緩存filter的結果集，供后續包含相同filter的查詢使用，提高查詢效率。

# 普通查詢
POST my_index/_search
{
  "query": {
    "term" : { "user" : "Kimchy" } 
  }
}
# query-bool-filter 加速查詢
POST my_index/_search
{
  "query": {
    "bool": {
      "filter": {
        "term": { "user": "Kimchy" }
      }
    }
  }
}

寫入ES的數據最好通過某種方式做分割，存入不同的index。常見的做法是將數據按模塊/功能分類，寫入不同的index，然后按照時間去滾動生成index。這樣做的好處是各種數據分開管理不會混淆，也易于提高查詢效率。同時index按時間滾動，數據過期時刪除整個index，要比一條條刪除數據或deletebyquery效率高很多，因為刪除整個index是直接刪除底層文件，而deletebyquery是查詢-標記-刪除。

舉例說明，假如有[modulea,moduleb]兩個模塊產生的數據，那么index規劃可以是這樣的：一類index名稱是modulea + {日期}，另一類index名稱是module_b+ {日期}。對于名字中的日期，可以在寫入數據時自己指定精確的日期，也可以通過ES的ingest pipeline中的index-name-processor實現（會有寫入性能損耗）。

# module_a 類index
- 創建index：
PUT module_a@2018_01_01
{
    "settings" : {
        "index" : {
            "number_of_shards" : 3, 
            "number_of_replicas" : 2 
        }
    }
}
PUT module_a@2018_01_02
{
    "settings" : {
        "index" : {
            "number_of_shards" : 3, 
            "number_of_replicas" : 2 
        }
    }
}
...
- 查詢數據：
GET module_a@*/_search
#  module_b 類index
- 創建index：
PUT module_b@2018_01_01
{
    "settings" : {
        "index" : {
            "number_of_shards" : 3, 
            "number_of_replicas" : 2 
        }
    }
}
PUT module_b@2018_01_02
{
    "settings" : {
        "index" : {
            "number_of_shards" : 3, 
            "number_of_replicas" : 2 
        }
    }
}
...
- 查詢數據：
GET module_b@*/_search

分片（shard）：一個ES的index由多個shard組成，每個shard承載index的一部分數據。

副本（replica）：index也可以設定副本數（numberofreplicas），也就是同一個shard有多少個備份。對于查詢壓力較大的index，可以考慮提高副本數（numberofreplicas），通過多個副本均攤查詢壓力。

shard數量（numberofshards）設置過多或過低都會引發一些問題：shard數量過多，則批量寫入/查詢請求被分割為過多的子寫入/查詢，導致該index的寫入、查詢拒絕率上升；對于數據量較大的inex，當其shard數量過小時，無法充分利用節點資源，造成機器資源利用率不高 或 不均衡，影響寫入/查詢的效率。

對于每個index的shard數量，可以根據數據總量、寫入壓力、節點數量等綜合考量后設定，然后根據數據增長狀態定期檢測下shard數量是否合理。基礎架構部數據庫團隊的推薦方案是：

• 對于數據量較小（100GB以下）的index，往往寫入壓力查詢壓力相對較低，一般設置3~5個shard，numberofreplicas設置為1即可（也就是一主一從，共兩副本） 。

• 對于數據量較大（100GB以上）的index：

• 一般把單個shard的數據量控制在（20GB~50GB）

• 讓index壓力分攤至多個節點：可通過index.routing.allocation.totalshardsper_node參數，強制限定一個節點上該index的shard數量，讓shard盡量分配到不同節點上

• 綜合考慮整個index的shard數量，如果shard數量（不包括副本）超過50個，就很可能引發拒絕率上升的問題，此時可考慮把該index拆分為多個獨立的index，分攤數據量，同時配合routing使用，降低每個查詢需要訪問的shard數量。

  
  

# 修改系統資源限制
# 單用戶可以打開的最大文件數量，可以設置為官方推薦的65536或更大些
echo "* - nofile 655360" >>/etc/security/limits.conf
# 單用戶內存地址空間
echo "* - as unlimited" >>/etc/security/limits.conf
# 單用戶線程數
echo "* - nproc 2056474" >>/etc/security/limits.conf
# 單用戶文件大小
echo "* - fsize unlimited" >>/etc/security/limits.conf
# 單用戶鎖定內存
echo "* - memlock unlimited" >>/etc/security/limits.conf

# 單進程可以使用的最大map內存區域數量
echo "vm.max_map_count = 655300" >>/etc/sysctl.conf

# TCP全連接隊列參數設置， 這樣設置的目的是防止節點數較多（比如超過100）的ES集群中，節點異常重啟時全連接隊列在啟動瞬間打滿，造成節點hang住，整個集群響應遲滯的情況
echo "net.ipv4.tcp_abort_on_overflow = 1" >>/etc/sysctl.conf
echo "net.core.somaxconn = 2048" >>/etc/sysctl.conf

# 降低tcp alive time，防止無效鏈接占用鏈接數
echo 300 >/proc/sys/net/ipv4/tcp_keepalive_time

-Xms和-Xmx設置為相同的值，推薦設置為機器內存的一半左右，剩余一半留給系統cache使用。

• jvm內存建議不要低于2G，否則有可能因為內存不足導致ES無法正常啟動或OOM

• jvm建議不要超過32G，否則jvm會禁用內存對象指針壓縮技術，造成內存浪費

• 
  

  設置內存熔斷參數，防止寫入或查詢壓力過高導致OOM，具體數值可根據使用場景調整。 indices.breaker.total.limit: 30% indices.breaker.request.limit: 6% indices.breaker.fielddata.limit: 3%

• 
  

  調小查詢使用的cache，避免cache占用過多的jvm內存，具體數值可根據使用場景調整。 indices.queries.cache.count: 500 indices.queries.cache.size: 5%

• 
  

  單機多節點時，主從shard分配以ip為依據，分配到不同的機器上，避免單機掛掉導致數據丟失。 cluster.routing.allocation.awareness.attributes: ip node.attr.ip: 1.1.1.1

# 專有master節點的配置文件（conf/elasticsearch.yml）增加如下屬性：
node.master: true 
node.data: false 
node.ingest: false 
# 數據節點的配置文件增加如下屬性（與上面的屬性相反）：
node.master: false 
node.data: true 
node.ingest: true

上面提到，ES的元信息由master節點管理，定期同步給各個節點，也就是每個節點都會存儲一份。這個元信息主要存儲在clusterstate中，如所有node元信息（indices、節點各種統計參數）、所有index/shard的元信息（mapping, location, size）、元數據ingest等。

ES在創建新分片時，要根據現有的分片分布情況指定分片分配策略，從而使各個節點上的分片數基本一致，此過程中就需要深入遍歷clusterstate。當集群中的index/shard過多時，clusterstate結構會變得過于復雜，導致遍歷clusterstate效率低下，集群響應遲滯。基礎架構部數據庫團隊曾經在一個20個節點的集群里，創建了4w+個shard，導致新建一個index需要60s+才能完成。 當index/shard數量過多時，可以考慮從以下幾方面改進：

• 降低數據量較小的index的shard數量

• 把一些有關聯的index合并成一個index

• 數據按某個維度做拆分，寫入多個集群

前面提到，ES底層采用Lucene做存儲，而Lucene的一個index又由若干segment組成，每個segment都會建立自己的倒排索引用于數據查詢。Lucene為了加速查詢，為每個segment的倒排做了一層前綴索引，這個索引在Lucene4.0以后采用的數據結構是FST (Finite State Transducer)。Lucene加載segment的時候將其全量裝載到內存中，加快查詢速度。這部分內存被稱為SegmentMemory， 常駐內存，占用heap，無法被GC。

前面提到，為利用JVM的對象指針壓縮技術來節約內存，通常建議JVM內存分配不要超過32G。當集群的數據量過大時，SegmentMemory會吃掉大量的堆內存，而JVM內存空間又有限，此時就需要想辦法降低SegmentMemory的使用量了，常用方法有下面幾個：

• 定期刪除不使用的index

• 對于不常訪問的index，可以通過close接口將其關閉，用到時再打開

• 通過force_merge接口強制合并segment，降低segment數量

基礎架構部數據庫團隊在此基礎上，對FST部分進行了優化，釋放高達40%的Segment Memory內存空間。

以上就是如何進行Elasticsearch調優實踐的全部內容了，更多與如何進行Elasticsearch調優實踐相關的內容可以搜索億速云之前的文章或者瀏覽下面的文章進行學習哈！相信小編會給大家增添更多知識,希望大家能夠支持一下億速云！