elasticsearch索引速度优化

作者: JerryHouse 分类: elasticsearch 发布时间: 2017-03-21 16:39 ė 6elasticsearch索引速度优化已关闭评论

前一篇文章讲了elasticsearch排序插件,本文为elasticsearch官方的索引新能优化指南的翻译。
如果搜索的索引任务比较繁重(例如索引基础结构日志),我们可能会愿意牺牲一些elasticsearch的搜索性能以实现更快的索引速度。在这些情况下,搜索的量比较小,并且等待几秒钟才出搜索结果也是可以忍耐的,而不需要以毫秒级别返回搜索结果,可以做出一些权衡,牺牲查询性能以提高搜索引擎的索引性能。

1.科学的测试索引性能
性能测试总是很困难,因此尽可能科学的测试索引性能很重要。如果涉及的因素太多,就不可能确定哪一个导致了更好的效果。合理的测试方法如下:
a.在单个节点上测试性能,索引只有单个分片且无副本。
b.在默认设置下测试性能,这个可以作为性能测试的基准。
c.确保性能测试运行很长时间(30+分钟),以便可以评估长期性能,而不是短期峰值或延迟。某些事件(例如段合并和GC)不会立即发生,因此性能可能会随时间而变化。
d.开始对基准默认值进行单一更改,然后进行严格的测试,如果性能改进是可以接受的,保持设置,并继续下一个测试。

2.使用elasticsearch批量索引接口
使用elasticsearch批量索引请求能够达到最佳性能。批量大小取决于单条数据的大小,分析和elasticsearch搜索群集的配置,一个好的起点是每个批量索引的数据大小为5-15 MB。批量文档数目不是批量大小的良好指标。例如,如果您每个批量索引1,000个文档:

每个文档1 KB,1,000个文档为1 MB。
每个文档100 KB,1,000个文档是100 MB。
可以看到使用文档数目是稳定的,因此批量的数据大小比文档数目更好。一开始的时候批量大小约5-15 MB,慢慢增加,直到性能不再提升,然后开始提高批量索性的并发性。

使用Marvel和/或工具(如iostat,top和ps)监视节点,以查看什么资源在什么时候开始成为瓶颈。如果开始接收EsRejectedExecutionException异常,就意味着至少有一个资源已达到容量极限。应该减少并发性,提供更多的物理资源(例如从机械硬盘切换到SSD硬盘)或添加更多节点。

3.硬件存储

磁盘通常是任何现代服务器的瓶颈。 Elasticsearch大量使用磁盘,磁盘可以处理的吞吐量越多,节点就越稳定。以下是优化磁盘I / O的一些提示:

  • 使用SSD。如其他地方所提到的,它们优于纺织介质。
  • 不要使用远程安装的存储,如NFS或SMB / CIFS。

4.减少段的合并
段合并在计算上成本相当昂贵,并且可以吃掉很多磁盘I / O。合并计划应该在后台运行,因为它们可能需要很长时间才能完成,特别是大的段,但好在于大段合并的相对较少。

但有时合并会降低索引性能,如果发生这种情况,Elasticsearch将自动使用单个线程对索引请求进行处理,这可以有效的防止在段合并完成之前产生数百个新的段。 Elasticsearch通过每秒最大索引数据的大小来控制什么时候将索引切换到单线程执行,默认值为20 MB / s,如果不希望搜索性能受到后台合并的影响,可以适当的提高这个默认值。如果使用的是SSD,可以考虑将其增加到100-200 MB / s,然后测试看看是否能够提高性能:

PUT /_cluster/settings
{
    "persistent" : {
        "indices.store.throttle.max_bytes_per_sec" : "100mb"
    }
}

如果正在进行批量导入,根本不关心搜索的性能,则可以完全禁用段合并。这将允许elasticsearch的索引速度运行与磁盘的写入速度一样快:

PUT /_cluster/settings
{
    "transient" : {
        "indices.store.throttle.type" : "none" 
    }
}

将段合并完全禁用后,需要注意在完成数据导入后,应当重新启用段合并以提高搜索性能。

如果elasticsearch集群使用的是机械硬盘,而不是SSD硬盘,由于机械硬盘的并发I / O的性能不高,因此需要减少elasticsearch并发访问磁盘的线程数。下面的设置将允许elasticsearch以max_thread_count + 2个线程磁盘上进行并发操作,如果将max_thread_count设置为1则表示允许同时三个线程对磁盘进行操作。

则在的elasticsearch.yml进行如下配置:

index.merge.scheduler.max_thread_count: 1

最后,可以将index.translog.flush_threshold_size从默认的512 MB增加到更大的值,例如1 GB。这允许更大的段在commit发生之前累积在translog日志中。通过创建较大的段,可以减少刷新频率较少,并且大段合并的次数会减少。以上这些配置都降低了elasticsearch磁盘I / O开销和提高了索引的速度。在调整这些设置时还需要记住增加相应数量的elasticsearch的堆内存来增大文件缓冲。

5.写在最后

如果索引的变化不需要实时的反映到搜索结果中,可以考虑将每个elasticsearch索引的index.refresh_interval减少到30秒。如果要执行大量数据的导入,则可以在导入期间将此值设置为-1来禁用刷新。当然在数据导入完成后,不要忘记重新启用刷新。同时还可以考虑通过设置index.number_of_replicas禁用副本。

本文出自 dcharm,转载时请注明出处及相应链接。

本文永久链接: http://www.dcharm.com/?p=655

Ɣ回顶部