ELK性能优化实战总结：我强任我强，你“跪”标准好好学

一、背景介绍

近一年内对公司的 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 情况

 

参数说明

• S0：幸存1区当前使用比例
• S1：幸存2区当前使用比例
• E：伊甸园区使用比例
• O：老年代使用比例
• M：元数据区使用比例
• CCS：压缩使用比例
• YGC：年轻代垃圾回收次数
• FGC：老年代垃圾回收次数
• FGCT：老年代垃圾回收消耗时间
• GCT：垃圾回收消耗总时间问题：从 jstat gc 中也可以看出，每秒的 eden 增长速度非常快，很快就满了。

1.2 定位 Young GC 频繁的原因

1.2.1 检查是否新生代的空间是否太小

用下面几种方式都可查看新、老年代内存大小 (1) 使用 jstat -gc