大流量大負載的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.11、10.103.35.7、10.103.35.2、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-02、2020-03-03、2020-03-05持續放量直到100%，優化效果不明顯

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

jstorm 

 

 

 

 

 flink

 

 

03-06日 優化violet集群IO完成了95%以上，主要對10.120.14.11、10.103.35.7、10.103.35.2、10.103.35.3、10.103.35.10、10.120.10.2、10.120.10.3、10.120.10.5、10.120.10.6、10.120.10.7、10.120.10.8、10.120.10.9、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集群參數調優，快速處理突發故障、恢復集群抖動和動態進行集群擴縮容等

 

部落格引用地址：https://www.cnblogs.com/lizherui/p/12632988.html 

VirMach 便宜 VPS

QNews

QNews