欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

Elasticsearch实战-磁盘IO被打满

程序员文章站 2022-07-02 12:51:27
背景 事情是这样的。一天下午4点42分左右。业务反馈我开发的服务在测试环境出现问题,返回资源数据是0。查日志发现是ES访问超时。相当于数据库挂了。持续了20多分钟自己恢复。咨询了ES团队,最终得到下面的答复: 调查 1.需要换成本地磁盘,测试环境也是我们的正式环境。是否能直接替换成物理机?多少台合适 ......

背景

事情是这样的。一天下午4点42分左右。业务反馈我开发的服务在测试环境出现问题,返回资源数据是0。查日志发现是es访问超时。相当于数据库挂了。持续了20多分钟自己恢复。
咨询了es团队,最终得到下面的答复:

当前集群现状:
1)当前集群数据io最高的索引为xxx,数据量很小(100mb) 
2)但是读写都很大(读>1000qps,写>1000qps) ,使用的是线下环境的机器
3)索引分了10个片,4个副本问题
分析:
1)线下环境的机器之前了解到测试环境硬盘性能本来就很差,这个需要业务sre一块来确定
2)查询的时候,会一次性查询10个片,这样可能会查10台机器的数据,很容易出现木桶效应,造成集群的性能下降
3)写入的时候,虽然是做了10个分片,看起来能加大写能力,但是机器数少,导致结果是每台机器分布了5个分片,等效于只做了2个分片,完全没有扩大写的能力
建议:
1)升级硬件,换成ssd
2)分片改成2个,这样读能力比以前肯定有提升,写能力等价
3)数据量很小,建议直接换成redis
我自己做了调查。测试环境es有十台vm(非本地esb磁盘)作为服务器。其中一台io被打满。其他机器负载、io都很低。对于这个问题,es团队给出的答复是:
es的服务负载均衡、发现机制是自己写的,一般不会出现问题,
client仅仅对官方的客户端做了简单的封装,
当然最好是可以对官方的客户端进行改造,
但是我们现在的人力明显不行,只能继续沿用老的客户端使用;
我们预计在10月份左右会出一个自研的客户端,
会尽量避免出现一台机器导致部分查询出现问题,
但是也避免不了,
es内部的服务发现机制,我们改变不了,除非改es

调查

1.需要换成本地磁盘,测试环境也是我们的正式环境。是否能直接替换成物理机?多少台合适?怎么可以平滑替换?

没有必要换成物理机。因为es内存最多能用32g。内存多出来的是浪费用不上,有物理机也是隔成vm来用。

原来10台vm是足够的,只需要同等数量替换。

有机器替换功能。替换时原理是先申请机器部署。然后点击机器替换。会一台台的将分片赶到新机器上。一台下完自动下线老机器。

2.我们测试环境有10台服务器,10个分片,4个副本,写/读qps大概是7:6。究竟几个分片几个索引更合理?

因为每个分片和副本是同步写。写比例大,副本多会对性能有很大影响。分片替换需要重建索引,很难平滑。所以只将副本数减少为一个分片1个。

3.程序方面有没有可以优化的?

在es上层增加tair缓存。在进行数据更新操作时是单个数据读取。采用tair有更好的事务性,并减少了对es的压力。es只处理复杂查询请求。