昨天上午，运维支持组的小伙伴向我反馈说他们的es集群出了故障，bulk写性能突然下降了，平均1s中只有几百条数据写入
1、背景
SkyWalking作为公司链路采集系统，实时采集线上各个服务的链路数据。采样率为全量，理论上TPS是监控接入工程所有的TPS总和。目前后端使用ES作为数据存储，链路数据保留7天。生产环境目前接入的工程有83个，ES的数据写入，和查询出现了明显的瓶颈。需要对ES做性能调优。
2、现状
-
ES集群
2台 2核 16g -
索引
1、每个索引2分片、0副本，主要用到的是3个索引，分别是：global_trace、segment、segment_duration
2、索引数据在ES端保存7天，SkyWalking每5分钟定时删除7日前的数据
3、索引大小：
global_trace: 150G
segment: 222G
segment_duration: 150G -
单索引查询分析
global_trace：查询 2 个分片中用的 2 个. 724450976 命中. 耗时 6.499 秒
segment_duration：查询 2 个分片中用的 2 个. 788681707 命中. 耗时 7.662 秒
segment：查询 2 个分片中用的 2 个. 1304838269 命中. 耗时 11.767 秒
3、主要问题
- SkyWalking 定时删除堆积
Skywalking的数据TTL策略是通过线程定时调用ES API条件删除历史数据。目前配置是：链路数据存放7天，每5分钟删除7天前的数据。由于ES删除缓慢，导致数据堆积。恶性循环下导致本来设置的TTL时间为90分钟，结果却堆积了近5天数据。目前直接把TTL时间改为了7天，数据删除依然缓慢，几乎没有删除掉，导致数据堆积越来越多。
Skywalking的TTl操作是通过 delete_by_query的方式实现的，这种操作通过全表扫描的方式寻找满足条件的数据，数据体量大了之后非常消耗性能，通过观察监控发现CPU利用率一直处于100%状态，基本没有空闲资源处理其它请求。
做法时禁掉TTL操作，改为凌晨低峰时期删除，优化后的cpu利用率维持在80%-90%。
- bulk写性能低
TPS吞吐量估算为：800-1800，针对每分钟5w次的写入完全hold不住
bulk写入性能低的一个原因是受delete_by_query的方式影响，解决了上面那个问题后，bulk性能明显提升不少，但依然无法满足大量数据实时写入的需求，那么还有哪些操作可以优化呢？
1、增大索引buffer；indices.memory.index_buffer_size: 20%
2、增大刷新间隔；index.refresh_interval：120s
3、异步写translog； index.translog.durability：async
4、增大CPU核数，提升并发处理能力
5、使用SSD硬盘或者将单块机械硬盘改为多块使用
- Skywalking整体性能缓慢
Skywalking底层逻辑复杂，会涉及到大量索引关联与聚合操作，每次看板加载都在5秒以上。
官方建议单分片大小合理的区间值是20g~50G，上面3个索引的大小明显超出了这个范围，优化建议：
1、扩大索引分片数量
2、实现按天拆分索引
3、删除7天之前的索引而不是使用delete_by_query
4、增加服务器数量，对索引进行冷热数据分离，不经常使用的索引可以降低分片数量
5、非当日索引强制合并segment段为1
3、4、5基于条件2
网友评论