26、Elasticsearch性能优化与配置指南

Elasticsearch性能优化与配置指南

1. 字段数据缓存与断路器

在Elasticsearch中，除了使用字段数据缓存，还可以配置字段使用文档值（doc values）。字段数据缓存的内存使用量可以通过 indices.fielddata.cache.size 属性来控制，可设置为绝对值（如2GB）或Elasticsearch实例可用内存的百分比（如40%）。需注意，这些值是每个节点的属性，而非每个索引的属性。若丢弃部分缓存以腾出空间，会导致查询性能下降，因此建议提供足够的物理内存。默认情况下，字段数据缓存大小无限制，若不谨慎设置，可能导致集群崩溃。

字段数据缓存的过期时间也可控制，默认情况下缓存不会过期。可通过 indices.fielddata.cache.expire 属性设置最大不活动时间，例如设置为 10m ，则缓存将在10分钟不活动后失效。但重建字段数据缓存成本较高，一般不建议设置过期时间。

字段数据断路器可预估字段加载到内存所需的内存量，通过抛出异常避免加载过多数据到内存。Elasticsearch有两个属性控制断路器行为：
- indices.fielddata.breaker.limit ：默认值为80%，可通过集群更新设置API动态更新。当查询导致加载的字段值估计占用Elasticsearch进程可用堆内存的80%或更多时，将抛出异常。
- indices.fielddata.breaker.overhead ：默认值为1.03，用于乘以字段的原始估计内存量。

2. 存储模块

Elasticsearch的存储模块负责控制索引数据的写入方式，索引可完全存储在内存或持久磁盘存储中。纯基于内存的索引速度极快但易失，基于磁盘的索引速度较慢但具有容错性。

可通过 index.store.type 属性指定索引的存储类型，可用选项如下：
| 存储类型 | 描述 | 适用场景 |
| ---- | ---- | ---- |
| simplefs | 基于磁盘的存储，使用随机访问文件访问索引文件，并发访问性能不佳，不建议在生产环境使用。 | 无高并发需求的测试环境 |
| niofs | 基于磁盘的索引存储，使用Java NIO类访问索引文件，在高并发环境下性能良好，但由于Java实现的bug，不建议在Windows系统上使用。 | UNIX系统的高并发场景 |
| mmapfs | 基于磁盘的存储，将索引文件映射到内存，是64位系统的默认存储方式，由于使用操作系统缓存访问索引文件，读取效率更高。需确保有足够的虚拟地址空间，但在64位系统上通常不会有问题。 | 64位系统的通用场景 |
| memory | 将索引存储在内存中，需要足够的物理内存来存储所有文档，否则Elasticsearch将失败。 | 对索引访问性能要求极高且内存充足的场景 |

3. 索引缓冲区和刷新速率

Elasticsearch允许设置用于索引操作的内存量。 indices.memory.index_buffer_size 属性（默认值为10%）可控制给定节点上所有索引分片之间可分配的总内存量（或最大堆内存的百分比）。例如，将此属性设置为20%，Elasticsearch将为索引缓冲区分配最大堆大小的20%。

此外， indices.memory.min_shard_index_buffer_size 属性默认值为4mb，可设置每个分片的最小索引缓冲区大小。

索引刷新速率由 index.refresh_interval 属性控制，每个索引可单独设置，默认值为1秒。该属性指定索引搜索器对象的刷新频率，即数据视图的刷新频率。刷新速率越低，文档在搜索操作中可见的速度越快，但Elasticsearch需要投入更多资源刷新索引视图，导致索引和搜索操作变慢。对于大规模批量索引，如重新索引数据时，建议在索引期间将 index.refresh_interval 属性设置为 -1。

4. 线程池配置

Elasticsearch使用多个线程池来控制线程处理方式和用户请求的内存消耗。主要的线程池类型如下：
- cache ：无界线程池，为每个传入请求创建一个线程。
- fixed ：固定大小的线程池，通过 size 属性指定线程池大小，通过 queue_size 属性指定队列大小。若队列已满，新请求将被拒绝。

性能方面最重要的线程池如下：
| 线程池 | 用途 | 默认类型 | 默认大小 | 默认队列大小 |
| ---- | ---- | ---- | ---- | ---- |
| index | 用于索引和删除操作 | fixed | 可用处理器数量 | 300 |
| search | 用于搜索和计数请求 | fixed | 可用处理器数量 * 3 | 1000 |
| suggest | 用于建议请求 | fixed | 可用处理器数量 | 1000 |
| get | 用于实时GET请求 | fixed | 可用处理器数量 | 1000 |
| bulk | 用于批量操作 | fixed | 可用处理器数量 | 50 |
| percolate | 用于 percolation 请求 | fixed | 可用处理器数量 | 1000 |

例如，若要将索引操作的线程池配置为固定类型，大小为100，队列大小为500，可在 elasticsearch.yml 配置文件中设置：

threadpool.index.type: fixed
threadpool.index.size: 100
threadpool.index.queue_size: 500

也可使用集群更新API更新线程池配置：

curl -XPUT 'localhost:9200/_cluster/settings' -d '{
  "transient" : {
    "threadpool.index.type" : "fixed",
    "threadpool.index.size" : 100,
    "threadpool.index.queue_size" : 500
  }
}'

5. 综合配置建议

在配置Elasticsearch集群以实现高索引和查询吞吐量时，需注意以下几点：
- 内存分配 ：一般不应将超过50% - 60%的可用物理内存分配给运行Elasticsearch的JVM进程，以便为操作系统和操作系统I/O缓存留出空间。但这并非绝对，需根据实际情况调整。同时，建议将 Xmx 和 Xms 参数设置为相同值，以避免JVM堆大小调整。
- 性能测试 ：进行系统调优时，应进行可重复的性能测试，以便观察配置更改对整体性能的影响。有时在单台机器上进行简单的性能测试，可作为进一步调优的起点。
- 选择合适的存储类型 ：64位操作系统建议使用 mmapfs ；非64位操作系统，UNIX系统选择 niofs ，Windows系统选择 simplefs ；若能接受易失性存储且追求高速，可考虑 memory 存储，但需确保有足够的内存。
- 调整索引刷新速率 ：较慢的刷新速率（如10s或30s）可减轻Elasticsearch的压力，使更多资源可用于索引和查询操作。
- 调优线程池 ：建议对默认线程池进行调优，尤其是查询操作的线程池。性能测试后，当集群处理查询过载时，可考虑直接拒绝请求，而非将其放入队列等待处理。
- 优化合并过程 ：查询包含多个段的索引比段数较少的索引慢，但减少段数需要更频繁地合并。若希望查询更快，应减少索引的段数；若希望索引更快，可增加段数。需找到两者之间的平衡点，使用并发合并调度器并调整默认节流值，避免I/O子系统因合并操作过载。
- 控制字段数据缓存 ：默认情况下，Elasticsearch的字段数据缓存无限制，可能导致内存不足。可通过限制缓存大小和配置断路器来避免内存问题。
- 增加索引缓冲区 ：若需要高索引速率，可增加 indices.memory.index_buffer_size 属性的百分比，例如设置为30%。
- 调整事务日志 ：Elasticsearch的事务日志模块（translog）用于预写日志，默认情况下，事务日志最多保留5000个操作，最大大小为200mb。若能接受数据在更长时间内不可用于搜索操作，但希望提高索引吞吐量，可通过 index.translog.flush_threshold_ops 和 index.translog.flush_threshold_size 属性增加默认值。但需注意，事务日志较大时，分片初始化可能会变慢。

6. 模板和动态模板

Elasticsearch的索引模板功能可定义一次或多次映射，并在每个新创建的索引中使用，无需每次创建索引时都发送映射信息。每个模板定义一个模式，与新创建的索引名称进行比较，匹配时将模板中的值复制到索引结构定义中。若多个模板匹配新索引名称，所有模板将按顺序应用，后应用的模板中的值将覆盖先前模板中定义的值。此外，还有一个顺序参数可强制指定模板的应用顺序。

例如，若要创建多个不存储文档源且无需副本的索引，可使用以下命令创建模板：

curl -XPUT http://localhost:9200/_template/main_template?pretty -d '{
  "index_patterns": ["*"],
  "settings": {
    "index": {
      "store": {
        "type": "mmapfs"
      },
      "number_of_shards": 1,
      "number_of_replicas": 0
    }
  },
  "mappings": {
    "_source": {
      "enabled": false
    }
  }
}'

通过合理配置和调优上述各项参数，可提高Elasticsearch集群的性能和稳定性，满足不同场景下的索引和查询需求。

Elasticsearch性能优化与配置指南（续）

7. 性能优化的综合考量

在对Elasticsearch进行性能优化时，不能仅仅关注某一个方面，而需要综合考虑各个因素之间的相互影响。以下是一些综合考量的要点：
- 资源平衡 ：内存、CPU、磁盘I/O等资源之间需要达到平衡。例如，增加索引缓冲区可能会提高索引速度，但如果磁盘I/O性能不足，可能会导致数据写入延迟。因此，在调整一个参数时，需要考虑其他资源的使用情况。
- 业务需求匹配 ：不同的业务场景对Elasticsearch的性能要求不同。例如，实时搜索业务对索引刷新速率要求较高，而批量数据处理业务则更注重索引吞吐量。因此，需要根据实际业务需求来调整各项参数。
- 长期规划 ：随着业务的发展，数据量和查询量会不断增加。在进行性能优化时，需要考虑到未来的扩展性，避免频繁进行大规模的配置调整。

8. 监控与反馈机制

为了确保Elasticsearch集群始终保持良好的性能，需要建立有效的监控与反馈机制。具体步骤如下：
1. 选择监控工具 ：可以使用Elasticsearch自带的监控工具，如Elasticsearch Monitoring，也可以使用第三方监控工具，如Prometheus和Grafana。
2. 设置监控指标 ：监控指标应包括内存使用情况、CPU使用率、磁盘I/O速率、查询响应时间等。通过对这些指标的监控，可以及时发现性能瓶颈。
3. 建立反馈机制 ：当监控指标超过预设的阈值时，应及时发出警报，并根据警报信息进行相应的调整。例如，如果发现内存使用率过高，可以考虑减少字段数据缓存的大小。

9. 常见问题及解决方案

在使用Elasticsearch过程中，可能会遇到一些常见问题，以下是一些问题及对应的解决方案：
| 问题 | 描述 | 解决方案 |
| ---- | ---- | ---- |
| 内存不足 | 集群频繁出现内存溢出错误，导致节点崩溃。 | 调整字段数据缓存大小，优化查询语句，增加物理内存。 |
| 查询响应时间过长 | 查询请求的响应时间超过预期，影响用户体验。 | 优化索引结构，调整线程池配置，减少索引刷新速率。 |
| 索引吞吐量低 | 数据写入速度慢，无法满足业务需求。 | 增加索引缓冲区，调整合并策略，优化磁盘I/O性能。 |

10. 性能优化的工作流

graph LR
    A[明确业务需求] --> B[初始配置]
    B --> C[性能测试]
    C --> D{是否满足需求}
    D -- 是 --> E[持续监控]
    D -- 否 --> F[分析性能瓶颈]
    F --> G[调整配置参数]
    G --> C
    E --> H{是否出现新问题}
    H -- 是 --> F
    H -- 否 --> E

性能优化是一个持续的过程，需要按照以下工作流进行：
1. 明确业务需求 ：了解业务对Elasticsearch的性能要求，如索引吞吐量、查询响应时间等。
2. 初始配置 ：根据业务需求和硬件资源，进行初始的配置设置，如选择合适的存储类型、调整索引刷新速率等。
3. 性能测试 ：使用性能测试工具对Elasticsearch集群进行测试，收集各项性能指标。
4. 分析性能瓶颈 ：根据性能测试结果，分析性能瓶颈所在，确定需要调整的参数。
5. 调整配置参数 ：根据分析结果，对配置参数进行调整，如增加索引缓冲区、调优线程池等。
6. 持续监控 ：建立监控机制，持续监控Elasticsearch集群的性能指标，及时发现并解决新出现的问题。

11. 总结

Elasticsearch的性能优化是一个复杂的过程，需要综合考虑多个因素。通过合理配置字段数据缓存、存储模块、索引缓冲区、线程池等参数，选择合适的存储类型和索引刷新速率，以及建立有效的监控与反馈机制，可以提高Elasticsearch集群的性能和稳定性，满足不同业务场景的需求。同时，需要不断进行性能测试和调整，以适应业务的发展和变化。希望本文提供的指南和建议能够帮助你更好地优化Elasticsearch集群，提升其在实际应用中的表现。