ELK性能优化实战分析，从底层开始带你了解并发编程

最新推荐文章于 2024-07-08 10:43:43 发布

m0_60635176

最新推荐文章于 2024-07-08 10:43:43 发布

阅读量838

点赞数 23

分类专栏： Java程序员面试文章标签： elk 性能优化 jvm

本文链接：https://blog.csdn.net/m0_60635176/article/details/136695482

版权

本文深入探讨了ELK（Elasticsearch, Logstash, Kibana）性能优化，从JVM、ES索引设置、线程池配置及内存锁定等方面进行调优。优化后，新生代和老年代的GC频率显著降低，系统性能得到大幅提升。通过调整索引设置、优化fsync和refresh频率、限制merge并发线程数以及设置线程池参数，有效地减少了数据写入延迟和系统停顿。此外，禁用或限制Swap使用以避免性能下降。" 136916064,11296603,微信小程序实现可滑动底部导航栏,"['微信小程序', '小程序开发', '混合式开发', 'Android', '移动开发']

摘要由CSDN通过智能技术生成

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 频率非常频繁。

优化后