Elasticsearch高性能优化实践

Elasticsearch高性能优化实践_es批量导入数据多少为最优-CSDN博客

ES 性能调优
ES 的默认配置，是综合了数据可靠性、写入速度、搜索实时性等因素。实际使用时，我们需要根据公司要求，进行偏向性的优化。

一、写优化
假设我们的应用场景要求是，每秒 300 万的写入速度，每条 500 字节左右。

针对这种对于搜索性能要求不高，但是对写入要求较高的场景，我们需要尽可能的选择恰当写优化策略。

综合来说，可以考虑以下几个方面来提升写索引的性能：

加大 Translog Flush ，目的是降低 Iops、Writeblock。
增加 Index Refresh 间隔，目的是减少 Segment Merge 的次数。
调整 Bulk 线程池和队列。
优化节点间的任务分布。
优化 Lucene 层的索引建立，目的是降低 CPU 及 IO。
1、批量提交
ES 提供了 Bulk API 支持批量操作，当我们有大量的写任务时，可以使用 Bulk 来进行批量写入。

每次提交的数据量为多少时，能达到最优的性能，主要受到文件大小、网络情况、数据类型、集群状态等因素影响。 

通用的策略如下：Bulk 默认设置批量提交的数据量不能超过 100M。数据条数一般是根据文档的大小和服务器性能而定的，但是单次批处理的数据大小应从 5MB～15MB 逐渐增加，当性能没有提升时，把这个数据量作为最大值。

2、优化存储设备
ES 是一种密集使用磁盘的应用，在段合并的时候会频繁操作磁盘，所以对磁盘要求较高，当磁盘速度提升之后，集群的整体性能会大幅度提高。

磁盘的选择，提供以下几点建议：

使用固态硬盘（Solid State Disk）替代机械硬盘。SSD 与机械磁盘相比，具有高效的读写速度和稳定性。
使用 RAID 0。RAID 0 条带化存储，可以提升磁盘读写效率。
在 ES 的服务器上挂载多块硬盘。使用多块硬盘同时进行读写操作提升效率，在配置文件 ES 中设置多个存储路径，如下所示：
path.data:/path/to/data1,/path/to/data2。
避免使用 NFS（Network File System）等远程存储设备，网络的延迟对性能的影响是很大的。

3、合理使用合并
Lucene 以段的形式存储数据。当有新的数据写入索引时，Lucene 就会自动创建一个新的段。

随着数据量的变化，段的数量会越来越多，消耗的多文件句柄数及 CPU 就越多，查询效率就会下降。

由于 Lucene 段合并的计算量庞大，会消耗大量的 I/O，所以 ES 默认采用较保守的策略，让后台定期进行段合并，如下所述：

索引写入效率下降：当段合并的速度落后于索引写入的速度时，ES 会把索引的线程数量减少到 1。这样可以避免出现堆积的段数量爆发，同时在日志中打印出“now throttling indexing”INFO 级别的“警告”信息。
提升段合并速度：ES 默认对段合并的速度是 20m/s，如果使用了 SSD，我们可以通过以下的命令将这个合并的速度增加到 100m/s。
PUT /_cluster/settings
{
    "persistent" : {
        "indices.store.throttle.max_bytes_per_sec" : "100mb"
    }
}
4、减少Refresh的次数
Lucene 在新增数据时，采用了延迟写入的策略，默认情况下索引的 refresh_interval 为 1 秒。

Lucene 将待写入的数据先写到内存中，超过 1 秒（默认）时就会触发一次 Refresh，然后 Refresh 会把内存中的的数据刷新到操作系统的文件缓存系统中。

如果我们对搜索的实效性要求不高，可以将 Refresh 周期延长，例如 30 秒。

这样还可以有效地减少段刷新次数，但这同时意味着需要消耗更多的Heap内存。

如下所示：

index.refresh_interval:30s
5、加大Flush设置
Flush 的主要目的是把文件缓存系统中的段持久化到硬盘，当 Translog 的数据量达到 512MB 或者 30 分钟时，会触发一次 Flush。

index.translog.flush_threshold_size 参数的默认值是 512MB，我们进行修改。

增加参数值意味着文件缓存系统中可能需要存储更多的数据，所以我们需要为操作系统的文件缓存系统留下足够的空间。

6、减少副本的数量
ES 为了保证集群的可用性，提供了 Replicas（副本）支持，然而每个副本也会执行分析、索引及可能的合并过程，所以 Replicas 的数量会严重影响写索引的效率。

当写索引时，需要把写入的数据都同步到副本节点，副本节点越多，写索引的效率就越慢。

如果我们需要大批量进行写入操作，可以先禁止 Replica 复制，设置 index.number_of_replicas: 0 关闭副本。在写入完成后，Replica 修改回正常的状态。

二、线程池设置
每个Elasticsearch节点内部都维护着多个线程池，如index、search、get、bulk等，用户可以修改线程池的类型和大小，线程池默认大小跟CPU逻辑一致。

1、查看当前线程组状态
curl -XGET 'http://localhost:9200/_nodes/stats?pretty'
 
----
 
"thread_pool" : {
    "bulk" : {
      "threads" : 32,
      "queue" : 0,
      "active" : 0,
      "rejected" : 0,
      "largest" : 32,
      "completed" : 659997
    },
"index" : {
      "threads" : 2,
      "queue" : 0,
      "active" : 0,
      "rejected" : 0,
      "largest" : 2,
      "completed" : 2
    }

上面截取了部分线程池的配置，其中，最需要关注的是rejected。当某个线程池active==threads时，表示所有线程都在忙，那么后续新的请求就会进入queue中，即queue>0，一旦queue大小超出限制，如bulk的queue默认50，那么elasticsearch进程将拒绝请求（碰到bulk HTTP状态码429），相应的拒绝次数就会累加到rejected中。

解决方法：

记录失败的请求并重发
减少并发写的进程个数，同时加大每次bulk请求的size
2、核心线程池
index：此线程池用于索引和删除操作。它的类型默认为fixed，size默认为可用处理器的数量，队列的size默认为300。
search：此线程池用于搜索和计数请求。它的类型默认为fixed，size默认为可用处理器的数量乘以3，队列的size默认为1000。
suggest：此线程池用于建议器请求。它的类型默认为fixed，size默认为可用处理器的数量，队列的size默认为1000。
get：此线程池用于实时的GET请求。它的类型默认为fixed，size默认为可用处理器的数量，队列的size默认为1000。
bulk：此线程池用于批量操作。它的类型默认为fixed，size默认为可用处理器的数量，队列的size默认为50。
percolate：此线程池用于预匹配器操作。它的类型默认为fixed，size默认为可用处理器的数量，队列的size默认为1000。

3、线程池类型
a、cache

无限制的线程池，为每个请求创建一个线程。

b、fixed

有着固定大小的线程池，大小由size属性指定，允许你指定一个队列（使用queue_size属性指定）用来保存请求，直到有一个空闲的线程来执行请求。如果Elasticsearch无法把请求放到队列中（队列满了），该请求将被拒绝

4、修改线程池配置
配置文件elasticsearch.yml

threadpool.index.type: fixed
threadpool.index.size: 100
threadpool.index.queue