将logstash与elasticsearch性能匹配的几点尝试

背景

公司的测试环境4核8G内存，安装部署ELK技术栈

elastic search6.2.4 分配4G内存空间

kibana 6.2.4

logstash 6.2.4

并集成了xpack

发生性能不匹配问题

结果在对一个表（数据大约80000条）进行全表建索引的时候：（全表建索引的逻辑是logstash使用logstash-jdbc-input从mysql表中根据jdbc_page_size来更新相应大小行数）

 

logstash经常会报错：

retrying failedaction with response code:429

 

以及

Attempted tosend a bulk request to elasticsearch' but Elasticsearch appears to beunreachable or down! {:error_message=>"Elasticsearch Unreachable:[http://elastic:[email protected]:9200/][Manticore::SocketTimeout] Read timedout",:class=>"LogStash::Outputs::ElasticSearch::HttpClient::Pool::HostUnreachableError",:will_retry_in_seconds=>2}

 

elasticsearch也会报错：

failed to execute pipeline for a bulk request

org.elasticsearch.common.util.concurrent.EsRejectedExecutionException:rejected execution oforg.elasticsearch.ingest.PipelineExecutionService$2@e32de6d onEsThreadPoolExecutor[name = WPhvS8c/bulk, queue capacity = 200,org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@2abeedc3[Running,pool size = 4, active threads = 4, queued tasks = 200, completed tasks = 2524]]

 

原因就是：logstash推送的速度太快，而elastic search消费不过来。

 

前提是：第一次建全表索引的时候elastic search压力会比较大，之后大多数情况下都是增量更新。

 

先看到一个解决方案：

sysctl -wvm.max_map_count=262144

参考：

https://www.elastic.co/guide/en/elasticsearch/reference/5.0/vm-max-map-count.html

但似乎并没啥用，原因可能不在这里

思路1：加大elasticsearch的index rate

由于是刚刚接触es，原理性的东西还不清楚，参考网上的经验在尝试

参考：

如何提高ElasticSearch 索引速度

1. 调整队列长度，threadpool.index.queue_size，这个感觉治标不治本，仅仅能当queue中堆积的时候帮忙不报错，但并不能加快index rate

2. 修改bulk线程

如果4核，那就只能设置<=5，其实可更改的空间也不大

 

这两项在elasticsearch.yml中设置

thread_pool:
    bulk:
        size: 9
        queue_size: 1000

3. 设置为translog异步落地index.translog.durability=async，

增大indices.memory.index_buffer_size

增大index.translog.flush_threshold_ops

增大index.translog.sync_interval

官方参考：

https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-translog.html

这个没有进行尝试。因为全表更新可以慢，毕竟不会经常做。

 

思路2：减少logstashemitted rate

如果es处理不过来，那能不能减少logstash推送的速度呢？

 

首先将logstash-jdbc-input中的jdbc_page_size=1

这样应该是最小了

 

之后配置logstash.yml

参考：

https://www.elastic.co/guide/en/logstash/current/logstash-settings-file.html

将pipeline.workers=1

pipeline.batch.size=1

pipeline.batch.delay=5000

 

似乎这样起到了效果，每次查询语句执行的时间间隔似乎变宽了。

思路3：直接提升硬件

升级为8核16G

使用top命令查看

以及kibana监控

查看elasticsearch的JVM Heap

发现如果像之前部署elasticsearch JVM Heap为4G，可能存在不够用的情况

总结：

最后的效果是这样的

logstash中

0.67/s到0.7/s之间

ES的index rate

10.67/s

整体的效果

但这样将logstash的推送速度降到很低，会导致很慢。基本上更新1000条要20min左右。80000条不敢想

能不能快一点呢？考虑到ES index rate差不多是logstash emit rate的10倍

当将jdbc_page_size设置为10时，logstash event rate为0，这是为啥呢？原来显示的是每秒多少event？而我们执行的节奏是1.661529s

而我们进入到logstashpipeline中时，能够看到

而ES的index rate为

总之这样运行差不多3个小时，就全表更新了。

以上就是logstash与elasticsearch性能匹配过程中我的尝试，应该有很多错误的地方，请各位不吝赐教了

附kibana monitor监控页面内容介绍

整体介绍

https://www.elastic.co/guide/en/kibana/6.3/monitoring-data.html

ES

https://www.elastic.co/guide/en/kibana/6.3/elasticsearch-metrics.html

Kibana

https://www.elastic.co/guide/en/kibana/6.3/kibana-page.html

Logstash

https://www.elastic.co/guide/en/kibana/6.3/logstash-page.html

logstash pipeline

https://www.elastic.co/guide/en/logstash/6.3/logstash-pipeline-viewer.html