大流量大負載的Kafka集羣優化實戰

前言背景

算法優化改版有大需求要上線，在線特徵dump數據逐步放量，最終達到現有Kafka集羣5倍的流量，預計峯值達到萬兆網卡80%左右(集羣有幾十個物理節點，有幾PB的容量，網卡峯值流出流量會達到800MB左右/sec、寫入消息QPS爲100w+ msgs/sec)。上下游服務須要作擴容評估，提早作好容量規劃，保障服務持續穩定運行

• L3層 dump特徵 @xxx
  • 1.依賴文章特徵公共服務
  • 2.依賴用戶特徵公共服務 前期能夠一塊兒共建
• 評估dump特徵數據量 @xxx
• kafka新增Topic接收dump數據，評估kafka是否須要擴容 @xxx
• 新增拼接數據流支撐dump特徵，須要評估新增機器 @xxx

通過對Kafka集羣軟硬件資源及利用率綜合分析與評估，決定不擴容機器，徹底能夠應對流量擴大5倍的性能挑戰

流量灰度時間表

• 2020-02-21放量進度 流量灰度10%
• 2020-02-24放量進度 流量灰度30%
• 2020-03-02放量進度 流量灰度50%
• 2020-03-02放量進度 流量灰度70%
• 2020-03-03放量進度 流量灰度85%
• 2020-03-05放量進度 流量灰度100%

優化紀實

預先優化在topics建立的狀況下，沒有流量時作的優化工做
本次在線特徵dump放量topics列表以下：

onlinefeedback
indata_str_onlinefeedback_mixxxbrowser
indata_str_onlinefeedback_oppoxxxbrowser
indata_str_onlinefeedback_3rd
......

violet集羣的topics爲indata_str_click_s3rd 和 indata_str_video_3rd_cjv 完成擴容並rebalance找出其餘流量大的topics列表
以上topic都已經建立，可是隻覆蓋了少數磁盤掛載點，violet集羣有21個節點252磁盤掛載點，但有些topics的partitions數量不到30，形成磁盤利用率不高，IO不均衡。
優化點：擴容partitions數量，覆蓋更多磁盤掛載點

現狀&優化旅程

2020-02-21日 開始放量 topics均值流量小於20%，如下是放量後22~23日監控數據(讀寫IOPS、IOutil)

 

 

 

 

 

 

從以上數據分析，讀寫IOPS和ioutil極其不均衡，並且其中寫IOPS走向極端上下兩條線，後來查明緣由是zk事務日誌是實時單條commit，大量flink使用0.8.x版本，消費狀態用zk存儲形成的。另外還發現violet出口流量不均衡，高的70%、低的10%左右，當時flink消費出現阻塞現象，緣由爲上線前Flink未及時調大fetch.message.max.bytes的大小，引起violet集羣部分broker網絡出口流量飆升。

2020-02-26日 在線特徵dump數據的topics均值放量到50%左右
優化zk集羣寫入性能從1.5k降到100之內，單事務寫強制刷盤改成事務批量按期刷盤，在線Dump特徵流量放量，排查violet集羣線上隱患，因爲消費端flink仍是依賴的較低kafka-0.8.x版本，消費狀態存儲zk，致使寫入頻繁。此外zk的日誌數據和事務數據目錄從數據盤調整到系統盤，數據盤統一Kafka使用

 

 

客戶端使用優化 

serving使用kafka按key進行hash分配出現生產傾斜致使消費出現lag，和業務方商定修改消費邏輯解決此問題
2020-03-02日 在線特徵dump放量75%，優化violet集羣IO完成了80%以上，支撐在線特徵100%放量應該沒有問題，主要對10.120.14.十一、10.103.35.七、10.103.35.二、10.120.10.8等4個節點IO削峯均衡化，熱點掛載點IO峯值降低30~60%不等，操做策略以下：

• 擴容partitions，topics數據量大，partitions數量少，與業務溝通，擴partitions分配到低IO掛載點上
• 遷移partitions，partitions目錄遷移和節點遷移，找出熱點掛載點，分析出高讀寫的partitions，遷移到使用率低的磁盤掛載點上
• 調整topic保留時間，保證業務磁盤容量夠用不浪費，與業務溝通，設置topics最小保留時間

優化前監控(3.02~3.03區間數據)

 

 

ioutil被打滿，磁盤很是繁忙，響應變慢等待時間變長

優化後效果以下(3.06日區間數據)

 

 

紅框部分IO持續高位爲當時部分partition遷移致使的，能夠忽略不計，因爲2020-03-0二、2020-03-0三、2020-03-05持續放量直到100%，優化效果不明顯

2020-03-04日 客戶端參數優化

jstorm 

 

 

 

 

 flink

 

 

03-06日 優化violet集羣IO完成了95%以上，主要對10.120.14.十一、10.103.35.七、10.103.35.二、10.103.35.三、10.103.35.十、10.120.10.二、10.120.10.三、10.120.10.五、10.120.10.六、10.120.10.七、10.120.10.八、10.120.10.九、10.120.10.11等13個節點IO削峯均衡化和磁盤使用率均衡化 

下面是3.07~3.08日區間監控數據

 

 

 

 

 

3.08日 內時間點監控數據

 

 

3.08日 是週日 經過監控獲知indata_str_onlinefeedback_mibrowser和indata_str_onlinefeedback_3rd-small消費流量比較大，須要作IO均衡化
indata_str_onlinefeedback_mibrowser每秒消費流量

 

 

indata_str_onlinefeedback_3rd-small每秒消費流量2.5GB

 

 

03.09日 截止下午17:00最近6小時數據(3.08日晚優化後效果)

內核參數優化 

sudo blockdev --setra  16384  /dev/sdx
sudo sh -c 'echo "4096" > /sys/block/sdx/queue/nr_requests'
sudo sh -c 'echo "500" > /proc/sys/vm/dirty_writeback_centisecs'
sudo sh -c 'echo "35" > /proc/sys/vm/dirty_ratio'
sudo sh -c 'echo "5" > /proc/sys/vm/dirty_background_ratio'
sudo sh -c 'echo "2000" > /proc/sys/vm/dirty_expire_centisecs'

2020-03-11日 截止下午17:00最近6小時數據　　

 

 

可否徹底磁盤IO均衡，比較困難，但還能夠下降，由於這跟客戶端生產/消費策略及消費歷史數據有關，有些不可控因素。

2020-03-11日 kafka jvm heap優化 經過Kafka集羣業務監控發現利用率低
減小jvm heap大小，讓渡給pagecache作系統級數據緩存

 

 

 

 

另外Apache Kafka PMC大神王國璋回覆：Kafka對內存要求不大，可是若是客戶端版本較低會須要down convert version，這個過程是很是消耗CPU和內存的。緣由是Producer向Kafka寫入數據時，佔用的堆外內存NIO Buffer，當消費讀數據時，Kafka並不維護內存數據，由於使用系統函數sendfile將數據直接從磁盤文件複製到網卡設備中，而不須要經由應用程序之手。採集監控數據以下：

NIO Buffer

 

 

 

 non-heap memory

 

 

 

早期jvm heap配置爲32GB，後來優化爲16GB，如今降到10GB，既保證了kafka進程穩定，又不浪費內存

優化可否一次性解決到位 

性能優化可否預先或提早一次性所有搞定？
通常性topics的partitions擴容能夠提早作，jvm heap也能夠提早修改，可是有些參數就無法肯定了，由於集羣流量不大，負載不高，沒有性能瓶頸，找不到更看不出瓶頸在哪裏，優化了也看不出效果。之內核參數優化爲例

Centos Performance Tuning

另外IO均衡化也是，集羣流量壓力不大，找不到須要IO均衡化的目標topics。只有流量逐步放大，才容易發現並識別問題topics

因此優化須要分類、分批、分場景、根據瓶頸、風險、效果、難易程度逐步推動。

從預先優化到全面優化 

在線特徵dump上線持續放量直至100%過程，咱們作了大量調整和優化，它是一個按部就班和不斷完善的過程，不可能一蹴而就，回顧優化列表以下：

• 提早預先優化，預估大流量topics，擴容partitions覆蓋更多磁盤掛載點
• 依賴服務zookeeper優化：單條事務消息刷盤改成批量刷盤
• 容器級優化：jvm heap利用率優化，從16GB下降大10GB，多餘物理內存騰出給pagecache使用
• Kafka服務應用級優化
  • 調大replica.fetch.wait.max.ms，下降replica fetch Request無效請求數，釋放cpu計算和內存資源
  • 增大replica.fetch.max.bytes，特別是kafka重啓下降目標broker讀IOPS
  • 調大爲zookeeper.session.timeout = 20000ms，避免網絡抖動異常致使broker掉線
• 業務客戶端優化
  • jstorm
    • 生產端：增大batch大小，下降Producer Request次數，給磁盤write IO降壓
    • 消費端：增大各個fetch參數，下降生產/消費速率，給磁盤read IO降壓
  • flink：增大並行度，結合異步和jvm參數
• 持續IO均衡化
  • 擴容partitions，topics數據量大，partitions數量少，與業務溝通，擴partitions分配到低IO掛載點上
  • 遷移partitions，partitions目錄遷移和節點遷移，找出熱點掛載點，分析出高讀寫的partitions，遷移到使用率低的磁盤掛載點上
  • 調整topic保留時間，保證業務磁盤容量夠用不浪費，與業務溝通，設置topics最小保留時間
• centos內核參數優化，目標是提高性能，保證穩定，同時充分利用pagecache和OS讀寫磁盤特性，用各類策略榨乾取盡其資源
  
  • 設置/sys/block/sdb/queue/read_ahead_kb
  • 設置/sys/block/sdc/queue/nr_requests
  • ...省略，瞭解更多請看 centos系統參數優化

partition遷移重點分析

要作到全面性、多維度、立體化的綜合性能優化並達到預期理想效果，須要對相關Kafka、jvm、netty技術原理及OS等等(不限於)有至關理解。例如持續IO均衡化，就是須要運用綜合手段來解決，利用管理平臺、各種監控數據和shell命令找出觸發瓶頸的topics及對應partitions，而後用工具遷移實現IO再平衡。

 

以上操做是反覆循環進行的動做，觀察-》分析-》操做-》查看效果-》再觀察... 反覆進行直至達到最佳狀態

如下爲partitions目錄遷移bugs，通過分析，重啓後解決，錯誤緣由是broker應用內存中保留了partition目錄遷移狀態信息，重啓後還原，但繼續執行遷移須要從新操做

 

 小結

• 預先優化，保證初期放量穩定，性能不打折
• 持續優化，採起多種手段拍平IO毛刺，同時兼顧磁盤容量均衡
• 想要達到最佳效果，須要對centOS底層TCP傳輸、網絡處理、pagecache使用、IO調度、磁盤讀寫調度及刷盤機制有綜合性全面的理解；要對Kafka的底層原理、各類配置參數項等具備深入理解，能夠進行Kafka集羣參數調優，快速處理突發故障、恢復集羣抖動和動態進行集羣擴縮容等

 

博客引用地址：http://www.javashuo.com/article/p-zbntnfay-gc.html