1 整體環境說明

1.1 硬件環境

1、 磁盤：SATA磁盤2塊，磁盤陣列為RAID1

2、 CPU****：2個4核CPU。具體參數：Intel(R) Xeon(R) CPU E5405 @ 2.00GHz

3、 內存：8G（8*1G）

4、 網卡：1000Mb/s

1.2 軟件環境

1、 kafka版本：kafka_2.11-2.11.0.0

2、 kafka集群數量：3

3、 zookeeper版本：zookeeper-3.4.12

4、 zookeeper集群數量：3

5、 zookeeper使用單獨的集群，不使用kafka自帶zookeeper

2 服務器自身瓶頸測試

由于kafka是的吞吐量特別大，所以先考慮集群服務器的自身瓶頸。如磁盤IO瓶頸。由于kafka做的集群所以需要相互傳輸數據，所以要考慮網卡瓶頸。

2.1 測試磁盤IO瓶頸

2.1.1 磁盤IO寫入瓶頸

1、使用以下命令測試磁盤IO的寫入瓶頸

# sync;time -p bash -c "(dd if=/dev/zero of=test.dd bs=1M count=20000)"

解釋：在當前目錄下創建一個test.dd的文件，寫入20000個1M的數據。

2、使用iostat命令監測磁盤io情況。

使用命令

# iostat -x 1

解釋：擴展查看io性能，每1秒鐘刷新一次。

注意：如果沒有iostat。請執行yum install sysstat –y命令進行安裝iostat命令

3、結果展示

（1）磁盤寫入IO結果

# sync;time -p bash -c "(dd if=/dev/zero of=test.dd bs=1M count=20000)"記錄了20000+0 的讀入記錄了20000+0 的寫出20971520000字節(21 GB)已復制，221.314 秒，94.8 MB/秒real 221.67user 0.01sys 21.20

磁盤寫入IO為94.8 MB/秒

（2）iostat命令結果

?

關注wkB/s和%util兩個參數

wkB/s：每秒寫入設備的數據量（單位：KB）

%util：消耗在I/O請求中的CPU時間百分比（設備帶寬利用率）。如果該值接近100%說明設備出現了瓶頸。

2.1.2 磁盤IO讀取瓶頸

1、使用以下命令測試磁盤IO的讀取瓶頸

# hdparm -tT --direct /dev/sda

解釋：hdparm命令是顯示與設定硬盤的參數。-t參數為評估硬盤的讀取效率(不經過磁盤cache)。-T參數為評估硬盤的讀取效率(經過磁盤cache)

注意：如果沒有hdparm命令可以直接yum –y install hdparm即可

2、使用iostat命令監測磁盤io情況。

使用命令

# iostat -x 1

3、結果展示

# hdparm -tT --direct /dev/sda/dev/sda:Timing O_DIRECT cached reads: 326 MB in 2.00 seconds = 162.83 MB/secTiming O_DIRECT disk reads: 322 MB in 3.01 seconds = 106.88 MB/sec

解釋：經過磁盤cache的磁盤讀取為162.83 MB/sec

未經過磁盤cache的磁盤讀取為106.88 MB/sec

2.2 磁盤性能總結

以我的服務器SATA磁盤2塊，磁盤陣列為RAID1的配置。磁盤寫入數據瓶頸為94.8 MB/秒。讀取數據瓶頸經過磁盤cache的磁盤讀取為162.83 MB/秒，未經過磁盤cache的磁盤讀取為106.88 MB/秒。如果kafka集群的寫入速度和讀取數據的速度達到這個數值，或者iostat的輸出結果%util的值接近100%。說明磁盤已經到達一個瓶頸。會影響壓測數據的準確性。

2.3 網卡性能總結

我的網卡是千兆網卡，傳輸數據可以達到1000Mb/s，由于我們使用的單位都為MB/s。所以把Mb換算成MB。1000Mb/s=125MB/s。也就是說傳輸熟讀到達125MB/s的時候是網卡的瓶頸。會影響壓測數據的準確性。

3 Kafka測試前期準備

3.1 影響測試結果配置分析

Kafka的性能測試主要測試kafka的吞吐量，kafka吞性能為生產者在向kafka傳入消息時的寫入量，kafka的吐性能為消費者在kafka集群中消費的能力，也就是讀取量。

3.1.1 Borker相關

Kafka的borker是kafka集群的緩存代理，消息中間件處理結點，一個Kafka節點就是一個broker，多個broker可以組成一個Kafka集群。下面是相關broker的參數分析。

1、num.partiton

topic物理上的分組，一個topic可以分為多個partition，每個partition是一個有序的隊列。

Partition的數量選取也會直接影響到Kafka集群的吞吐性能。例如我們接口如果開了多個線程去消費kafka的數據，當Partition數量相對于流入流出的數據量顯得較少，或由于業務邏輯和Partition數量沒有匹配好造成個別Partition讀寫數據量大，大量的讀寫請求集中落在一臺或幾臺機器上時就會很影響效率。

2、Default.replication.factor

Replication參數為kafka集群副本數。這個參數決定了kafka的高可用性。也決定了kafka的吞吐量。此數據運算和broker個數和broker上的分區數量都有關系。正常broker為3replication設置為1最好。因為3個節點的集群可以宕機一臺可以繼續工作，而3個replication可以保證宕機兩個節點正常工作。所以多replication會造成資源浪費。如果數據不需要持久化和數據不重要并且寫入量特別大的話，可以考慮replication為0。

3、num.network.thread

用于接收并處理網絡請求的線程數，默認為3。其內部實現是采用Selector模型。啟動一個線程作為Acceptor來負責建立連接，再配合啟動num.network.threads個線程來輪流負責從Sockets里讀取請求，一般無需改動，除非上下游并發請求量過大。

4、寫入數據每條大小

'{"indexdiy":"catalina","input_type":"log","message":"[2018-09-26 12:30:13,030] [org.apache.tomcat.util.net.NioSelectorPool] [INFO] [Using a shared selector for servlet write/read]","offset":17600578,"project_tag":"catalina","source":"/opt/tomcat7/logs/catalina.out","type":"log"}'

以上面一條日志為例。此條日志大小為283B。所以我們測試基準為200B和500B。

3.1.2 Consumer相關

Consumer為kafka的消費者，同一個topic消費者越多越快，但是需要注意的是，消費者的數量不能超過topic的分區數量，因為每個topic的每個分區只能被一個消費者消費，多出來的消費者會無信息可消費。導致資源浪費。

3.2 測試命令詳解

1、創建topic命令

# ./kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test -7

--replication-factor：指定副本個數
--partitions：指定分區個數
--topic：指定topic名

2、查看topic命令

# ./kafka-topics.sh --zookeeper 10.10.4.11:2181 --list

3、查看指定topic的詳細內容

# ./kafka-topics.sh --zookeeper 10.10.4.11:2181 --topic test_property --describe

5、 寫入數據

# ./kafka-producer-perf-test.sh --num-records 10000000 --topic test-ref-9 --record-size 500 --throughput 100000 --producer-props bootstrap.servers=10.10.4.11:9092,10.10.4.12:9092,10.10.4.13:9092

--num-records：記錄的條數
--topic：指定topic的名字
--record-size：一條記錄大小。
--throughput：吞吐數量
--producer-props bootstrap.servers=IP:9092,IP:9092,IP:9092：指定kafka集群

注意：-- throughput參數為寫入數量，如果結果接近此數量，建議*10再測試一次。因為和此結果相近說明kafka沒有到達瓶頸。

6、消費數據

# ./kafka-consumer-perf-test.sh --messages 10000000 --threads 3 --zookeeper localhost:2181 --num-fetch-threads 3 --topic test-ref-8

--messages：指定消費條目數
--threads：指定線程數
--num-fetch-threads 3：指定消費人數

注意：執行以上命令在kafka****家目錄下的/bin****下執行命令

4 Kafka寫入性能測試

在測試kafka寫入性能測試的時候一邊檢測系統的cpu使用情況、內存使用情況和磁盤IO情況。

4.1 測試kafka的partition參數

4.1.1 創建不同partition的topic并寫入數據1000萬條數據。

1、 創建一個副本，partition分別為1、3、6、12的topic分別為test-0、test-1、test-2、test-3

2、 向topic內寫入1000萬條500B的數據，一次寫入100萬條，replication為1。并且開啟另一個窗口使用iostat命令實時監控磁盤IO情況。

4.1.2 測試結果

1、寫入數據如下表

?

3、 磁盤IO情況

由于磁盤IO瓶頸在94.8 MB/秒得出的數據只有partition為1的情況下在60MB/秒。所以大多數情況下%util處于一個100%的狀態。在partition為1的情況下是隔兩秒會出現%util值為100%。

?

4.2 kafka的partition參數總結

由于壓力測試沒有到達kafka的瓶頸，而是到達了服務器的瓶頸。所以以上數據僅供參考。如想測試更準確的數據。需要性能更好的磁盤來做測試。

在其他數據相同，而partition不同的時候。結論是partition越多寫入速度越快。但是partition數量越多會照成kafka集群可用性越差。所以建議，在實際生產環境。有多少個broker，partition數就為多少。這樣可以保證kafka集群的高可用性。可以保證n-1/2個節點宕機而不影響kafka集群使用。

4.3 測試Kafka的replication參數

4.3.1 創建不同replication的topic并寫入數據1000萬條數據。

1、創建一個副本，replication分別為2和3的topic為test-4、test-5。和之前創建的test-1。一起做測試

2、向topic內寫入1000萬條500B的數據，一次寫入100萬條，partition為3（因為我的broker是3個）。并且開啟另一個窗口使用iostat命令實時監控磁盤IO情況。

4.3.2 測試結果

1、寫入數據如下表

?

2、磁盤IO情況

由于磁盤IO瓶頸在94.8 MB/秒得出的數據只有replication為3的情況下在70MB/秒。所以大多數情況下%util處于一個100%的狀態。在replication為3的情況下也是一直%util值為100%。

?

4.4 kafka的replication參數總結

由于壓力測試沒有到達kafka的瓶頸，而是到達了服務器的瓶頸。所以以上數據僅供參考。如想測試更準確的數據。需要性能更好的磁盤來做測試。

在其他數據相同，而replication不同的時候。結論是replication越少寫入速度越快。但是replication數量越少會照成kafka集群可用性越差。所以建議，在實際生產環境。Kafka集群broker為3的時候replication為1，可以保證一臺節點宕機集群可用。其他架構需繼續深入研究。

4.5 測試Kafka的network.thread參數

1、 修改配置文件network.thread的參數為1，重啟kafka進行對test-1進行寫入測試。

2、 和之前test-1的數據進行對比。

4.5.1 測試結果

1、寫入數據如下

?

2、磁盤IO情況

?

磁盤已經到達瓶頸。

4.6 Kafka的network.thread參數總結

從結果可看出kafka的network.thread參數越多寫入速度越快。但是增加的非常不明顯。除非寫入速度要求極高的情況，或者機器性能足夠好。其他情況建議使用默認值3即可。

4.7 測試kafka的單條數據大小參數

1、 修改命令--record-size參數。

2、 同往test-1里寫入進行測試

4.7.1 測試結果

1、寫入數據如下

?

2、磁盤IO情況

?

磁盤已經到達瓶頸。

4.8 Kafka的單條數據大小參數總結

從結果顯示證明如果寫入kafka的數據量單條越小，傳輸速度越快。正常我們的日志大約在300B每條，最大為500B每條。所以我們按照最大的數據量進行傳輸來測試寫入量。

5 Kafka寫入數據測試整體總結

在kafka寫入數據的時候，主要參數在于partition的數量、replication的數量及單條數據的大小。對于線程數對寫入速度并不是特別影響。在測試的時候觀察cpu使用情況和內存使用情況。Kafka在有寫入的時候對于本身的內存要求不大，jvm設置為1G就可以，但是kafka機制是kafka先寫入系統頁緩存內，所以需要的內存比較大。不建議和使用內存較大的應用部署在一臺機器上，如elasticsearch。如果服務器內存較大，建議kafka使用4G左右jvm。Kafka對cpu要求不是特別大。一般兩核以上就可以。

6 Kafka讀取性能測試

在測試kafka讀取性能測試的時候一邊檢測系統的cpu使用情況、內存使用情況和磁盤IO情況。

注意事項：寫入數據后等一段時間再進行測試，因為可能有些數據還在內存中，所以看不出磁盤IO的瓶頸。

6.1 測試kafka的partition參數

1、由于之前已經寫入1000萬數據，可以直接在test-0、test-1、test-2、test-3的topic 并且Consumer為3、線程為3。直接讀取這些數據進行測試。

6.1.1 測試結果

1、讀取數據如下表

?

2、磁盤IO情況

磁盤IO有時會到達瓶頸，但是次數不多。

?

6.2 Kafka的partition參數總結

壓測結果證明partition越多速度越快，實際情況我們建議和之前一樣。有多少個broker，partition數就為多少。這樣可以保證kafka集群的高可用性?？梢员ＷCn-1/2個節點宕機而不影響kafka集群使用。詳細情況kafka寫入測試的partition總結。

6.3 測試Kafka的consumer參數

以test1為測試topic。分別使用1、3、6個consumer來進行讀取測試。

6.3.1 測試結果

1、寫入數據如下表

?

2、磁盤IO情況

磁盤IO有時會到達瓶頸，但是次數不多。

?

3、 使用軟件KafkaOffsetMonitor監控不同consumer的滯留情況lag為滯留信息條目數

（1）一個consumer三個partition

?

（2）三個consumer三個partition

?

（3）三個consumer六個partition

?

6.4 kafka的consumer參數總結

從測試結果可以看出，consumer這個參數不是越多越好，而是和topic的partition相同時性能最優，如果consumer大于partition的時候，測試開始會報錯，內容大意為，有xx個consumer是沒有分區可以消費的。這個參數可以根據項目本身去定義。但是不要超過topic的partition數目。但是consumer少會有消息滯留現象。

6.5 測試Kafka的線程參數

通過test-1 topic進行測試。

6.5.1 測試結果

1、 寫入數據如下表

?

2、 磁盤IO

?

6.6 kafka的線程參數總結

從測試結果來看線程數并不影響kafka的寫入速度。

7 Kafka讀取性能總結

Kafka寫入性能主要在于partition參數和consumer參數。Partition參數和的具體值可以直接參考寫入性能總結，這里不再贅述。Consumer的性能測試來看，只要不多于partition的數量都是可以的。如果broker的數量比較多，建議多設置幾個。

Kafka讀取對于replication無關，因為replication不參與讀取，只做容災備份的。對線程數也沒那么大的關系。

讀取數據對cpu負載不是特別高，2核以上夠用，如果是實時讀取數據，對磁盤來說性能要求并不高，因為短時間內，一些數據都是在內存里可以直接取到的。

8 Kafka整體性能總結

對于ELK集群來說，整體性能還是比較好的，一般影響測試結果都是磁盤的瓶頸造成的。對于磁盤來說用SATA磁盤就可以，因為kafka的寫入讀取機制都是順序寫入、讀取的。SATA順序讀寫速度大約在53MB/s和SSD的順序讀取都是差不多的。如果做RAID建議做RAID5。

Kafka對于CPU和內存要求不是特別大，一般CPU建議在8核以上，內存建議在8G以上。如果服務器性能好kafka的jvm建議設置4G。

Kafka在我的測試環境下，broker為3的集群情況下。Replication參數為1，partition參數為3，線程數為3，consumer數為3，輸入讀取的文件大小為500B。整體kafka的寫入速度為242665條/秒，傳輸大小為115.71 MB/秒。讀取速度為241390條/秒，傳輸大小為115MB/秒。

但是以上數據幾乎都是遇到了磁盤IO的瓶頸，數據不是特別準確，希望可以有更好的環境，對kafka進行更全面的測試。

最后貼上整體數據

生產

?

消費


鏈接：https://www.jianshu.com/p/799f2ca809b8
?

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的kafka压力测试说明的全部內容，希望文章能夠幫你解決所遇到的問題。

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