ElasticSearch性能优化方案

ElasticSearch性能优化主要分为4个方面的优化。

一、服务器部署

1、增加1-2台服务器,用于负载均衡节点elasticSearch的配置文件中有2个参数:node.master和node.data。这两个参数搭配使用时,能够帮助提供服务器性能。

node.master: false

node.data: true

该node服务器只作为一个数据节点,只用于存储索引数据。使该node服务器功能 单一,只用于数据存储和数据查询,降低其资源消耗率。

node.master: true

node.data: false

该node服务器只作为一个主节点,但不存储任何索引数据。该node服务器将使用

自身空闲的资源,来协调各种创建索引请求或者查询请求,讲这些请求合理分发到相关 的node服务器上。

node.master: false

node.data: false

该node服务器即不会被选作主节点,也不会存储任何索引数据。

该服务器主要用 于查询负载均衡。在查询的时候,通常会涉及到从多个node服务器上查询数据,并请求分发到多个指定的node服务器,并对各个node服务器返回的结果进行一个汇总处理, 最终返回给客户端。

注:服务器充足情况下可以根据上述配置

2、在生产环境尽量关闭data节点服务器中的http功能,同时也不要安装head, bigdesk, marvel等监控 插件,这样保证data节点服务器只需处理创建/更新/删除/查询索引数据等操作。http功能可以在非数据节点服务器上开启,上述相关的监控插件也安装到这些服 务器上,用于监控ElasticSearch集群状态等数据信息。这样做一来出于数据安全考虑,二来出于服务性能考虑。

参数这样设置:http.enabled: false

3、一台服务器上最好只部署一个Node,一台物理服务器上可以启动多个Node服务器节点(通过设置不同的启动port), 但一台服务器上的CPU,内存,硬盘等资源毕竟有限,从服务器性能考虑,在生产环境下不建议一台 服务器上启动多个node节点。

二、服务器配置

1.配置索引线程池的大小ElastiSearch服务器有多个线程池大小配置。主要有:index,search,suggest,get,bulk,percolate,snapshot,snapshot_data,warmer,refresh。

在此主要针对index和search进行一个配置调整。

index:创建/更新/删除索引数据。

Search:主要针对用户的各种搜索操作。

具体配置如下:

threadpool:

index:

type: fixed

size: 24(逻辑核心数*3)

queue_ size: 1000

search:

type: fixed

size: 24(逻辑核心数*3)

queue_ size: 1000

2.确定分片(shard)的数量和副本(replica)的数量  ElasticSearch在创建索引数据时,最好指定相关的shards数量和replicas,否则会使用服务器中的默认配置参数shards=5,replicas=1。  因为这两个属性的设置直接影响集群中索引和搜索操作的执行。假设你有足够的机器来持有碎片和副本,那么可以按如下规则设置这两个值:

1) 拥有更多的碎片可以提升索引执行能力,并允许通过机器分发一个大型的索引;

2) 拥有更多的副本能够提升搜索执行能力以及集群能力。对于一个索引来说,number_of_shards只能设置一次,而number_of_replicas可以使用索引更新设置API在任何时候被增加或者减少。这两个配置参数在配置文件的配置如下:

index.number_of_shards: 5(第一次分片的数值)

index.number_of_replicas: 1(可变)

3.elasticsearch.yml log日志其具体配置如下:

index.search.slowlog.level: INFO

index.search.slowlog.threshold.query.warn: 5s

index.search.slowlog.threshold.query.info: 2s

index.search.slowlog.threshold.query.debug: 500s

index.search.slowlog.threshold.query.trace: 500ms

index.search.slowlog.threshold.fetch.warn: 5s

index.search.slowlog.threshold.fetch.info: 2s

index.search.slowlog.threshold.fetch.debug: 500ms

index.search.slowlog.threshold.fetch.trace: 200ms

时间: 2024-10-29 19:11:45

ElasticSearch性能优化方案的相关文章

mysql 性能优化方案 (转)

网 上有不少MySQL 性能优化方案,不过,mysql的优化同sql server相比,更为麻烦与复杂,同样的设置,在不同的环境下 ,由于内存,访问量,读写频率,数据差异等等情况,可能会出现不同的结果,因此简单地根据某个给出方案来配置mysql是行不通的,最好能使用 status信息对mysql进行具体的优化. mysql> show global status; 可以列出mysql服务器运行各种状态值,另外,查询mysql服务器配置信息语句: mysql> show variables; 一

kvm性能优化方案

kvm性能优化方案 kvm性能优化,主要集中在cpu.内存.磁盘.网络,4个方面,当然对于这里面的优化,也是要分场景的,不同的场景其优化方向也是不同的,下面具体聊聊这4个方面的优化细节. cpu 在介绍cpu之前,必须要讲清楚numa的概念,建议先参考如下两篇文章 CPU Topology 玩转cpu-topology 查看cpu信息脚本: #!/bin/bash # Simple print cpu topology # Author: kodango function get_nr_proc

GNU Linux高并发性能优化方案

/*********************************************************** * Author : Samson * Date : 07/14/2015 * Test platform: * gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 * GNU bash, 4.3.11(1)-release (x86_64-pc-linux-gnu) * Nginx version: * Nginx 1.6.2 * Nginx 1.8.0

JDBC性能优化方案

近期用到了利用JDBC查询Oracle数据库,但是查询效率不尽人意,研究了一下JDBC方面可以优化的地方,在这里跟大家分享一下. 1.设置最优的预取值 defaultRowPrefetch:预取条数默认值 defaultBatchValue:触发查询操作的批量请求值 这两个参数的默认值都是10,我们可以通过增加这两个参数值来减少数据库请求以提高查询效率,当然具体值大小要视具体情况而定. 2.通过连接池获取连接 创建连接的代价很大,通过连接池获取连接可省去创建连接时间. 3.选择合适的Statem

Glusterfs目录ls性能优化方案分析

Glusterfs目录ls性能优化方案分析 目的和优化思路 讨论了glusterfs对文件系统爬虫rsync/ls目录性能的现有优化措施和可能的进一步优化方案.优化思路是减少本地文件系统的元数据操作,减少fuse client的负载,减少req的网络轮询次数,减少一次网络通信时间,缓存预抓取,并发,异步,bulk 传输 fuse readdirplus centos 6.4最新内核,支持fuse readdirplus.微调mount timeout参数. FUSE: Adaptive NFS-

web前端9大性能优化方案汇总

网页的性能问题是产品开发过程中的一个重要的环节,在产品成功地把功能实现后,性能能好与坏就直接影响了用户体验,以至于影响了产品的成败! 作为web前端开发者,对前端部分进行性能上的优化,是责无旁贷,刻不容缓的工作.下面简介一下9种性能优化方案. 一.罪魁祸首是http请求 一般网页,80%的响应时间花在下载网页内容(images, stylesheets, javascripts, scripts, flash等).减少请求次数是缩短响应时间的关键!可以通过简化页面设计来减少请求次数,但页面内容较

(转)Web性能优化方案

第一章 打开网站慢现状分析 在公司访问部署在IDC机房的VIP网站时会感觉很慢.是什么原因造成的?为了缩短页面的响应时间,改进我们的用户体验,我们需要知道用户的时间花在等待什么东西上. 可以跟踪一下我们的登录页面,如下图所示 从上图我们可以分析知道,HTML文档只占了总响应时间的20%,其它80%响应时间用来下载JS.CSS.图片等组件.所以WEB前端有很大的优化空间,我们将从WEB的前端优化.后端优化两方面综合考虑给出WEB的性能优化方案. 第二章 WEB前台的优化规则 一.尽量减少 HTTP

Redmine性能优化方案

近来公司redmine服务器表现很糟糕,在16核,64GRAM的机器上,压测结果竟然只有每秒5~7个请求,部分页面一个都出不来. 以下是我对Redmine性能优化方案: redmine服务器性能问题排查与优化建议: 以下建议的方案是基于redmine运行期的log文件中的render耗时.activerecord耗时,linux系统性能指标采样与 mysql 性能指标采样分析,以及redmine在不同web server下的benchmark而得:   一. 问题排查与定量分析 通过分析redm

亿级 Elasticsearch 性能优化

前言 最近一年使用 Elasticsearch 完成亿级别日志搜索平台「ELK」,亿级别的分布式跟踪系统.在设计这些系统的过程中,底层都是采用 Elasticsearch 来做数据的存储,并且数据量都超过亿级别,甚至达到百亿级别. 所以趁着有空,就花点时间整理一下具体怎么做 Elasticsearch 性能优化,希望能对 Elasticsearch 感兴趣的同学有所帮助. 背景 Elasticsearch 是一个基于 Lucene 的搜索服务器.它提供了一个分布式多用户能力的全文搜索引擎,基于