- 全文搜索的业务:业务中常用 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,出乎意料。