Zookeeper fsync超时

问题简述

• ZK leader节点与follower节点之间fsync同步动作耗时过久，导致心跳超时，集群重新选举，与客户端连接断开，进而影响客户端业务逻辑

问题根源

• 根源可能在磁盘、网络、内存等的突发情况，不容易排查

问题规避

• 调整ZK参数，避免fsync耗时过久
• 主要为以下参数

# ZK自己的基准时间单位，以ms为单位
tickTime=3000
# 主从初始化允许的超时时间
initLimit=10
# 主从同步允许的超时时间
syncLimit=5
# 以KB为单位
preAllocSize=32768

InfluxDB iowait飚高

问题简述

• 对InfluxDB的查询以及表的删除动作均会导致服务器CPU iowait指标飚高，大量读请求影响了写请求

问题根源

• InfluxDB不加where条件的查询，哪怕按时间排序加limit限制，性能也可能很差，因为会遍历所有数据分片
• InfluxDB删除表的动作，相当于遍历所有数据分片

问题解决

• InfluxDB最好不要删除数据，如有需要也是通过过期策略清理历史数据，当某张表数据空时，InfluxDB会自行删除此表
• 查询语句性能做好评估

explain select * from "";
explain analyze select * from;

ElasticSearch 磁盘占用不均

问题简述

• ElasticSearch集群五个节点，其中一个节点的磁盘占用率相较其它节点要高

问题根源

• ElasticSearch分配分片，不看节点的磁盘使用率，而是看节点的分片数
• 某些节点的分片数大，但单个分片的磁盘占用小，所以导致不均

问题解决

• 将分片数与节点数调整为一致
• 根据实际情况清理一些索引
• 调整ES集群参数，水位线，此种方式也存在一些问题，强制不允许往某个节点写入数据会导致客户端报错

PUT _cluster/settings
{
   "persistent":{
      "cluster.routing.allocation.disk.watermark.high":"75%",
      "cluster.routing.allocation.disk.watermark.low":"70%"
    }
}