记一次Elasticsearch问题排查

发布时间:2022-09-11 00:00

我们团队基于Elasticsearch开发了一款将数据从数据库实时同步至Elasticsearch的工具——搜索平台,其实现方式主要是通过flink将数据库中已有的存量数据导入Elasticsearch,并订阅数据表的binlog,将实时改动也同步至Elasticsearch。

问题发现

AIoT团队在搜索平台上维护了一个较大的索引,其写入平均有2k到3k的tps,查询也有数百QPS。由于该索引较重要且占用资源较多,因此使用Elasticsearch的template功能将之单独部署在专用的机器上。

从5月底开始,写入此索引的flink实时任务就会偶现失败重启的情况,经排查,发现是写入Elasticsearch的请求超时导致的,结合当时机器的cpu占用等指标判定是写入tps过高导致Elasticsearch无法承受,因此,将该索引所占的机器从2台升级到3台,并使用业务数据进行了一轮写入压测,发现能支撑业务方的写入速率,扩完后较长一段时间内,该索引也一直没有出现问题,因此认为问题已经被解决了。

问题排查

然而,在6月22日凌晨,上述问题再次出现,通过查看指标,发现当时的写入速率并无显著提升。

1.索引写入速率

image.png

既然不是由写入速率提升造成的,那就接着排查其他可能占用CPU资源的行为。

2.索引查询速率

image.png

3.jvm gc次数

image.png

4.节点merge速率

记一次Elasticsearch问题排查_第1张图片

5.节点写入队列长度

image.png

由上述指标可以看出,写入耗时过久是因为索引的其中一个节点写入队列过长,无法及时处理写入导致的。然而在写入队列变长的过程中,节点的gc,merge等操作并无明显变化,索引的查询速率也没有明显提升,因此猜测是某些具有特殊特征的文档导致es写入过慢导致的。

在上述猜测下,我们的思路就变成了找出导致索引过慢的罪魁祸首文档。因此就从埋点数据中收集了很多慢索引文档,尝试手动索引,但均能很快索引完成。

但是线上问题依旧存在,为了使业务不出问题,我们从以下手段尝试修复线上问题:

1.加速Elasticsearch的索引效率

  • 调大索引的refresh_interval参数
  • 修改index.translog.durability为async等
  • 关闭部分字段的索引配置

ItVuer - 免责声明 - 关于我们 - 联系我们

本网站信息来源于互联网,如有侵权请联系:561261067@qq.com

桂ICP备16001015号