kafka叢集基於吞吐量指標進行效能調優實踐-kafka 商業環境實戰
本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。期待加入IOT時代最具戰鬥力的團隊。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。
概要
- 效能
- 吞吐量：broker或者clients應用程式每秒能處理多少位元組（或訊息）
- 延時：通常指Producer傳送到broker端持久化儲存訊息之間的時間間隔。
- 可用性：系統和元件正常執行的概率或時間比率，業界一般N個9來量化可用性，比如年度4個9表示53分鐘（365* 24 * 60 * 0.01%=53分鐘）
- 永續性：已提交的訊息需要被持久化到Broker端底層的檔案系統的物理日誌而不能丟失。
1 kafka 基礎設施優化
-
磁碟容量：首先考慮的是所需儲存的訊息所佔用的總磁碟容量和每個broker所能提供的磁碟空間。如果Kafka叢集需要保留 10TB資料，單個broker能儲存 2TB，那麼我們需要的最小Kafka叢集大小5 個broker。此外，如果啟用副本引數，則對應的儲存空間需至少增加一倍（取決於副本引數）。這意味著對應的Kafka叢集至少需要 10 個broker。
-
檔案系統在檔案被訪問、建立、修改等的時候會記錄檔案的一些時間戳，比如：檔案建立時間（ctime）、最近一次修改時間（mtime）和最近一次訪問時間（atime）。預設情況下，atime的更新會有一次讀操作，這會產生大量的磁碟讀寫，然而atime對Kafka完全沒用。
mount -o noatime -
絕大多數執行在Linux上的軟體都是基於EXT4構建和測試的，因此相容性上EXT4要優於其他檔案系統。
-
作為高效能的64位日誌檔案系統（journaling file system），XFS表現出高效能，高伸縮性，特別適應於生產伺服器，特別是大檔案（30+GB）操作。很多儲存類的應用都適合選擇XFS作為底層檔案系統。
-
計算機的記憶體分為虛擬記憶體和實體記憶體。實體記憶體是真實的記憶體，虛擬記憶體是用磁碟來代替記憶體。
並通過swap機制實現磁碟到實體記憶體的載入和替換,這裡面用到的磁碟我們稱為swap磁碟。在寫檔案的時候，Linux首先將資料寫入沒有被使用的記憶體中，這些記憶體被叫做記憶體頁（page cache）。然後讀的時候，Linux會優先從page cache中查詢，如果找不到就會從硬碟中查詢。
當實體記憶體使用達到一定的比例後，Linux就會使用進行swap，使用磁碟作為虛擬記憶體。
通過cat /proc/sys/vm/swappiness可以看到swap引數。這個引數表示虛擬記憶體中swap磁碟佔了多少百分比。0表示最大限度的使用記憶體，100表示儘量使用swap磁碟。系統預設的引數是60，當實體記憶體使用率達到40%，就會頻繁進行swap，影響系統性能，推薦將vm.swappiness 設定為較低的值1。
最終我設定為10，因為我們的機器的記憶體還是比較小的，只有40G，設定的太小，可能會影響到虛擬記憶體的使用吧。臨時修改：sudo sysctl vm.swappiness=N 永久修改（/etc/sysctl.conf）：vm.swappiness=N
2 kafka JVM設定
-
PermGen space : 全稱是Permanent Generation space，是指記憶體的永久儲存區域，為什麼會發生記憶體溢位？這一部分用於存放Class和Meta的資訊, Class在被 Load的時候被放入PermGen space區域，它和存放Instance的Heap區域不同,所以如果你的APP會LOAD很多CLASS的話,就很可能出現PermGen space錯誤。
-
G1演算法將堆劃分為若干個區域（Region），它仍然屬於分代收集器。不過，這些區域的一部分包含新生代，新生代的垃圾收集依然採用暫停所有應用執行緒的方式，將存活物件拷貝到老年代或者Survivor空間。老年代也分成很多區域，G1收集器通過將物件從一個區域複製到另外一個區域，完成了清理工作。這就意味著，在正常的處理過程中，G1完成了堆的壓縮（至少是部分堆的壓縮），這樣也就不會有cms記憶體碎片問題的存在了。
-
在G1中，還有一種特殊的區域，叫Humongous區域。 如果一個物件佔用的空間超過了分割槽容量50%以上，G1收集器就認為這是一個巨型物件。這些巨型物件，預設直接會被分配在年老代，但是如果它是一個短期存在的巨型物件，就會對垃圾收集器造成負面影響。為了解決這個問題，G1劃分了一個Humongous區，它用來專門存放巨型物件。如果一個H區裝不下一個巨型物件，那麼G1會尋找連續的H分割槽來儲存。為了能找到連續的H區，有時候不得不啟動Full GC。
-
G1採用記憶體分割槽(Region)的思路，將記憶體劃分為一個個相等大小的記憶體分割槽，回收時則以分割槽為單位進行回收，存活的物件複製到另一個空閒分割槽中。由於都是以相等大小的分割槽為單位進行操作，因此G1天然就是一種壓縮方案(區域性壓縮)；
-
G1雖然也是分代收集器，但整個記憶體分割槽不存在物理上的年輕代與老年代的區別，也不需要完全獨立的survivor(to space)堆做複製準備。G1只有邏輯上的分代概念，或者說每個分割槽都可能隨G1的執行在不同代之間前後切換；
-
G1的收集都是STW的，但年輕代和老年代的收集界限比較模糊，採用了混合(mixed)收集的方式。即每次收集既可能只收集年輕代分割槽(年輕代收集)，也可能在收集年輕代的同時，包含部分老年代分割槽(混合收集)，這樣即使堆記憶體很大時，也可以限制收集範圍，從而降低停頓。
-
堆記憶體中一個Region的大小可以通過-XX:G1HeapRegionSize引數指定，大小區間只能是1M、2M、4M、8M、16M和32M，總之是2的冪次方，如果G1HeapRegionSize為預設值，則在堆初始化時計算Region的實踐大小，預設把堆記憶體按照2048份均分，最後得到一個合理的大小。
-
JVM 8 metaSpace 誕生了: 不過元空間與永久代之間最大的區別在於：元空間並不在虛擬機器中，而是使用本地記憶體。因此，預設情況下，元空間的大小僅受本地記憶體限制，但可以通過以下引數來指定元空間的大小：
-XX:MetaspaceSize，初始空間大小，達到該值就會觸發垃圾收集進行型別解除安裝，同時GC會對該值進行調整：如果釋放了大量的空間，就適當降低該值；如果釋放了很少的空間，那麼在不超過MaxMetaspaceSize時，適當提高該值。 -
-XX:MinMetaspaceFreeRatio，在GC之後，最小的Metaspace剩餘空間容量的百分比，減少為分配空間所導致的垃圾收集
-XX:MaxMetaspaceFreeRatio，在GC之後，最大的Metaspace剩餘空間容量的百分比，減少為釋放空間所導致的垃圾收集 -
XX:MaxGCPauseMillis=n : 設定最大GC停頓時間(GC pause time)指標(target). 這是一個軟性指標(soft goal)， JVM 會盡量去達成這個目標。
-
InitiatingHeapOccupancyPercent： 整個堆疊使用達到百分之多少的時候，啟動GC週期. 基於整個堆，不僅僅是其中的某個代的佔用情況，G1根據這個值來判斷是否要觸發GC週期, 0表示一直都在GC，預設值是45（即45%慢了，或者說佔用了)
-
-XX:G1NewSizePercent 新生代最小值，預設值5%
-
-XX:G1MaxNewSizePercent 新生代最大值，預設值60%
-
MetaspaceSize: 這個JVM引數是指Metaspace擴容時觸發FullGC的初始化閾值，也是最小的閾值。
# export JAVA_HOME=/usr/java/jdk1.8.0_51 # export KAFKA_HEAP_OPTS=" -Xmx6g -Xms6g -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=128m -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50 " -
本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。期待加入IOT時代最具戰鬥力的團隊。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。
3 檔案調優
-
若出現"too many files open"錯誤時，就需要為Broker所在的機器調優最大檔案部署符上限。檔案控制代碼個數計算方法如下：
broker上可能最大分割槽數*（每個分割槽平均資料量/平均的日誌段大小+3）其中3 表示索引檔案個數， 假設20個分割槽，分割分割槽總資料量為100GB，每一個日誌段大小是1GB，那麼這臺機器最大檔案部署符大小應該是： 20*（100/1+3）=2060 因此該引數一定要設定足夠大。比如100000 -
若出現"java.lang.OutOfMemoryError:Map failed的嚴重錯誤，主要原因是大量建立topic將極大消耗作業系統記憶體，使用者可以適當調整vm.max.map.count引數，具體方法如下：
/sbin/sysctl -w vm.max_map_count = N ，該引數預設值是65535，可以考慮線上環境設定更大的值。
4 吞吐量
Broker端；
- 適當增加num.replica.fetchers，但不要超過CPU核數，該值控制了broker端follower副本從leader副本處獲取訊息的最大執行緒數。預設值是1，表明follower副本只使用一個執行緒實時拉取leader處的最新訊息。對於設定了acks=all的producer而言，主要延時可能耽誤在follower與leader同步過程，所以增加該值可以縮短同步的時間，從而間接的提升Producer端的TPS。
- 調優GC避免經常性的Full GC。老版本過渡依賴Zookeeper來表徵Consumer還活著，若GC時間過長，會導致Zookeeper會話過期，kafka會立即對group進行rebalance。新版本上已經棄用了對Zookeeper的依賴。
Producer端：
- 適當增加batch.size，比如100-512KB。
- 適當增加linger.ms，比如10-100毫秒
Producer端是批量傳送訊息的，更大的batch size可以令更多的訊息封裝進同一個請求，故傳送給broker端的總請求數就會減少，此舉可以減輕Producer的負載，也降低了broker端的CPU請求處理開銷。而更大的linger.ms使producer等待更長的時間才傳送訊息，這樣就能夠快取更多的訊息填滿batch，從而從整體上提升TPS。但是延時肯定增加了。 - 設定壓縮型別compression.type=lz4，目前支援的壓縮方式有：GZIP，Snappy，LZ4，在CPU資源豐富的情況下compression.type=lz4的效果是最好的。
- acks=0或1
- retries=0
- 若多執行緒共享Produer或分割槽數很多時，增加buffer.memory。因為每一個分割槽都會佔用一個batch.size。
consumer端
- 採用多Consumer例項，共同消費多分割槽資料，這些例項共享相同的group.id。
- 增加fetch.min.bytes，比如10000，表徵每次leader副本所在的broker所返回的最小資料量來間接影響TPS,通過增加該值，Kafka會為每一個FETCH請求的response填入更多的資料。
5 悖論存在（分割槽數越多，TPS越高）
- Kafka基本的並行單元就是分割槽，producer在設計時實現了能夠同時向多個分割槽傳送訊息，從而這些訊息最終寫入到多個broker上，最終可以被多個consumer同時消費。通常來說，分割槽數越多，TPS越高
- 分割槽數越多，佔用的緩衝區越多，因為緩衝區是以分割槽為粒度的，所以Server/clients端將佔用更多的記憶體。
- 每一個分割槽在底層檔案系統中都有專屬目錄，除了3個索引檔案外還儲存日誌段檔案，會佔用大量的檔案控制代碼。
- 每一個分割槽都有若干個副本儲存在不同的broker上，當broker掛掉後，因為需要Controller進行處理leader變更請求，該處理執行緒是單執行緒，瘋了吧，亞歷山大。
- 本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。期待加入IOT時代最具戰鬥力的團隊。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。
7 總結
num.replica.fetchers倒是一個新穎的選手，可以好好試試，acks重點關注，其他都中規中矩。一片好文得來不易，尊重原創，謝絕轉載，謝謝！
本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。期待加入IOT時代最具戰鬥力的團隊。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。
秦凱新 於深圳 201812032355