Elasticsearch入库优化记录

由于最近要实现Elasticsearch日入8T(最大支持10T）的数据，所以最近对es入库部分的效率，进行了重点验证。

现在的入库程序使用（有专门的程序将原始数据转换成）json文件，批量bulk的方式，实现大量的数据入库。

根据公司这段时间和部分现场的使用情况来看，每台机器每小时大概只能入库20G（现场万兆网：30G），索引创建的速度约：40K-50K/s。

使用Prometheus监控了测试环境的es集群（1台master节点、4台data节点（双实例）的状态、磁盘读写速度，发现入库速度远远未能达到瓶颈。(公司千兆网）。

因此分析ES的相关配置及入库程序源代码，着手进行优化：

1）根据Prometheus监控结果优化

（1）查看jvm gc情况并优化

（2）优化配置

根据监控平台的merge情况，调整磁盘刷新间隔（合理的GC、同时避免数据量过大时JVM OOM）

2）检查es配置，确保thread_pool.bulk.size和cpu核心数一致；确保thread_pool.bulk.queue_size不小于2000

3）入库客户端优化

现有入库客户端，使用线程池进行bulk批量提交的方式实现es数据入库；入库效率理论上是可以的。

但阅读代码发现入库时，实际使用的esclient为公用一个，造成线程较大时，排队等这单个esclient，线程增加对入库速度基本没有影响。

优化：

（1）增加esclient队列（连接池），创建和入库线程池中线程数量一致数量的esclient，使用poll（take）、put的方式维护该队列，使esclient的可用性和和现在的入库线程池保持一致。

速度加快了很多（5线程时，索引创建的速度：80K-90K/s；10线程时：150K/s；20线程：180K-200K/s）

（2）使用bulkAsync异步提交的方式。

尝试使用bulkAsync，2线程基本能达到200K/s，5线程能达到210K/s，但一会就出现超时了；超时时处理逻辑复杂很多（要处理很多复杂的业务逻辑），为了代码易读性和易维护性，且由于客户端不需要太高的并发量，最重要的是少写代码，少出bug，生产环境暂不使用该模式，哈。

现在测试环境下，单台机器每天可入1.9T左右的原始数据，OK！

其他优化：

入库客户端

jvm参数，调整新生代大小，减少yong gc；减少50%以上。

后进一步使用jvm外内存，由于改动较大，速度以满足需要，未进一步研究。

 

-------

2019-12-10

后有时间再次分析了一下入库程序，分析了现在的模板，查看段创建情况，在模版中增加了translog刷新时间和大小阀值，将入库速度进一步提高，在千兆网环境下，1个协调节点，4个数据节点，入库速度已到400K/s。

2020-01-13

为了进一步提升性能，达到单台服务器入库5T以上的目标（达到公司测试环境下的网络瓶颈）。

分析发现数据速度无法进一步提升的主要原因是：协调节点的GC非常厉害，影响了数据处理效率。

解决办法：

（1）想办法降低协调节点的GC（正在调研中）

（2）增加协调节点，将协调节点增加到5/8/9进行验证。

最终验证：在使用9个协调节点时，输入插入速度50万条/秒，达到了局域网（千兆网）的网络瓶颈；单台服务器24小时入库达到5.9TB。