分布式搜索引擎Elasticsearch性能优化与配置

1、参数优化

文件句柄

Linux中,每一个进程默认打开的最大文件句柄数是1000,对于服务器进程来讲,显然过小,经过修改/etc/security/limits.conf来增大打开最大句柄数html

* - nofile 65535

虚拟内存设置

max_map_count定义了进程能拥有的最多内存区域node

sysctl -w vm.max_map_count=262144

修改/etc/elasticsearch/elasticsearch.ymlbootstrap

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文件中有以下内容bash

session required /lib/security/pam_limits.so

验证是否生效服务器

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

磁盘缓存相关参数

vm.dirty_background_ratio 这个参数指定了当文件系统缓存脏页数量达到系统内存百分之多少时(如5%)就会触发pdflush/flush/kdmflush等后台回写进程运行,将必定缓存的脏页异步地刷入外存;网络

vm.dirty_ratiosession

  • 该参数指定了当文件系统缓存脏页数量达到系统内存百分之多少时(如10%),系统不得不开始处理缓存脏页(由于此时脏页数量已经比较多,为了不数据丢失须要将必定脏页刷入外存);在此过程当中不少应用进程可能会由于系统处理文件IO而阻塞
  • 把该参数适当调小。若是cached的脏数据所占比例(这里是占MemTotal的比例)超过这个设置,系统会中止全部的应用层的IO写操做,等待刷完数据后恢复IO。因此万一触发了系统的这个操做,对于用户来讲影响很是大的
sysctl -w vm.dirty_ratio=10
sysctl -w vm.dirty_background_ratio=5

为了将设置永久保存,将上述配置项写入/etc/sysctl.conf文件中app

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

相关文章
相关标签/搜索