ElasticSearch 是一个分布式的开源搜索和分析引擎,因其功能强大、简单易用而被应用到很多业务场景。在生产环境使用 ES 时,如果未进行优化则服务的稳定性可能得不到保障,目前我们使用 ES 作为账单平台的基础组件为微信支付提供服务时就遇到这种问题。本文即从当前的业务场景出发,分析 ES 稳定性未到达要求的原因并提供相应的解决思路。
当前微信支付对整体质量要求非常高,体现在可用性方面是需要达到 99.99%,同样账单平台也需要达到甚至超过该要求。但是在 ES 及系统环境未做优化的情况下,读写成功率是没有达到要求,在个人账单 ES 索引场景下,写成功率为 99.85%,读成功率为 99.95%,所以这里亟需优化。
二、内存回收慢优化
问题分析
针对读写成功率低问题,我们首先查看存储侧接入层 ESProxy 超时失败的情况,对应如下图:
可以看出接入层访问 ES 节点出现了大量超时,在排除接入层自身的问题后,基本上把问题源锁定到 ES 节点。 通过进一步确认 ES 节点负载情况(如下图),机器会出现 CPU 抖动,而抖动时上层会出现超时,这就表明读写成功率低是 CPU 抖动导致的,于是我们重心就是解决 CPU 抖动问题。
那么是什么原因导致 ES 节点的 CPU 抖动呢?首先我们先确定 CPU 抖动时系统具体在做什么,根据已有经验,很有可能是 ES 热点线程或 GC 导致的,但是在分析 CPU 抖动时 user 和 system 进程占比情况,其中 user 进程 CPU 占比基本没有变化,而 system 进程 CPU 却增长很多,由于 ES 热点线程或 GC 是 user 进程,所以排除了这里的影响。通过系统相关统计以及 perf 得到下面现象:
抖动时系统在大量扫描可回收内存
系统在不断进行内存回收
系统分配内存时出现了失败
通过这三个现象,我们也得出了一个结论,CPU 抖动是因为内存不足导致。
优化方案
明确了抖动问题原因后,那么我们接下来的优化方向就是保证有足够的空闲内存,避免内存不断回收而出现 CPU 抖动。针对内存不足问题,我们首先确认系统当前的内存分布情况,具体数据如下:
在系统运行一段时间后,现网的成功率逐渐降低,由 99.99%降低到 99.97%,对应接入层的超时失败也相应增多,有了之前的经验,我们相应查看了 ES 节点的负载情况,发现仍然有 CPU 抖动的现象(如下图)。考虑到之前已经优化了内存回收慢的问题,此时应是新的问题导致的 CPU 抖动,于是接下来优化点依旧是解决抖动。
和之前分析 CPU 抖动问题一样,我们先确认 CPU 抖动系统在做什么。通过 perf 分析,如下图所示:
采样的结果可以明确 CPU 抖动时,系统在进行内存碎片整合(即有 compact_zone()等函数调用),这就意味着此时系统高阶内存是不足,为了进一步验证当前的高阶内存不足,通过 cat/proc/buddyinfo 查看当前系统空闲内存的分布情况,如下图所示: