kafka性能調(diào)優(yōu)解密（一）-- Broker端

Broker篇

1????? 網(wǎng)絡(luò)模型3個相關(guān)參數(shù)

參數(shù)

默認值

推薦值

說明

num.network.threads

3

默認值

server用來處理網(wǎng)絡(luò)請求的網(wǎng)絡(luò)線程數(shù)目；一般你不需要更改這個屬性。

num.io.threads

8

默認值

server用來處理請求的I/O線程的數(shù)目；這個線程數(shù)目至少要等于硬盤的個數(shù)。

queued.max.requests

500

默認值

在網(wǎng)絡(luò)線程停止讀取新請求之前，可以排隊等待I/O線程處理的最大請求個數(shù)。

Kafka的內(nèi)部結(jié)構(gòu)圖如下：

Kafka的內(nèi)部結(jié)構(gòu)圖如下：

其中num.network.threads是控制上圖中的Processor Thread的個數(shù)， num.io.threads是控制API Thread的個數(shù)，queued.max_requests是控制Request Channel隊列的容量。

1.? 調(diào)大num.network.threads能夠增加處理網(wǎng)絡(luò)io請求，但不讀寫具體數(shù)據(jù)，基本沒有io等待。但如果過大，會帶來線程切換的開銷。

2.????增大queued.max.requests能夠緩存更多的請求，以撐過業(yè)務(wù)峰值。如果過大，會造成內(nèi)存的浪費。

3.????增大num.io.threads能提升線程處理能力，如果過大會代理線程切換開銷影響處理能力。同時至少要等于硬盤的個數(shù)。

num.network.threads、num.io.threads和queued.max.requests 這三個參數(shù)是kafka網(wǎng)絡(luò)模型的相關(guān)參數(shù)，所以這里一起測試。?模擬一定的壓力，使得API threads線程處理不過來，request channel隊列阻塞，性能開始下降。此時增大queue.max.requests或者增加API threads，查看性能情況

1G網(wǎng)卡下，10分區(qū)，2k數(shù)據(jù)，發(fā)送1000000, ack都為1, 3個Producer與3個Consumer一起跑, Consumer每次從隊列開始讀取數(shù)據(jù)

測試數(shù)據(jù)如下：

num.network.threads

num.io.threads

queued.max.requests

Producer

nMsg.sec

Consumer

nMsg.sec

3

8

1

48768.5443

48985.088

3

8

250

50942.3841

52804.523

3

8

500

51303.0474

55146.401

3

8

1000

51956.0971

54461.271

3

1

1

50699.6045

48399.7216

從queued.max.requests值由1增加到1000，可以看出通過調(diào)大queue個數(shù)，性能可以稍稍提高6%左右

修改num.io.threads個數(shù)，性能影響不大。

10G網(wǎng)卡 下，100分區(qū)，2k數(shù)據(jù)，發(fā)送1000000, ack都為1, 10個Producer與10個Consumer一起跑, Consumer每次從隊列開始讀取數(shù)據(jù)，Producer BatchSize 為512M

num.network.threads

num.io.threads

queued.max.requests

Producer

nMsg.sec

Consumer

nMsg.sec

3

8

1

203500.2035

139385.4383

3

8

1000

228206.2985

139567.3412

50

8

1

187441.4246

137869.9555

50

8

1000

229042.6019

151199.0081

取queued.max.requests的極端情況分別為1和1000，在不同的壓力下， Producer性能能提升10%。 如果把num.network.threads調(diào)大，這兩者的差距就更大達到22%

從數(shù)據(jù)得到的結(jié)論：

1.從上面的測試來看，3個線程的壓力下，就算queued.max.requests設(shè)置為1，broker也能很快處理，不會造成性能劇烈下降。

2.10G 網(wǎng)卡下， queued.max.requests設(shè)置為1 與設(shè)置為1000比較，能提升22%。

3.按照目前的壓力來看，用默認值就可以滿足業(yè)務(wù)要求，發(fā)現(xiàn)性能瓶頸可以調(diào)大這三個參數(shù)就可以。

2 復(fù)制3個相關(guān)參數(shù)

2.1??????參數(shù)描述

參數(shù)

默認值

推薦值

說明

replica.socket.receive.buffer.bytes

64*1024

256k~2M

備份時向leader發(fā)送網(wǎng)絡(luò)請求時的socket receive buffer

replica.fetch.max.bytes

1024*1024

根據(jù)業(yè)務(wù)實際配置

備份時每次fetch的最大值

num.replica.fetchers

1

默認值

從leader備份數(shù)據(jù)的線程數(shù)

1.replica.socket.receive.buffer.bytes： 同TCP buffer的分析，不少于BDP 窗口大小，時延高的可以設(shè)大一點2.replica.fetch.max.bytes:? 不得少于發(fā)往broker消息的最大長度（message.max.bytes），需要根據(jù)業(yè)務(wù)實際消息的大小，然后設(shè)大一點即可。

3. num.replica.fetchers： 復(fù)制fetch線程設(shè)置大一點可以提升獲取性能，同時增加備機的IO并行性，但設(shè)置太大也沒用反而導(dǎo)致空閑，這個同Consumer的fetch thread一樣。

在ACK=1的情況下，Produce/Consumer的性能與復(fù)制關(guān)系不是很大，除非受到網(wǎng)絡(luò)的瓶頸。

2個broker 創(chuàng)建10個分區(qū)的topic，?一定的壓力下，通過調(diào)整這3個參數(shù)，檢查性能的變化

單獨調(diào)大receiver buffer參數(shù)：

replica.socket.receive.buffer.bytes

replica.fetch.max.bytes s

num.replica.fetchers

Producer

nMsg.sec

Consumer

nMsg.sec

65536

1048576

1

141602.9453

140684.5711

262144

1048576

1

143843.5

136843.83

2097152

1048576

1

143287

141113.38

單獨調(diào)大rep_fetch_max_bytes:

replica.socket.receive.buffer.bytes

replica.fetch.max.bytes s

num.replica.fetchers

Producer

nMsg.sec

Consumer

nMsg.sec

65536

1048576

1

141602.9453

140684.5711

65536

4194304

1

163345.312

129623.2285

65536

8388608

1

148170.0993

143096.3181

單獨調(diào)大num.replica.fetchers:

replica.socket.receive.buffer.bytes

replica.fetch.max.bytes s

num.replica.fetchers

Producer

nMsg.sec

Consumer

nMsg.sec

65536

1048576

1

141602.9453

140684.5711

65536

1048576

5

161733.7862

142486.6775

65536

1048576

10

150330.7276

137249.5196

分析結(jié)論

1.?????? 單獨調(diào)這些參數(shù)，性能并沒用發(fā)生比較大的變化，因為正常測試存在波動

2.?????? replica.socket.receive.buffer.bytes?? 跟Consumer的 socket.receiver.buffer.bytes 盡量一致就可以

3.?????? replica.fetch.max.bytes 根據(jù)業(yè)務(wù)最大消息來配置，稍微大一點就可以了

4.?????? num.replica.fetchers? 默認1個線程就足夠了，否則復(fù)制會比較占網(wǎng)絡(luò)流量

3????? TCP相關(guān)參數(shù)

原理分析和理論指導(dǎo)值同Producer端的TCP參數(shù)。具體參考下篇producer端

應(yīng)用性能調(diào)優(yōu) Kafka

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。