ELK性能优化实战总结：我强任我强，成为阿里P7移动架构师到底有多难

• ELK版本：6.3.0
• 垃圾回收器：ES 默认指定的老年代（CMS）+ 新生代（ParNew）
• 操作系统：CentOS Linux release 7.4.1708(Core)

2. 性能问题

随着接入 ELK 的应用越来越多，每日新增索引约 230 个，新增 document 约 3000 万到 5000 万。

每日上午和下午是日志上传高峰期，在 Kibana 上查看日志，发现问题：

(1) 日志会有 5-40 分钟的延迟

(2) 有很多日志丢失，无法查到

3. 问题分析

3.1 日志延迟

首先了解清楚：数据什么时候可以被查到？

数据先是存放在 ES 的内存 buffer，然后执行 refresh 操作写入到操作系统的内存缓存 os cache，此后数据就可以被搜索到。

所以，日志延迟可能是我们的数据积压在 buffer 中没有进入 os cache 。

3.2 日志丢失

查看日志发现很多 write 拒绝执行的情况

从日志中可以看出 ES 的 write 线程池已经满负荷，执行任务的线程已经达到最大 16 个线程，而 200 容量的队列也已经放不下新的 task。

查看线程池的情况也可以看出 write 线程池有很多写入的任务

GET /_cat/thread_pool?v&h=host,name,type,size,active,largest,rejected,completed,queue,queue_size

所以我们需要优化 ES 的 write 的性能。

4.解决思路

4.1 分析场景

ES 的优化分为很多方面，我们要根据使用场景考虑对 ES 的要求。

根据个人实践经验，列举三种不同场景下的特点：

• SkyWalking：一般配套使用 ES 作为数据存储，存储链路追踪数据、指标数据等信息。
• ELK：一般用来存储系统日志，并进行分析，搜索，定位应用的问题。
• 全文搜索的业务：业务中常用 ES 作为全文搜索引擎，例如在外卖应用中，ES 用来存储商家、美食的业务数据，用户在客户端可以根据关键字、地理位置等查询条件搜索商家、美食信息。

这三类场景的特点如下：

关于实时性

• SkyWalking 在实际使用中，一般使用频率不太高，往往是发现应用的问题后，再去 SkyWalking 查历史链路追踪数据或指标数据，所以可以接受几分钟的延迟。
• ELK 不管是开发、测试等阶段，时常用来定位应用的问题，如果不能快速查询出数据，延迟太久，会耽误很多时间，大大降低工作效率；如果是查日志定位生产问题，那更是刻不容缓。
• 全文搜索的业务中一般可以接受在1分钟内查看到最新数据，比如新商品上架一分钟后才看到，但尽量实时，在几秒内可以可看到。

4.2 优化的方向

可以从三方面进行优化：JVM 性能调优、ES 性能调优、控制数据来源

三、ES性能优化

可以从三方面进行优化：JVM 性能调优、ES 性能调