昨天上午蝴簇，運維支持組的小伙伴向我反饋說他們的es集群出了故障世曾，bulk寫性能突然下降了，平均1s中只有幾百條數(shù)據(jù)寫入
1霹抛、背景
SkyWalking作為公司鏈路采集系統(tǒng)搓逾，實時采集線上各個服務的鏈路數(shù)據(jù)。采樣率為全量杯拐，理論上TPS是監(jiān)控接入工程所有的TPS總和霞篡。目前后端使用ES作為數(shù)據(jù)存儲，鏈路數(shù)據(jù)保留7天端逼。生產(chǎn)環(huán)境目前接入的工程有83個朗兵，ES的數(shù)據(jù)寫入，和查詢出現(xiàn)了明顯的瓶頸顶滩。需要對ES做性能調(diào)優(yōu)余掖。
2、現(xiàn)狀
ES集群
2臺 2核 16g索引
1礁鲁、每個索引2分片盐欺、0副本赁豆，主要用到的是3個索引，分別是：global_trace找田、segment歌憨、segment_duration
2、索引數(shù)據(jù)在ES端保存7天墩衙，SkyWalking每5分鐘定時刪除7日前的數(shù)據(jù)
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的數(shù)據(jù)TTL策略是通過線程定時調(diào)用ES API條件刪除歷史數(shù)據(jù)心铃。目前配置是：鏈路數(shù)據(jù)存放7天，每5分鐘刪除7天前的數(shù)據(jù)挫剑。由于ES刪除緩慢去扣，導致數(shù)據(jù)堆積。惡性循環(huán)下導致本來設置的TTL時間為90分鐘樊破，結(jié)果卻堆積了近5天數(shù)據(jù)愉棱。目前直接把TTL時間改為了7天，數(shù)據(jù)刪除依然緩慢哲戚，幾乎沒有刪除掉奔滑，導致數(shù)據(jù)堆積越來越多。
Skywalking的TTl操作是通過 delete_by_query的方式實現(xiàn)的顺少，這種操作通過全表掃描的方式尋找滿足條件的數(shù)據(jù)朋其，數(shù)據(jù)體量大了之后非常消耗性能，通過觀察監(jiān)控發(fā)現(xiàn)CPU利用率一直處于100%狀態(tài)脆炎，基本沒有空閑資源處理其它請求梅猿。
做法時禁掉TTL操作，改為凌晨低峰時期刪除秒裕，優(yōu)化后的cpu利用率維持在80%-90%袱蚓。
- bulk寫性能低
TPS吞吐量估算為：800-1800，針對每分鐘5w次的寫入完全hold不住
bulk寫入性能低的一個原因是受delete_by_query的方式影響几蜻，解決了上面那個問題后癞松，bulk性能明顯提升不少，但依然無法滿足大量數(shù)據(jù)實時寫入的需求入蛆，那么還有哪些操作可以優(yōu)化呢响蓉？
1、增大索引buffer哨毁；indices.memory.index_buffer_size: 20%
2枫甲、增大刷新間隔；index.refresh_interval：120s
3、異步寫translog想幻； index.translog.durability：async
4粱栖、增大CPU核數(shù)，提升并發(fā)處理能力
5脏毯、使用SSD硬盤或者將單塊機械硬盤改為多塊使用
- Skywalking整體性能緩慢
Skywalking底層邏輯復雜闹究，會涉及到大量索引關聯(lián)與聚合操作，每次看板加載都在5秒以上食店。
官方建議單分片大小合理的區(qū)間值是20g~50G渣淤，上面3個索引的大小明顯超出了這個范圍，優(yōu)化建議：
1吉嫩、擴大索引分片數(shù)量
2价认、實現(xiàn)按天拆分索引
3、刪除7天之前的索引而不是使用delete_by_query
4自娩、增加服務器數(shù)量用踩，對索引進行冷熱數(shù)據(jù)分離，不經(jīng)常使用的索引可以降低分片數(shù)量
5忙迁、非當日索引強制合并segment段為1
3脐彩、4、5基于條件2
