###推荐阅读:https://www.jianshu.com/p/e51ba6866b84
一、背景介绍
近一年内对公司的 ELK 日志系统做过性能优化,也对 SkyWalking 使用的 ES 存储进行过性能优化,在此做一些总结。本篇主要是讲 ES 在 ELK 架构中作为日志存储时的性能优化方案。
ELK 架构作为日志存储方案
二、现状分析
1. 版本及硬件配置
- JDK:JDK1.8_171-b11 (64 位)
- ES集群:由3台16核32G的虚拟机部署 ES 集群,每个节点分配 20 G 堆内存
- 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 性能调优、控制数据来源
1. JVM调优
第一步是 JVM 调优。
因为 ES 是依赖于 JVM 运行,没有合理的设置 JVM 参数,将浪费资源,甚至导致 ES 很容易 OOM 而崩溃。
1.1 监控 JVM 运行情况
(1)查看 GC 日志
问题:Young GC 和 Full GC 都很频繁,特别是 Young GC 频率高,累积耗时非常多。
(2) 使用 jstat 看下每秒的 GC 情况