ELK性能优化实战分析，linux云计算架构师

• 全文搜索的业务：业务中常用 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 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