kafka性能調優(yōu)解密（二）-- Producer端

Producer篇

1? acks

Ack為0的時候應該性能最優(yōu)，但沒有可靠性保證；

Ack為1的時候只保證leader已經(jīng)把數(shù)據(jù)寫入，但沒有確保各個副本已經(jīng)寫入，如果此時leader所在broker宕機，會丟失數(shù)據(jù)。

Ack為-1的時候，會保證所有的in-sync副本都寫入成功才返回。這個參數(shù)性能最差，但可靠性是最高的

1.在2個機器分別部署2個broker，創(chuàng)建10個分區(qū)的topic

2.客戶端在另一個機器上進行發(fā)送消息測試。 通過修改消息長度和ACK不同的值，檢查ack對性能的影響。

1G網(wǎng)卡下，采用New Producer共發(fā)1000000條，batch.size為16k。

Ack

message.sizes

MB.sec

nMsg.sec

性能下降比

0

2048

88.4087

45265.2544

/

1

2048

67.4981

34559.0268

0.236522

-1

2048

20.8556

10678.0566

0.7641

0

4096

85.8007

21964.9878

/

1

4096

74.745

19134.7276

0.128853

-1

4096

19.0526

4877.4778

0.777943

0

8192

87.1386

11153.7432

/

1

8192

54.1993

6937.5069

0.378011

-1

8192

15.3464

1964.3394

0.823885

可以看出性能結果和原理分析中的結論是一致的，ack為0的時候最好，1次之，-1最差。

從測試數(shù)據(jù)中可以得到如下結論：

隨著ACK的值增多，在集群中性能會下降，但消息可靠性增強，對可靠性和性能都要有要求的，推薦ack設置為1，這個也是默認值；業(yè)務允許節(jié)點異常時丟失少量數(shù)據(jù)，并且對性能要求很高的，可以用0。

2? batch.size

參數(shù)

默認值

推薦值

說明

batch.size

16384

524288

producer將試圖批處理消息記錄，以減少請求次數(shù)。這將改善client與server之間的性能。這項配置控制默認的批量處理消息字節(jié)數(shù)。

不會試圖處理大于這個字節(jié)數(shù)的消息字節(jié)數(shù)。

發(fā)送到brokers的請求將包含多個批量處理，其中會包含對每個partition的一個請求。

較小的批量處理數(shù)值比較少用，并且可能降低吞吐量（0則會僅用批量處理）。較大的批量處理數(shù)值將會浪費更多內存空間，這樣就需要分配特定批量處理數(shù)值的內存大小。

Producer創(chuàng)建一個BufferPool，totalSize為buffer.memory， 在這個pool里創(chuàng)建很多batch，每個batch大小就是batch.size。這個值越大，可以有效減少tcp傳輸次數(shù)。但是也不是越大越好，會造成內存浪費，因為linger.ms配置成0則會不等待batch.size裝滿就馬上發(fā)送，導致每次發(fā)送batch buffer里有空閑；同時如果不夠內存，會被block住影響性能

1.?在2個機器分別部署2個broker，客戶端在另一個機器上進行發(fā)送消息測試。 通過修改batch.size的值，檢查這個參數(shù)對性能的影響。

2. 創(chuàng)建一個10個分區(qū)的topic

10G網(wǎng)卡下，2k數(shù)據(jù)，共發(fā)1000000條，線程數(shù)為10個

Batch.size為512k的時候，磁盤IO監(jiān)控圖為：

可以看出此時sda這一塊盤的使用已達100%

10G網(wǎng)卡下，4k數(shù)據(jù)，共發(fā)1000000條，線程數(shù)為10個

Batch.size為512k的時候，磁盤IO監(jiān)控圖為：

分析結論：

1.從2k和4k的測試結果來看，峰值都出現(xiàn)在512k batch_size中。 此時查看磁盤，發(fā)現(xiàn)util 已經(jīng)達到100%，磁盤成為瓶頸

2.batch_size過大，除了空間浪費外，還會導致BufferPool中可用的batch過少，導致發(fā)送速度快的時候分配內存不足的情況發(fā)生概率增大，發(fā)生被卡住

3? buffer.memory

參數(shù)

默認值

推薦值

說明

buffer.memory

33554432

128M~1G

producer可以用來緩存數(shù)據(jù)的內存大小。如果數(shù)據(jù)產(chǎn)生速度大于向broker發(fā)送的速度，producer會阻塞或者拋出異常，以“block.on.buffer.full”來表明。

這項設置將和producer能夠使用的總內存相關，但并不是一個硬性的限制，因為不是producer使用的所有內存都是用于緩存。一些額外的內存會用于壓縮（如果引入壓縮機制），同樣還有一些用于維護請求。

Producer對象創(chuàng)建BufferPool指定的內存大小，如果這個值設置的過小，會導致內存分配不足，在block.on.buffer.full為TRUE的情況下就會阻塞發(fā)送影響性能。設置過大的話會導致浪費內存

1. 2個broker的場景下，創(chuàng)建10個分區(qū)的topic

2. 通過固定batch size，然后調大 buffer.memory，查看tps的變化

10G網(wǎng)卡下，2k數(shù)據(jù)，共發(fā)1000000條，線程數(shù)為10個，batchsize為512k

10G網(wǎng)卡下2k數(shù)據(jù)，共發(fā)1000000條，線程數(shù)為10個，batchsize為256k

可以看出buffer.memory設置過少，會導致tps很低，只有3w多；但設置很大，tps也不能一直提升。

分析結論：

1.?????? buffer.memory 調的過小對性能會影響很大，因為內存不足就會導致發(fā)送被block（block.on.buffer.full為TRUE）

2.?????? 設置過大的buffer.memory對性能提高幫助不是很大，只要夠用就好。 可以根據(jù)batch size比默認值提高多少倍，而相應提高buffer.memory多少倍即可

4? send.buffer.bytes

參數(shù)

默認值

推薦值

說明

send.buffer.bytes

131072

默認值或者略大于帶寬*時延

TCP send緩存大小，當發(fā)送數(shù)據(jù)時使用

TCP窗口

1、接收窗口

1）泛指接收緩沖區(qū)的大小。

2）接收緩沖區(qū)能夠接收的數(shù)據(jù)字節(jié)數(shù)（接收緩沖區(qū)空出的字節(jié)數(shù)），實質上就是接收緩沖區(qū)的大小減去未送往應用層數(shù)據(jù)部分。又稱為通告窗口。

2、發(fā)送窗口

1）泛指發(fā)送緩沖區(qū)的大小。

2）可發(fā)送的數(shù)據(jù)就處于發(fā)送窗口中，發(fā)送窗口大小指的就是可發(fā)送的數(shù)據(jù)量。

BDP：Bandwidth Delay Product，即帶寬時延乘積。

BDP=帶寬×時延

帶寬：是指瓶頸帶寬，無線網(wǎng)絡中一般空口是瓶頸，因此對應空口帶寬。

時延：是指系統(tǒng)的環(huán)回時長RTT0，即：TCP

發(fā)出一個數(shù)據(jù)包到收到對應ACK的時長，約

等于PING環(huán)回時長。

在TCP序號－時間圖上，以帶寬為斜率畫一個直角三角形，其斜邊的斜率等于帶寬，水平直角邊的長度等于時延RTT0，則垂直直角邊的長度就等于BDP。

1.?????? TCP窗口< BDP

受限于TCP窗口大小，TCP速率達不到帶寬。

TCP穩(wěn)態(tài)速率=TCP窗口/RTT0

TCP穩(wěn)態(tài)速率隨著TCP窗口的增大而增大，直至TCP窗口=BDP。

2.?????? TCP窗口= BDP

TCP穩(wěn)態(tài)速率＝瓶頸帶寬。

3.?????? TCP窗口> BDP

當TCP窗口>BDP時，TCP穩(wěn)態(tài)速率會不會進一步增大而超過瓶頸帶寬呢？當然不會，速率還是會穩(wěn)定在瓶頸帶寬。

那會帶來什么影響呢？ RTT的增大！

RTT=TCP窗口/帶寬

原則如下：

1、發(fā)送緩沖區(qū)和接收緩沖區(qū)的大小一般設置為相同的值。

2、緩沖區(qū)的大小一般設置為略大于BDP。

TCP緩沖區(qū)設置過大越大越好嗎？

緩沖區(qū)設置過大會導致RTT增加，帶來兩個弊端：

1）丟包重傳時速率恢復會變慢，因為重傳包也會在緩沖區(qū)中排隊發(fā)送。

2）會導致RTT測量變得遲鈍，無法跟上系統(tǒng)時延的變化，造成無謂的重傳或重傳不及時。

1.?? 2個broker 創(chuàng)建10個分區(qū)的topic

2.?? 在上面batch_size最好為512k 和 默認值的情況下，調整send.buffer.bytes，查看性能

10G網(wǎng)卡下，2k數(shù)據(jù)，共發(fā)1000000條，線程數(shù)為10個，batchsize為16k, buffer.memory為32M

10G網(wǎng)卡下，2k數(shù)據(jù)，共發(fā)1000000條，線程數(shù)為10個，batchsize為512k, buffer.memory為1024M

其中實測時延為0.032ms，帶寬為10G，那么：

BDP = 10G * 0.032ms = 337k

從上面的測試可以看出128k~512k的send buffer，性能已經(jīng)在峰值附近

結論：

1. send buffer采用默認值與broker 的receiver buffer默認值（100k）相對，性能在這個場景下是峰值

2.? 可以根據(jù)BDP的計算公式，然后配置send buffer與receiver buffer略大于BDP大小

5.? receive.buffer.bytes

參數(shù)

默認值

推薦值

說明

receive.buffer.bytes

32768

默認值

TCP receive緩存大小，當閱讀數(shù)據(jù)時使用

生產(chǎn)者的Receiver buffer 一般對生產(chǎn)者影響不是很大，因為只有響應信息返回。

1. 2個broker 創(chuàng)建10個分區(qū)的topic

2.? 在上面batch_size最好為512k 和 默認值的情況下，調整receive.buffer.bytes，查看性能

10G網(wǎng)卡下，2k數(shù)據(jù)，共發(fā)1000000條，線程數(shù)為10個，batchsize為512k, bufferMem為32M, send.buffer為128k

結論：

與理論分析差不多，設置比較小對性能也影響不大，采用默認值即可

緩存 應用性能調優(yōu) Kafka 存儲

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