1 整體環(huán)境說明

1.1 硬件環(huán)境

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

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

3、 內(nèi)存：8G（8*1G）

4、 網(wǎng)卡：1000Mb/s

1.2 軟件環(huán)境

1、 kafka版本：kafka_2.11-2.11.0.0

2、 kafka集群數(shù)量：3

3、 zookeeper版本：zookeeper-3.4.12

4、 zookeeper集群數(shù)量：3

5、 zookeeper使用單獨(dú)的集群，不使用kafka自帶zookeeper

2 服務(wù)器自身瓶頸測試

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

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)"

解釋：在當(dāng)前目錄下創(chuàng)建一個(gè)test.dd的文件，寫入20000個(gè)1M的數(shù)據(jù)。

2、使用iostat命令監(jiān)測磁盤io情況。

使用命令

# iostat -x 1

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

注意：如果沒有iostat。請(qǐng)執(zhí)行yum install sysstat –y命令進(jìn)行安裝iostat命令

3、結(jié)果展示

（1）磁盤寫入IO結(jié)果

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

磁盤寫入IO為94.8 MB/秒

（2）iostat命令結(jié)果

?

關(guān)注wkB/s和%util兩個(gè)參數(shù)

wkB/s：每秒寫入設(shè)備的數(shù)據(jù)量（單位：KB）

%util：消耗在I/O請(qǐng)求中的CPU時(shí)間百分比（設(shè)備帶寬利用率）。如果該值接近100%說明設(shè)備出現(xiàn)了瓶頸。

2.1.2 磁盤IO讀取瓶頸

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

# hdparm -tT --direct /dev/sda

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

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

2、使用iostat命令監(jiān)測磁盤io情況。

使用命令

# iostat -x 1

3、結(jié)果展示

# 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

解釋：經(jīng)過磁盤cache的磁盤讀取為162.83 MB/sec

未經(jīng)過磁盤cache的磁盤讀取為106.88 MB/sec

2.2 磁盤性能總結(jié)

以我的服務(wù)器SATA磁盤2塊，磁盤陣列為RAID1的配置。磁盤寫入數(shù)據(jù)瓶頸為94.8 MB/秒。讀取數(shù)據(jù)瓶頸經(jīng)過磁盤cache的磁盤讀取為162.83 MB/秒，未經(jīng)過磁盤cache的磁盤讀取為106.88 MB/秒。如果kafka集群的寫入速度和讀取數(shù)據(jù)的速度達(dá)到這個(gè)數(shù)值，或者iostat的輸出結(jié)果%util的值接近100%。說明磁盤已經(jīng)到達(dá)一個(gè)瓶頸。會(huì)影響壓測數(shù)據(jù)的準(zhǔn)確性。

2.3 網(wǎng)卡性能總結(jié)

我的網(wǎng)卡是千兆網(wǎng)卡，傳輸數(shù)據(jù)可以達(dá)到1000Mb/s，由于我們使用的單位都為MB/s。所以把Mb換算成MB。1000Mb/s=125MB/s。也就是說傳輸熟讀到達(dá)125MB/s的時(shí)候是網(wǎng)卡的瓶頸。會(huì)影響壓測數(shù)據(jù)的準(zhǔn)確性。

3 Kafka測試前期準(zhǔn)備

3.1 影響測試結(jié)果配置分析

Kafka的性能測試主要測試kafka的吞吐量，kafka吞性能為生產(chǎn)者在向kafka傳入消息時(shí)的寫入量，kafka的吐性能為消費(fèi)者在kafka集群中消費(fèi)的能力，也就是讀取量。

3.1.1 Borker相關(guān)

Kafka的borker是kafka集群的緩存代理，消息中間件處理結(jié)點(diǎn)，一個(gè)Kafka節(jié)點(diǎn)就是一個(gè)broker，多個(gè)broker可以組成一個(gè)Kafka集群。下面是相關(guān)broker的參數(shù)分析。

1、num.partiton

topic物理上的分組，一個(gè)topic可以分為多個(gè)partition，每個(gè)partition是一個(gè)有序的隊(duì)列。

Partition的數(shù)量選取也會(huì)直接影響到Kafka集群的吞吐性能。例如我們接口如果開了多個(gè)線程去消費(fèi)kafka的數(shù)據(jù)，當(dāng)Partition數(shù)量相對(duì)于流入流出的數(shù)據(jù)量顯得較少，或由于業(yè)務(wù)邏輯和Partition數(shù)量沒有匹配好造成個(gè)別Partition讀寫數(shù)據(jù)量大，大量的讀寫請(qǐng)求集中落在一臺(tái)或幾臺(tái)機(jī)器上時(shí)就會(huì)很影響效率。

2、Default.replication.factor

Replication參數(shù)為kafka集群副本數(shù)。這個(gè)參數(shù)決定了kafka的高可用性。也決定了kafka的吞吐量。此數(shù)據(jù)運(yùn)算和broker個(gè)數(shù)和broker上的分區(qū)數(shù)量都有關(guān)系。正常broker為3replication設(shè)置為1最好。因?yàn)?個(gè)節(jié)點(diǎn)的集群可以宕機(jī)一臺(tái)可以繼續(xù)工作，而3個(gè)replication可以保證宕機(jī)兩個(gè)節(jié)點(diǎn)正常工作。所以多replication會(huì)造成資源浪費(fèi)。如果數(shù)據(jù)不需要持久化和數(shù)據(jù)不重要并且寫入量特別大的話，可以考慮replication為0。

3、num.network.thread

用于接收并處理網(wǎng)絡(luò)請(qǐng)求的線程數(shù)，默認(rèn)為3。其內(nèi)部實(shí)現(xiàn)是采用Selector模型。啟動(dòng)一個(gè)線程作為Acceptor來負(fù)責(zé)建立連接，再配合啟動(dòng)num.network.threads個(gè)線程來輪流負(fù)責(zé)從Sockets里讀取請(qǐng)求，一般無需改動(dòng)，除非上下游并發(fā)請(qǐng)求量過大。

4、寫入數(shù)據(jù)每條大小

'{"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。所以我們測試基準(zhǔn)為200B和500B。

3.1.2 Consumer相關(guān)

Consumer為kafka的消費(fèi)者，同一個(gè)topic消費(fèi)者越多越快，但是需要注意的是，消費(fèi)者的數(shù)量不能超過topic的分區(qū)數(shù)量，因?yàn)槊總€(gè)topic的每個(gè)分區(qū)只能被一個(gè)消費(fèi)者消費(fèi)，多出來的消費(fèi)者會(huì)無信息可消費(fèi)。導(dǎo)致資源浪費(fèi)。

3.2 測試命令詳解

1、創(chuàng)建topic命令

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

--replication-factor：指定副本個(gè)數(shù)
--partitions：指定分區(qū)個(gè)數(shù)
--topic：指定topic名

2、查看topic命令

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

3、查看指定topic的詳細(xì)內(nèi)容

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

5、 寫入數(shù)據(jù)

# ./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：記錄的條數(shù)
--topic：指定topic的名字
--record-size：一條記錄大小。
--throughput：吞吐數(shù)量
--producer-props bootstrap.servers=IP:9092,IP:9092,IP:9092：指定kafka集群

注意：-- throughput參數(shù)為寫入數(shù)量，如果結(jié)果接近此數(shù)量，建議*10再測試一次。因?yàn)楹痛私Y(jié)果相近說明kafka沒有到達(dá)瓶頸。

6、消費(fèi)數(shù)據(jù)

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

--messages：指定消費(fèi)條目數(shù)
--threads：指定線程數(shù)
--num-fetch-threads 3：指定消費(fèi)人數(shù)

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

4 Kafka寫入性能測試

在測試kafka寫入性能測試的時(shí)候一邊檢測系統(tǒng)的cpu使用情況、內(nèi)存使用情況和磁盤IO情況。

4.1 測試kafka的partition參數(shù)

4.1.1 創(chuàng)建不同partition的topic并寫入數(shù)據(jù)1000萬條數(shù)據(jù)。

1、 創(chuàng)建一個(gè)副本，partition分別為1、3、6、12的topic分別為test-0、test-1、test-2、test-3

2、 向topic內(nèi)寫入1000萬條500B的數(shù)據(jù)，一次寫入100萬條，replication為1。并且開啟另一個(gè)窗口使用iostat命令實(shí)時(shí)監(jiān)控磁盤IO情況。

4.1.2 測試結(jié)果

1、寫入數(shù)據(jù)如下表

?

3、 磁盤IO情況

由于磁盤IO瓶頸在94.8 MB/秒得出的數(shù)據(jù)只有partition為1的情況下在60MB/秒。所以大多數(shù)情況下%util處于一個(gè)100%的狀態(tài)。在partition為1的情況下是隔兩秒會(huì)出現(xiàn)%util值為100%。

?

4.2 kafka的partition參數(shù)總結(jié)

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

在其他數(shù)據(jù)相同，而partition不同的時(shí)候。結(jié)論是partition越多寫入速度越快。但是partition數(shù)量越多會(huì)照成kafka集群可用性越差。所以建議，在實(shí)際生產(chǎn)環(huán)境。有多少個(gè)broker，partition數(shù)就為多少。這樣可以保證kafka集群的高可用性?？梢员ＷCn-1/2個(gè)節(jié)點(diǎn)宕機(jī)而不影響kafka集群使用。

4.3 測試Kafka的replication參數(shù)

4.3.1 創(chuàng)建不同replication的topic并寫入數(shù)據(jù)1000萬條數(shù)據(jù)。

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

2、向topic內(nèi)寫入1000萬條500B的數(shù)據(jù)，一次寫入100萬條，partition為3（因?yàn)槲业腷roker是3個(gè)）。并且開啟另一個(gè)窗口使用iostat命令實(shí)時(shí)監(jiān)控磁盤IO情況。

4.3.2 測試結(jié)果

1、寫入數(shù)據(jù)如下表

?

2、磁盤IO情況

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

?

4.4 kafka的replication參數(shù)總結(jié)

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

在其他數(shù)據(jù)相同，而replication不同的時(shí)候。結(jié)論是replication越少寫入速度越快。但是replication數(shù)量越少會(huì)照成kafka集群可用性越差。所以建議，在實(shí)際生產(chǎn)環(huán)境。Kafka集群broker為3的時(shí)候replication為1，可以保證一臺(tái)節(jié)點(diǎn)宕機(jī)集群可用。其他架構(gòu)需繼續(xù)深入研究。

4.5 測試Kafka的network.thread參數(shù)

1、 修改配置文件network.thread的參數(shù)為1，重啟kafka進(jìn)行對(duì)test-1進(jìn)行寫入測試。

2、 和之前test-1的數(shù)據(jù)進(jìn)行對(duì)比。

4.5.1 測試結(jié)果

1、寫入數(shù)據(jù)如下

?

2、磁盤IO情況

?

磁盤已經(jīng)到達(dá)瓶頸。

4.6 Kafka的network.thread參數(shù)總結(jié)

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

4.7 測試kafka的單條數(shù)據(jù)大小參數(shù)

1、 修改命令--record-size參數(shù)。

2、 同往test-1里寫入進(jìn)行測試

4.7.1 測試結(jié)果

1、寫入數(shù)據(jù)如下

?

2、磁盤IO情況

?

磁盤已經(jīng)到達(dá)瓶頸。

4.8 Kafka的單條數(shù)據(jù)大小參數(shù)總結(jié)

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

5 Kafka寫入數(shù)據(jù)測試整體總結(jié)

在kafka寫入數(shù)據(jù)的時(shí)候，主要參數(shù)在于partition的數(shù)量、replication的數(shù)量及單條數(shù)據(jù)的大小。對(duì)于線程數(shù)對(duì)寫入速度并不是特別影響。在測試的時(shí)候觀察cpu使用情況和內(nèi)存使用情況。Kafka在有寫入的時(shí)候?qū)τ诒旧淼膬?nèi)存要求不大，jvm設(shè)置為1G就可以，但是kafka機(jī)制是kafka先寫入系統(tǒng)頁緩存內(nèi)，所以需要的內(nèi)存比較大。不建議和使用內(nèi)存較大的應(yīng)用部署在一臺(tái)機(jī)器上，如elasticsearch。如果服務(wù)器內(nèi)存較大，建議kafka使用4G左右jvm。Kafka對(duì)cpu要求不是特別大。一般兩核以上就可以。

6 Kafka讀取性能測試

在測試kafka讀取性能測試的時(shí)候一邊檢測系統(tǒng)的cpu使用情況、內(nèi)存使用情況和磁盤IO情況。

注意事項(xiàng)：寫入數(shù)據(jù)后等一段時(shí)間再進(jìn)行測試，因?yàn)榭赡苡行?shù)據(jù)還在內(nèi)存中，所以看不出磁盤IO的瓶頸。

6.1 測試kafka的partition參數(shù)

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

6.1.1 測試結(jié)果

1、讀取數(shù)據(jù)如下表

?

2、磁盤IO情況

磁盤IO有時(shí)會(huì)到達(dá)瓶頸，但是次數(shù)不多。

?

6.2 Kafka的partition參數(shù)總結(jié)

壓測結(jié)果證明partition越多速度越快，實(shí)際情況我們建議和之前一樣。有多少個(gè)broker，partition數(shù)就為多少。這樣可以保證kafka集群的高可用性。可以保證n-1/2個(gè)節(jié)點(diǎn)宕機(jī)而不影響kafka集群使用。詳細(xì)情況kafka寫入測試的partition總結(jié)。

6.3 測試Kafka的consumer參數(shù)

以test1為測試topic。分別使用1、3、6個(gè)consumer來進(jìn)行讀取測試。

6.3.1 測試結(jié)果

1、寫入數(shù)據(jù)如下表

?

2、磁盤IO情況

磁盤IO有時(shí)會(huì)到達(dá)瓶頸，但是次數(shù)不多。

?

3、 使用軟件KafkaOffsetMonitor監(jiān)控不同consumer的滯留情況lag為滯留信息條目數(shù)

（1）一個(gè)consumer三個(gè)partition

?

（2）三個(gè)consumer三個(gè)partition

?

（3）三個(gè)consumer六個(gè)partition

?

6.4 kafka的consumer參數(shù)總結(jié)

從測試結(jié)果可以看出，consumer這個(gè)參數(shù)不是越多越好，而是和topic的partition相同時(shí)性能最優(yōu)，如果consumer大于partition的時(shí)候，測試開始會(huì)報(bào)錯(cuò)，內(nèi)容大意為，有xx個(gè)consumer是沒有分區(qū)可以消費(fèi)的。這個(gè)參數(shù)可以根據(jù)項(xiàng)目本身去定義。但是不要超過topic的partition數(shù)目。但是consumer少會(huì)有消息滯留現(xiàn)象。

6.5 測試Kafka的線程參數(shù)

通過test-1 topic進(jìn)行測試。

6.5.1 測試結(jié)果

1、 寫入數(shù)據(jù)如下表

?

2、 磁盤IO

?

6.6 kafka的線程參數(shù)總結(jié)

從測試結(jié)果來看線程數(shù)并不影響kafka的寫入速度。

7 Kafka讀取性能總結(jié)

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

Kafka讀取對(duì)于replication無關(guān)，因?yàn)閞eplication不參與讀取，只做容災(zāi)備份的。對(duì)線程數(shù)也沒那么大的關(guān)系。

讀取數(shù)據(jù)對(duì)cpu負(fù)載不是特別高，2核以上夠用，如果是實(shí)時(shí)讀取數(shù)據(jù)，對(duì)磁盤來說性能要求并不高，因?yàn)槎虝r(shí)間內(nèi)，一些數(shù)據(jù)都是在內(nèi)存里可以直接取到的。

8 Kafka整體性能總結(jié)

對(duì)于ELK集群來說，整體性能還是比較好的，一般影響測試結(jié)果都是磁盤的瓶頸造成的。對(duì)于磁盤來說用SATA磁盤就可以，因?yàn)閗afka的寫入讀取機(jī)制都是順序?qū)懭?、讀取的。SATA順序讀寫速度大約在53MB/s和SSD的順序讀取都是差不多的。如果做RAID建議做RAID5。

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

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

但是以上數(shù)據(jù)幾乎都是遇到了磁盤IO的瓶頸，數(shù)據(jù)不是特別準(zhǔn)確，希望可以有更好的環(huán)境，對(duì)kafka進(jìn)行更全面的測試。

最后貼上整體數(shù)據(jù)

生產(chǎn)

?

消費(fèi)


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

與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。