编程语言
首页 > 编程语言> > ELK性能优化实战总结:我强任我强,程序员真的是吃青春饭吗

ELK性能优化实战总结:我强任我强,程序员真的是吃青春饭吗

作者:互联网

ELK 架构作为日志存储方案

二、现状分析

1. 版本及硬件配置

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 的要求。

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

这三类场景的特点如下:

关于实时性

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 情况

参数说明

1.2 定位 Young GC 频繁的原因

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

用下面几种方式都可查看新、老年代内存大小 (1) 使用 jstat -gc pid  查看 Eden 区、老年代空间大小 (2) 使用 jmap -heap pid  查看 Eden 区、老年代空间大小 (3) 查看 GC 日志中的 GC 明细

其中 996800K 为新生代可用空间大小,即 Eden 区 +1 个 Survivor 区的空间大小,所以新生代总内存是996800K/0.9, 约1081M

上面的几种方式都查询出,新生代总内存约1081M,即1G左右;老年代总内存为19864000K,约19G。新、老比例约1:19,出乎意料。

1.2.1 新老年代空间比例为什么不是 JDK 默认的1:2【重点!】

**这真是一个容易踩坑的地方。**如果没有显示设置新生代大小,JVM 在使用 CMS 收集器时会自动调参,新生代的大小在没有设置的情况下是通过计算得出的,其大小可能与 NewRatio 的默认配置没什么关系而与 ParallelGCThreads 的配置有一定的关系。

参考文末链接:CMS GC 默认新生代是多大?

所以:新生代大小有不确定性,最好配置 JVM 参数 -XX:NewSize、-XX:MaxNewSize 或者 -xmn ,免得遇到一些奇怪的 GC,让人措手不及。

1.3 上面现象造成的影响

新生代过小,老年代过大的影响

1.4 JVM优化

1.4.1 配置堆内存空间大小

32G 的内存,分配 20G 给堆内存是不妥当的,所以调整为总内存的50%,即16G。修改 elasticsearch 的 jvm.options 文件

-Xms16g
-Xmx16g

设置要求:

1.4.2 配置堆内存新生代空间大小

因为指定新生代空间大小,导致 JVM 自动调参只分配了 1G 内存给新生代。

修改 elasticsearch 的 jvm.options 文件,加上

-XX:NewSize=8G
-XX:MaxNewSize=8G

老年代则自动分配 16G-8G=8G 内存,新生代老年代的比例为 1:1。修改后每次 Young GC 频率更低,且每次 GC 后只有少数数据会进入老年代。

2.3 使用G1垃圾回收器(未实践)

G1垃圾回收器让系统使用者来设定垃圾回收堆系统的影响,然后把内存拆分为大量的小 Region,追踪每个 Region 中可以回收的对象大小和回收完成的预计花费的时间, 最后在垃圾回收的时候,尽量把垃圾回收对系统造成的影响控制在我们指定的时间范围内,同时在有限的时间内尽量回收更多的垃圾对象。G1垃圾回收器一般在大数量、大内存的情况下有更好的性能。

ES默认使用的垃圾回收器是:老年代(CMS)+ 新生代(ParNew)。如果是JDK1.9,ES 默认使用 G1 垃圾回收器。

因为使用的是 JDK1.8,所以并未切换垃圾回收器。后续如果再有性能问题再切换G1垃圾回收器,测试是否有更好的性能。

1.5 优化的效果

1.5.1 新生代使用内存的增长率更低

优化前

每秒打印一次 GC 数据。可以看出,年轻代增长速度很快,几秒钟年轻代就满了,导致 Young GC 触发很频繁,几秒钟就会触发一次。而每次 Young GC 很大可能有存活对象进入老年代,而且,存活对象多的时候(看上图中第一个红框中的old gc数据),有(51.44-51.08)/100 * 19000M = 约68M。每次进入老年代的对象较多,加上频繁的 Young GC,会导致新老年代的分代模式失去了作用,相当于老年代取代了新生代来存放近期内生成的对象。当老年代满了,触发 Full GC,存活的对象也会很多,因为这些对象很可能还是近期加入的,还存活着,所以一次 Full GC 回收对象不多。而这会恶性循环,老年代很快又满了,又 Full GC,又残留一大部分存活的,又很容易满了,所以导致一直频繁 Full GC。

优化后

每秒打印一次 GC 数据。可以看出,新生代增长速度慢了许多,至少要 60 秒才会满,如上图红框中数据,进入老年代的对象约(15.68-15.60)/100 * 10000 = 8M,非常的少。所以要很久才会触发一次 Full GC 。而且等到 Full GC 时,老年代里很多对象都是存活了很久的,一般都是不会被引用,所以很大一部分会被回收掉,留一个比较干净的老年代空间,可以继续放很多对象。

1.5.2 新生代和老年代 GC 频率更低

ES 启动后,运行14个小时

优化前

Young GC 每次的时间是不长的,从上面监控数据中可以看出每次GC时长 1467.995/27276 约等于 0.05 秒。那一秒钟有多少时间是在处理 Young GC ?

计算公式:1467 秒/( 60 秒× 60 分 14 小时)= 约 0.028 秒,也就是 100 秒中就有 2.8 秒在Young GC,也就是有 2.8S 的停顿,这对性能还是有很大消耗的。同时也可以算出多久一次 Young GC, 方程是:60秒×60分*14小时/ 27276次 = 1次/X秒,计算得出X = 0.54,也就是 0.54 秒就会有一次 Young GC,可见 Young GC 频率非常频繁。

优化后

Young GC 次数只有修改前的十分之一,Young GC 时间也是约八分之一。Full GC 的次数也是只有原来的八分之一,GC 时间大约是四分之一。

GC 对系统的影响大大降低,性能已经得到很大的提升。

2.ES 调优

上面已经分析过 ES 作为日志存储时的特性是:高并发写、读少、接受 30 秒内的延时、可容忍部分日志数据丢失。下面我们针对这些特性对ES进行调优。

2.1 优化 ES 索引设置

2.2.1 ES 写数据底层原理

refresh ES 接收数据请求时先存入 ES 的内存中,默认每隔一秒会从内存 buffer 中将数据写入操作系统缓存 os cache,这个过程叫做 refresh;

到了 os cache 数据就能被搜索到(所以我们才说 ES 是近实时的,因为 1 s 的延迟后执行 refresh 便可让数据被搜索到)

fsync translog 会每隔 5 秒或者在一个变更请求完成之后执行一次 fsync 操作,将 translog 从缓存刷入磁盘,这个操作比较耗时,如果对数据一致性要求不是很高时建议将索引改为异步,如果节点宕机时会有5秒数据丢失;

flush ES 默认每隔30分钟会将 os cache 中的数据刷入磁盘同时清空 translog 日志文件,这个过程叫做 flush。

merge

ES 的一个 index 由多个 shard 组成,而一个 shard 其实就是一个 Lucene 的 index ,它又由多个 segment 组成,且 Lucene 会不断地把一些小的 segment 合并成一个大的 segment ,这个过程被称为段merge(参考文末链接)。执行索引操作时,ES 会先生成小的segment,ES 有离线的逻辑对小的 segment 进行合并,优化查询性能。但是合并过程中会消耗较多磁盘 IO,会影响查询性能。

2.2.2 优化方向
2.2.2.1 优化 fsync

为了保证不丢失数据,就要保护 translog 文件的安全:

Elasticsearch 2.0 之后, 每次写请求(如 index 、delete、update、bulk 等)完成时, 都会触发fsync将 translog 中的 segment 刷到磁盘, 然后才会返回200 OK的响应;

或者: 默认每隔5s就将 translog 中的数据通过fsync强制刷新到磁盘.

该方式提高数据安全性的同时, 降低了一点性能.

==> 频繁地执行 fsync 操作, 可能会产生阻塞导致部分操作耗时较久. 如果允许部分数据丢失, 可设置异步刷新 translog 来提高效率,还有降低 flush 的阀值,优化如下:

"index.translog.durability": "async",
"index.translog.flush_threshold_size":"1024mb",
"index.translog.sync_interval": "120s"
2.2.2.2 优化 refresh

写入 Lucene 的数据,并不是实时可搜索的,ES 必须通过 refresh 的过程把内存中的数据转换成 Lucene 的完整 segment 后,才可以被搜索。

默认 1秒后,写入的数据可以很快被查询到,但势必会产生大量的 segment,检索性能会受到影响。所以,加大时长可以降低系统开销。对于日志搜索来说,实时性要求不是那么高,设置为 5 秒或者 10s;对于 SkyWalking,实时性要求更低一些,我们可以设置为 30s。

设置如下:

"index.refresh_interval":"5s"
2.2.2.3 优化 merge

index.merge.scheduler.max_thread_count 控制并发的 merge 线程数,如果存储是并发性能较好的 SSD,可以用系统默认的 max(1, min(4, availableProcessors / 2)),当节点配置的 cpu 核数较高时,merge 占用的资源可能会偏高,影响集群的性能,普通磁盘的话设为1,发生磁盘 IO 堵塞。设置max_thread_count 后,会有 max_thread_count + 2 个线程同时进行磁盘操作,也就是设置为 1 允许3个线程。

设置如下:

总结

这个月马上就又要过去了,还在找工作的小伙伴要做好准备了,小编整理了大厂java程序员面试涉及到的绝大部分面试题及答案,希望能帮助到大家

CodeChina开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频】

在这里插入图片描述

在这里插入图片描述

总结

这个月马上就又要过去了,还在找工作的小伙伴要做好准备了,小编整理了大厂java程序员面试涉及到的绝大部分面试题及答案,希望能帮助到大家

CodeChina开源项目:【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频】

[外链图片转存中…(img-KgsdJVgH-1630891523197)]

[外链图片转存中…(img-j1oLCK7p-1630891523198)]

标签:ELK,Young,新生代,程序员,GC,内存,强任,日志,ES
来源: https://blog.csdn.net/m0_60607783/article/details/120126880