博客轉載自：
https://www.jianshu.com/p/6d2e63801107
昨天上午，運維支持組的小伙伴向我反饋說他們的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
作者：_江邊城外_
鏈接：https://www.jianshu.com/p/6d2e63801107
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。