一 、性能監控

1 查看機器負載top：

右上角?load average 的 3 個值 1.29 ，0.74， 1.34 代表過去1分鐘、5分鐘 、15分鐘load average

假如 load值為5.2,? cpu核數為4? ，均值1.3>1 ,則存在進程搶不到CPU。? 如下值1.29說明負載較小，均負載在1.29/4 = 0.32

如果load值越來越大，說明負載持續增加

第三行cpu（s)表示用戶進程使用CPU時間總的占比平均值。

如下圖12個Core,? 所有us求和取平均值，? 及cpu（s)= 400/12 =34%

top 然后打 1 即可查看每個核心情況。

?

清單中的 %CPU, 上次更新到現在的CPU時間占用百分比。? ? ? ?top + c 可以查看 COMMAND完整的啟動進程命令，定位是哪一個應用。

%CPU顯示的是進程占用一個核的百分比，而不是整個cpu（8核）的百分比，有時候可能大于100，那是因為該進程啟用了多線程占用了多個核心，所以有時候我們看該值得時候會超過100%，但不會超過總核數*100。

?

?

?

2 kafka?GC日志路徑查看。

kafka的GC日志：/run/cloudera-scm-agent/process/150-kafka-KAFKA_BROKER

日志文件名類似：kafkaServer-gc.log

GC說明，參看?https://blog.csdn.net/qq_38157516/article/details/80451599

? ? ? ??https://blog.csdn.net/xiaodu93/article/details/61926114

? ? ? ??http://www.knowsky.com/957110.html

2.1 FULL GC頻率和時長

? ? ?長時間的停頓會令 Broker 端拋出各種超時異常。

2.2 活躍對象大小

? ??這個指標是你設定堆大小的重要依據，同時它還能幫助你細粒度地調優 JVM 各個代的堆大小。

? ? ? 活躍對象大小，即經過FULL GC后，老年代還剩余的存活對象大小（可以取多次平均值）。

如果FULL GC后剩余對象500M存活，設置老年代堆大小設置成該數值的 1.5 倍或 2 -3倍，即大約 1.0GB比較安全。

?newRatio參數，設定了新生代和老年代比值，默認值為2（old/new）. 一般設置為老年存活對象的1.2到2倍

永久代設置1.2-2倍。

?具體設置建議，參考：https://blog.csdn.net/zfgogo/article/details/81260172

如果頻繁FULL GC,? 可以開啟 G1 的 -XX:+PrintAdaptiveSizePolicy 開關(默認的 GC 收集器設置為 G1)，讓 JVM 告訴你到底是誰引發了 Full GC。

?

2.3?應用線程總數。這個指標幫助你了解 Broker 進程對 CPU 的使用情

?

3 集群監控

3.1 檢查broker是否啟動。

? ? ?并且查看端口是否建立監聽。

3.2?broker關鍵日志查看

? ? ? ?1）監控 kafka? ,log compaction線程是否正常運行。

? ? ? ?2）副本拉取消息的線程，通常以 ReplicaFetcherThread 開頭

? ? ? ? ? ? 線程掛掉，不再從 Leader 副本拉取消息，因而 Follower 副本的 Lag 會越來越大。

? ? ? ?上述異常，立即查看kafka 日志信息

? ? ? ?一般日志路徑：/var/log/kafka/kafka-broker-hadoop001.log

?3.3?Broker 端的關鍵 JMX 指標

? ? ? ?1）BytesIn/BytesOut：即 Broker 端每秒入站和出站字節數。你要確保這組值不要接近你的網絡帶寬，否則這通常都表示網卡已被“打滿”，很容易出現網絡丟包的情形

? ? ? ? 2）?NetworkProcessorAvgIdlePercent：即網絡線程池線程平均的空閑比例。通常來說，你應該確保這個 JMX 值長期大于 30%。如果小于這個值，就表明你的網絡線程池非常繁忙，你需要通過增加網絡線程數或將負載轉移給其他服務器的方式，來給該 Broker 減負。

? ? ? ? ?3）RequestHandlerAvgIdlePercent：即 I/O 線程池線程平均的空閑比例。同樣地，如果該值長期小于 30%，你需要調整 I/O 線程池的數量，或者減少 Broker 端的負載。

? ? ? ? 4）UnderReplicatedPartitions：即未充分備份的分區數。所謂未充分備份，是指并非所有的 Follower 副本都和 Leader 副本保持同步。一旦出現了這種情況，通常都表明該分區有可能會出現數據丟失。因此，這是一個非常重要的 JMX 指標。

? ? ? ? ? 注意： 如果某個leader replication存在UnderReplicated的分區，則出現了較嚴重問題。

? ? ? ? ?under replicated分區是指fellow分區同步leader replication超過了replica.lag.time.max.ms設置值（CDH默認10s)，將從副本中移除。

? ? ? ? ?offline partion是只某個分區的所有分區不可用。? under relicated是 分區的部分副本不可用。

?

? ? ? ? ?5）ISRShrink/ISRExpand：即 ISR 收縮和擴容的頻次指標。如果你的環境中出現 ISR 中副本頻繁進出的情形，那么這組值一定是很高的。這時，你要診斷下副本頻繁進出 ISR 的原因，并采取適當的措施。

?

? ? ? ? 6）ActiveControllerCount：即當前處于激活狀態的控制器的數量。正常情況下，Controller 所在 Broker 上的這個 JMX 指標值應該是 1，其他 Broker 上的這個值是 0。如果你發現存在多臺 Broker 上該值都是 1 的情況，一定要趕快處理，處理方式主要是查看網絡連通性。這種情況通常表明集群出現了腦裂。腦裂問題是非常嚴重的分布式故障，Kafka 目前依托 ZooKeeper 來防止腦裂。但一旦出現腦裂，Kafka 是無法保證正常工作的

? ? ? ?其它監控指標還有很多，可以按需官網查詢集成到監控平臺。

3.4 kafka客戶端監控

? ? ? ?1） 客戶端ping kafka服務器，看下RTT，往返花費時間。太長，網絡速度問題必須解決。

? ? ? ?2）kafka-producer-network-thread 開頭的線程是你要實時監控的。

它是負責實際消息發送的線程。一旦它掛掉了，Producer 將無法正常工作，但你的 Producer 進程不會自動掛掉，因此你有可能感知不到

? ? ? ?3）Producer 角度，你需要關注的 JMX 指標是 request-latency，即消息生產請求的延時。這個 JMX 最直接地表征了 Producer 程序的 TPS

?

?

? ? ? ?4）對于消費者而言，心跳線程事關 Rebalance，也是必須要監控的一個線程。

? ? ? ? ? 它的名字以 kafka-coordinator-heartbeat-thread 開頭。

? ? ?5） 從 Consumer 角度來說，records-lag 和 records-lead 是兩個重要的 JMX 指標。

? ? ? ? ? ? ?它們直接反映了 Consumer 的消費進度

? ? ? ? ?records-lag：?? 滯后程度，就是指消費者當前落后于生產者的程度。比方說，Kafka 生產者向某主題成功生產了 100 萬條消息，你的消費者當前消費了 80 萬條消息，那么我們就說你的消費者滯后了 20 萬條消息，即 Lag 等于 20 萬。

? ? ? ?? records-lead：? 指消費者最新消費消息的位移與分區當前第一條消息位移的差值。?

? ? ? ? 監控方法：

a)使用 Kafka 自帶的命令行工具 kafka-consumer-groups 腳本。
$ bin/kafka-consumer-groups.sh --bootstrap-server <Kafka broker連接信息> --describe --group <group名稱>

b)使用 Kafka Java Consumer API 編程。

?

c)使用 Kafka 自帶的 JMX 監控指標。

? ? ? ? ? ?kafka.consumer:type=consumer-fetch-manager-metrics,client-id=“{client-id}”的 JMX 指標，里面有很多屬性。

? ? ? ? ? ?可以針對分區級別：

JMX 名稱為：kafka.consumer:? ?type=consumer-fetch-manager-metrics,partition=“{partition}”,topic=“{topic}”,client-id=“{client-id}”

使用jconsole監控截圖：（jdk_home/bin/jconsole)

JMX 方式只能監控客戶端即counsumer所在節點。當主題較多，消費者較多時，監控不是很方便。

?

如果監控kafka主題、分區、數據流入流出、調整分區數、Lag等kafka manager比較直觀好看，不推薦kafka tool，不方便會卡頓。
如果要監控內存、線程安全、進程，Lag、Lead等的話，就會使用jconsole和jvisualvm，另外，有利于排查kafka是否存在死鎖問題。

? ? ?6）如果你使用了 Consumer Group，那么有兩個額外的 JMX 指標需要你關注下，一個是 join rate，另一個是 sync rate。

? ?它們說明了 Rebalance 的頻繁程度。如果在你的環境中，它們的值很高，那么你就需要思考下 Rebalance 頻繁發生的原因了。

?

?

二、Kafka性能優化

?

1 應用層面優化。

1.1）增加吞吐量：

a）Broker 端??

num.replica.fetchers

表示的是 Follower 副本用多少個線程來拉取消息，默認使用 1 個線程。如果你的 Broker 端 CPU 資源很充足，不妨適當調大該參數值，加快 Follower 副本的同步速度。增加這個值后，你通常可以看到 Producer 端程序的吞吐量增加。

調優GC參數

避免經常性的 Full GC，目前不論是 CMS 收集器還是 G1 收集器，其 Full GC 采用的是 Stop The World 的單線程收集策略，非常慢，因此一定要避免。

b)?Producer 端

batch.size?

目前它們的默認值都偏小，特別是默認的 16KB 的消息批次大小一般都不適用于生產環境。設置512k-1M

?linger.ms

適當增加 10-100.默認值0

compression.type = lz4 或zstd? , 減小網絡IO

acks=1或0

增加buffer.memory

當多個線程共享一個producer實例時，由于公用緩存，就可能會碰到緩沖區不夠用的情形。倘若頻繁地遭遇 TimeoutException：Failed to allocate memory within the configured max blocking time 這樣的異常，那么你就必須顯式地增加 buffer.memory 參數值

?

c) Consumer端

?I)采用多consumer進程或線程

II) 增加fetch.min.bytes參數，默認1字節，調大為1K或更大

表示只要 Kafka Broker 端積攢了 1 字節的數據，就可以返回給 Consumer 端，

?

1.2）減小延時：

延時和吞吐量有時有些互斥，說一要視情況調整：

a)在Broker 端，

依然要增加 num.replica.fetchers 值以加快 Follower 副本的拉取速度，減少整個消息處理的延時

b)在 Producer 端

設置 linger.ms=0，我們希望消息盡快地被發送出去，因此不要有過多停留

同時不要啟用壓縮。因為壓縮操作本身要消耗 CPU 時間，會增加消息發送的延時。另外，最好不要設置 acks=all。我們剛剛在前面說過，Follower 副本同步往往是降低 Producer 端吞吐量和增加延時的首要原因。

c)在 Consumer 端，

我們保持 fetch.min.bytes=1 即可，也就是說，只要 Broker 端有能返回的數據，立即令其返回給 Consumer，縮短 Consumer 消費延時。

?

2) JVM優化

?

3）OS優化

a)在操作系統層面，你最好在掛載（Mount）文件系統時禁掉 atime 更新。記錄 atime 需要操作系統訪問 inode 資源，而禁掉 atime 可以避免 inode 訪問時間的寫入操作，減少文件系統的寫操作數。你可以執行 mount -o noatime 命令進行設置

b)文件系統，我建議你至少選擇 ext4 或 XFS。ZFS最新的據說更好

c)swap 空間的設置。 個人建議將 swappiness 設置成一個很小的值，比如 1～10 之間

d）ulimit -n 和 vm.max_map_count。前者如果設置得太小，你會碰到 Too Many File Open 這類的錯誤，而后者的值如果太小，在一個主題數超多的 Broker 機器上，你會碰到 OutOfMemoryError：Map failed 的嚴重錯誤，因此，我建議在生產環境中適當調大此值，比如將其設置為 655360。具體設置方法是修改 /etc/sysctl.conf 文件，增加 vm.max_map_count=655360，保存之后，執行 sysctl -p 命令使它生效。

e) 操作系統頁緩存大小

給 Kafka 預留的頁緩存越大越好，最小值至少要容納一個日志段的大小，也就是 Broker 端參數 log.segment.bytes 的值，該值默認1G。

實際上 page cache大小不用設置，默認讀寫文件都會用到，當內存不夠時，作為應急，cache和buffer內存可以釋放。

但是有些參數是可以控制其工作方式。

free 命令可以查看 cache（page cache） 和 buffer(buffer cache)緩存使用大小。新版本linux將兩者合二為一顯示了。

概念參考：https://blog.csdn.net/lqglqglqg/article/details/82313966

https://blog.csdn.net/jasonchen_gbd/article/details/80151328

II) 控制page cache參數:?ls?/proc/sys/vm

如下幾個參數對page cache大小有影響：

vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 30
vm.dirty_writeback_centisecs = 500

1)dirty_writeback_centisecs?,?dirty_expire_centisecs

后臺進程pdflush或flush-n:m負責異步將寫操作writeback到磁盤。這個進程每個dirty_writeback_centisecs（默認值500，即5s）厘秒喚醒然后執行一次。他會檢查這些臟頁面的時間是不是超時了，超時的會被寫磁盤。超時時間就是dirty_expire_centisecs(30s)，? 加大此值可以增加page cache大小

2）dirty_background_bytes與dirty_background_ratio（默認10%）

?參數意義：當臟頁所占的百分比（相對于系統總內存）達到dirty_background_ratio或者
臟頁所占的內存數量超過dirty_background_bytes時，內核的pdflush線程開始回寫臟頁。

注意：dirty_background_bytes參數和dirty_background_ratio參數是相對的，只能指定其中一個，另一個參數的值自動清零

3）dirty_bytes與dirty_ratio（默認30%）

如果dirty_background_bytes與dirty_background_ratio還不能有效發揮作用，導致臟頁面比例持續升高，并且超過了dirty_ratio，那么那么執行write的那個用戶態進程自己會block住，等待pdflush干完活再喚起。在寫入超大時，即時內核的pdflush線程滿足dirty_background_ratio開始回收了，也可能立馬超過dirty_background_ratio到達dirty_ratio。

4）drop_caches

向/proc/sys/vm/drop_caches文件中寫入數值可以使內核釋放page cache，dentries和inodes緩存所占的內存。生產環境不要用。

? 只釋放pagecache：

? ? ? echo 1 > /proc/sys/vm/drop_caches

? 只釋放dentries和inodes緩存：

? ? ? echo 2 > /proc/sys/vm/drop_caches

? 釋放pagecache、dentries和inodes緩存：

? ? ? echo 3 > /proc/sys/vm/drop_caches

? 這個操作不是破壞性操作，臟的對象（比如臟頁）不會被釋放，因此要首先運行sync命令。

5）vfs_cache_pressure

? ? 控制內核回收dentry和inode cache內存的傾向。

? 默認值是100，內核會根據pagecache和swapcache的回收情況，讓dentry和inode cache的內存占用量保持在一個相對公平的百分比上。

? 減小vfs_cache_pressure會讓內核更傾向于保留dentry和inode cache。當vfs_cache_pressure等于0，在內存緊張時，內核也不會回收dentry和inode cache，這容易導致OOM。
? 如果vfs_cache_pressure的值超過100，內核會更傾向于回收dentry和inode cache。

6）min_free_kbytes

? ? 這個參數用來指定強制Linux VM保留的內存區域的最小值，單位是kb。VM會使用這個參數的值來計算系統中每個低端內存域的watermark[WMARK_MIN]值。每個低端內存域都會根據這個參數保留一定數量的空閑內存頁。

? 一部分少量的內存用來滿足PF_MEMALLOC類型的內存分配請求。如果進程設置了PF_MEMALLOC標志，表示不能讓這個進程分配內存失敗，可以分配保留的內存。并不是所有進程都有的。kswapd、direct reclaim的process等在回收的時候會設置這個標志，因為回收的時候它們還要為自己分配一些內存。有了PF_MEMALLOC標志，它們就可以獲得保留的低端內存。

? 如果設置的值小于1024KB，系統很容易崩潰，在負載較高時很容易死鎖。如果設置的值太大，系統會經常OOM。

總結

以上是生活随笔為你收集整理的Kafka性能监控与优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。