极限压榨Elasticsearch写入速度

服务器
ES使用非常广泛,尤其是ELKB,几乎是上点规模的日志系统,都在用它。日志属于写多读少的业务场景,对写入速度要求很高。拿我们其中一个集群来说,单集群日志量达到百TB,每秒钟日志写入量达到10W条。

本文转载自微信公众号「小姐姐味道 」,作者小姐姐养的狗。转载本文请联系小姐姐味道 公众号。   

ES使用非常广泛,尤其是ELKB,几乎是上点规模的日志系统,都在用它。

日志属于写多读少的业务场景,对写入速度要求很高。拿我们其中一个集群来说,单集群日志量达到百TB,每秒钟日志写入量达到10W条。

ES不是单纯的顺序写,为了构造倒排索引,保证数据的可靠性和实时性,背后有很多耗时的merge或者额外操作,磁盘I/O和CPU的压力非常的大!

使用iotop去观测,可以发现ES的进程几乎占满了SSD磁盘的I/O资源,达到200MB/s+。使用top命令观测,发现8核CPU的user几乎占满。ES是非常能吃资源的。

既然能很容易发现系统的瓶颈,那就着力去优化这个资源,极限压榨一下ES的写入速度。

本次优化的示例版本是7.9.2。ES的版本升的是真快,已经完全脱离了5的时代了。

 

1、哪些操作占用资源

要进行优化,需要首先知道ES的写入过程,了解哪些步骤最耗时。

首先,就是副本(replica)问题,为了保证起码的高可用,这里的副本数量设置为1,是节省不了的。所以,将副本数量设置为0,只适合数据首次导入的时候。

 

如上图,一条数据想要最终落地,是需要经过多个步骤的。这个过程,甚至会有tranlog这样的备份机制。

ES的底层存储是Lucene,包含一系列的反向索引。这样的索引就成为段(segment)。但记录不会直接写入段,而是先写入一个缓冲区。

当缓冲区满了,或者在缓冲区呆的够久,达到了刷新时间(划重点),会一次性将缓冲区的内容写进段中。

这也是为什么refresh_interval属性的配置会严重的影响性能。如果你不要很高的实时性,不妨将其配置的大一点。

缓冲区默认使用堆空间的10%,最小值为48mb(针对于分片的)。如果你的索引多且写入重,这部分内存的占用是可观的,可以适当加大。

2、开始优化

数据写入,主要有三个动作:flush、refresh和merge。通过调整它们的行为,即可在性能和数据可靠性之间进行权衡。

flush

从上面的介绍可以看出来,translog写入了一份全量的数据,它有点像MysSQL中的binlog,或者redis的aof,用来保证异常情况下的数据安全。

这是因为,我们把数据写到磁盘后,还要调用fsync才能把数据刷到磁盘中,如果不这样做在系统掉电的时候就会导致数据丢失。

ES默认每次请求都进行一次flush,但对于日志来说,这没有必要,可以将这个过程改为异步的,参数如下:

  1. curl -H "Content-Type: application/json"  -XPUT 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{ 
  2.   "index.translog.durability" : "async"
  3. "index.translog.flush_threshold_size" : "512mb"
  4.   "index.translog.sync_interval" : "60s" 
  5. }' 

这可以说是最重要的一步优化了,对性能的影响最大,但在极端情况下会有丢失部分数据的可能。对于日志系统来说,是可以忍受的。

refresh

除了写translog,ES还会将数据写入到一个缓冲区中。但是注意了!此时,缓冲区的内容是无法被搜索到的,它还需要写入到segment里面才可以。

这就是refresh动作,默认1秒。也就是你写入的数据,大概率1秒之后才会被搜索到。

所以ES并不是一个实时性的搜索系统,它是一个类实时系统(near-realtime)。

 

通过index.refresh_interval可以修改这个刷新间隔。

对于日志系统来说,当然要把它调大一点啦。xjjdog这里调整到了120s,减少了这些落到segment的频率,速度自然会快。

  1. curl -H "Content-Type: application/json"  -XPUT 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{ 
  2.   "index.refresh_interval" : "120s" 
  3. }' 

merge

merge其实是lucene的机制,它主要是合并小的segment块,生成更大的segment,来提高检索的速度。

原因就是refresh过程会生成一大堆小segment文件,数据删除也会产生空间碎片。所以merge,通俗来讲就像是碎片整理进程。像postgresql等,也有vaccum进程在干同样的事。

显而易见,这种整理操作,既让费I/O,又浪费CPU。

要命的是,merge有三种策略。

  • tiered 默认选项,它能合并大小相似的索引段,并考虑每层允许的索引段的最大个数。
  • log_byte_size 以字节数的对数为计算单位,选择多个索引来合并创建新索引。
  • log_doc 以索引段的文档数量为计算单位,选择多个索引来合并创建新索引。

每一种策略都有非常详细的针对性配置,在此不啰嗦。

由于日志系统并没有随机性的删除操作,所以我们保持默认就可以。

3、微调

新版本对线程池的配置进行了优化,不需要配置复杂的search、bulk、index线程池。有需要配置下面几个就行了:thread_pool.get.size, thread_pool.write.size, thread_pool.listener.size, thread_pool.analyze.size。具体可观测_cat/thread_pool接口暴露的数据进行调整。

其实,可以通过配置多块磁盘的方式,来分散I/O的压力,但容易会造成数据热点集中在单块磁盘上。

Lucene的索引建立过程,非常耗费CPU,可以减少倒排索引的数量来减少CPU的损耗。第一个优化就是减少字段的数量;第二个优化就是减少索引字段的数量。具体的操作,是将不需要搜索的字段,index属性设置为not_analyzed或者no。至于_source和_all,在实际调试中效果不大,不再赘述。

另外,如果日志是通过filebeat或者logstash这样的组件传导过来的,一般都是开启了批量模式。通过批量能够增加性能,但也不宜过大,可根据实际观测进行设置,一般1k-1w之间都是可以的。

End

ES有多种使用场景。鉴于它NoSQL的本质,有的甚至用它来替代传统的关系型数据库。

这是没有问题的,但要注意它的延迟。本文侧重的是吞吐量优先的日志写入场景,数据的延迟就尤为明显。ES默认不是为了这种场景设计的,所以开箱即用的配置就显得效率很低。

我们了解到ES写入有flush、refresh和merge过程。其中,对I/O影响最大的就是translog和merge的动作;对CPU影响最大的是索引创建和merge的过程。在平常的mapping设计中,要尽量减少字段的数量,以及索引字段的数量。如此双管齐下,才能把CPU和I/O两个瓶颈点给解决掉。

作者简介:小姐姐味道 (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。我的个人微信xjjdog0,欢迎添加好友,进一步交流。

 

责任编辑:武晓燕 来源: 小姐姐味道
相关推荐

2016-09-07 15:02:03

ElasticSear索引速度

2014-08-29 14:31:36

性能浪潮高性能

2015-12-08 18:46:53

UPYUN云CDN直播加速

2021-10-20 06:47:50

Elasticsear场景引擎

2020-10-15 09:19:36

Elasticsear查询速度

2023-08-29 17:52:20

人工智能

2015-06-12 09:51:56

挑战速度极限

2023-12-26 12:12:57

检索调优Scripting场景

2022-08-21 07:30:55

程序并发Golang编码

2009-12-01 11:14:00

2014-03-12 10:07:59

SQL ServerCPU报警DBA

2021-08-10 07:27:42

ASP.NETFluentd日志

2021-02-05 15:35:21

Redis数据库命令

2011-07-11 22:05:28

笔记本评测

2021-12-10 09:30:55

微软Windows 11SSD

2018-01-02 16:29:49

MySQL存储分析

2018-04-10 13:40:04

存储技术U盘

2022-07-27 16:04:52

996互联网大厂Meta

2011-07-06 11:18:47

ADSL
点赞
收藏

51CTO技术栈公众号