Elasticsearch - 配置詳解

jopen 9年前發布 | 12K 次閱讀 ElasticSearch 搜索引擎

1.1. 基本配置

elasticsearch 的config文件夾里面有兩個配置文 件:elasticsearch.yml和logging.yml,第一個是es的基本配置文件,第二個是日志配置文件,es也是使用log4j來記錄日 志的,所以logging.yml里的設置按普通log4j配置文件來設置就行了。下面主要講解下 elasticsearch.yml這個文件中可配置的東西。

cluster.name: elasticsearch

配置es的集群名稱,默認是elasticsearch,es會自動發現在同一網段下的es,如果在同一網段下有多個集群,就可以用這個屬性來區分不同的集群。

node.name: "Franz Kafka"

節點名,默認隨機指定一個name列表中名字,該列表在es的jar包中config文件夾里name.txt文件中,其中有很多作者添加的有趣名字。

node.master: true

指定該節點是否有資格被選舉成為node,默認是true,es是默認集群中的第一臺機器為master,如果這臺機掛了就會重新選舉master。

node.data: true

指定該節點是否存儲索引數據,默認為true。

index.number_of_shards: 5

設置默認索引分片個數,默認為5片。

index.number_of_replicas: 1

設置默認索引副本個數,默認為1個副本。

path.conf: /path/to/conf

設置配置文件的存儲路徑,默認是es根目錄下的config文件夾。

path.data: /path/to/data

設置索引數據的存儲路徑,默認是es根目錄下的data文件夾,可以設置多個存儲路徑,用逗號隔開,例:

path.data: /path/to/data1,/path/to/data2

path.work: /path/to/work

設置臨時文件的存儲路徑,默認是es根目錄下的work文件夾。

path.logs: /path/to/logs

設置日志文件的存儲路徑,默認是es根目錄下的logs文件夾

path.plugins: /path/to/plugins

設置插件的存放路徑,默認是es根目錄下的plugins文件夾

bootstrap.mlockall: true

設置為true來鎖住內存。因為當jvm開始swapping時es的效率會降低,所以要保證它不swap,可以把ES_MIN_MEM 和 ES_MAX_MEM兩個環境變量設置成同一個值,并且保證機器有足夠的內存分配給es。同時也要允許elasticsearch的進程可以鎖住內存,linux下可以通過`ulimit -l unlimited`命令。

network.bind_host: 192.168.0.1

設置綁定的ip地址,可以是ipv4或ipv6的,默認為0.0.0.0。 

network.publish_host: 192.168.0.1

設置其它節點和該節點交互的ip地址,如果不設置它會自動判斷,值必須是個真實的ip地址。

network.host: 192.168.0.1

這個參數是用來同時設置bind_host和publish_host上面兩個參數。

transport.tcp.port: 9300

設置節點間交互的tcp端口,默認是9300。

transport.tcp.compress: true

設置是否壓縮tcp傳輸時的數據,默認為false,不壓縮。

http.port: 9200

設置對外服務的http端口,默認為9200。

http.max_content_length: 100mb

設置內容的最大容量,默認100mb

http.enabled: false

是否使用http協議對外提供服務,默認為true,開啟。

gateway.type: local

gateway的類型,默認為local即為本地文件系統,可以設置為本地文件系統,分布式文件系統,hadoop的HDFS,和amazon的s3服務器。

gateway.recover_after_nodes: 1

設置集群中N個節點啟動時進行數據恢復,默認為1。

gateway.recover_after_time: 5m

設置初始化數據恢復進程的超時時間,默認是5分鐘。

gateway.expected_nodes: 2

設置這個集群中節點的數量,默認為2,一旦這N個節點啟動,就會立即進行數據恢復。

cluster.routing.allocation.node_initial_primaries_recoveries: 4

初始化數據恢復時,并發恢復線程的個數,默認為4。

cluster.routing.allocation.node_concurrent_recoveries: 2

添加刪除節點或負載均衡時并發恢復線程的個數,默認為4。

indices.recovery.max_size_per_sec: 0

設置數據恢復時限制的帶寬,如入100mb,默認為0,即無限制。

indices.recovery.concurrent_streams: 5

設置這個參數來限制從其它分片恢復數據時最大同時打開并發流的個數,默認為5。

discovery.zen.minimum_master_nodes: 1

設置這個參數來保證集群中的節點可以知道其它N個有master資格的節點。默認為1,對于大的集群來說,可以設置大一點的值(2-4)

discovery.zen.ping.timeout: 3s

設置集群中自動發現其它節點時ping連接超時時間,默認為3秒,對于比較差的網絡環境可以高點的值來防止自動發現時出錯。

discovery.zen.ping.multicast.enabled: false

設置是否打開多播發現節點,默認是true。

discovery.zen.ping.unicast.hosts: ["host1", "host2:port", "host3[portX-portY]"]

設置集群中master節點的初始列表,可以通過這些節點來自動發現新加入集群的節點。

下面是一些查詢時的慢日志參數設置

index.search.slowlog.level: TRACE
index.search.slowlog.threshold.query.warn: 10s
index.search.slowlog.threshold.query.info: 5s
index.search.slowlog.threshold.query.debug: 2s
index.search.slowlog.threshold.query.trace: 500ms
index.search.slowlog.threshold.fetch.warn: 1s
index.search.slowlog.threshold.fetch.info: 800ms
index.search.slowlog.threshold.fetch.debug:500ms
index.search.slowlog.threshold.fetch.trace: 200ms


1.2. 高級配置(線程池)

一個Elasticsearch節點會有多個線程池,但重要的是下面四個:

索引(index):主要是索引數據和刪除數據操作(默認是cached類型)

搜索(search):主要是獲取,統計和搜索操作(默認是cached類型)

批量操作(bulk):主要是對索引的批量操作(默認是cached類型)

更新(refresh):主要是更新操作(默認是cached類型)

可以通過給設置一個參數來改變線程池的類型(type),例如,把索引的線程池改成blocking類型:

            min: 1   

            size: 30   

            wait_time: 30s  


下面是三種可以設置的線程池的類型:

cache

cache線程池是一個無限大小的線程池,如果有很請求的話都會創建很多線程,下面是個例子:

    threadpool:   

        index:   

            type: cached  


fixed

fixed線程池保持固定個數的線程來處理請求隊列。

size參數設置線程的個數,默認設置是cpu核心數的5倍

queue_size可以控制待處理請求隊列的大小。默認是設置為-1,意味著無限制。當一個請求到來但隊列滿了的時候,reject_policy參數可以控制它的行為。默認是abort,會使那個請求失敗。設置成caller會使該請求在io線程中執行。

    threadpool:   

        index:   

            type: fixed   

            size: 30   

            queue: 1000   

            reject_policy: caller  


blocking

blocking 線程池允許設置一個最小值(min,默認為1)和線程池大小(size,默認為cpu核心數的5倍)。它也有一個等待隊列,隊列的大小(queue_size )默認是1000,當這隊列滿了的時候。它會根據定好的等待時間(wait_time,默認是60秒)來調用io線程,如果超時沒有執行就會報錯。

    threadpool:   

        index:   

            type: blocking   

            min: 1   

            size: 30   

            wait_time: 30s  


筆者在實際工作中,由于程序啟動時即產生大量請求,導致隊列大小溢出的情況,從而查詢請求報錯,可以在以下2個解決方法權衡處理:

1、增加隊列長度,但隨之帶來的是CPU消耗高。

2、優化程序,適當控制程序的并發請求量。


來自:http://blog.csdn.net/xifeijian/article/details/49617775

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!