kafka性能调优解密（一）-- Broker端

Broker篇

1      网络模型3个相关参数

参数

默认值

推荐值

说明

num.network.threads

3

默认值

server用来处理网络请求的网络线程数目；一般你不需要更改这个属性。

num.io.threads

8

默认值

server用来处理请求的I/O线程的数目；这个线程数目至少要等于硬盘的个数。

queued.max.requests

500

默认值

在网络线程停止读取新请求之前，可以排队等待I/O线程处理的最大请求个数。

Kafka的内部结构图如下：

Kafka的内部结构图如下：

其中num.network.threads是控制上图中的Processor Thread的个数， num.io.threads是控制API Thread的个数，queued.max_requests是控制Request Channel队列的容量。

1.  调大num.network.threads能够增加处理网络io请求，但不读写具体数据，基本没有io等待。但如果过大，会带来线程切换的开销。

2.    增大queued.max.requests能够缓存更多的请求，以撑过业务峰值。如果过大，会造成内存的浪费。

3.    增大num.io.threads能提升线程处理能力，如果过大会代理线程切换开销影响处理能力。同时至少要等于硬盘的个数。

num.network.threads、num.io.threads和queued.max.requests 这三个参数是kafka网络模型的相关参数，所以这里一起测试。 模拟一定的压力，使得API threads线程处理不过来，request channel队列阻塞，性能开始下降。此时增大queue.max.requests或者增加API threads，查看性能情况

1G网卡下，10分区，2k数据，发送1000000, ack都为1, 3个Producer与3个Consumer一起跑, Consumer每次从队列开始读取数据

测试数据如下：

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，可以看出通过调大queue个数，性能可以稍稍提高6%左右

修改num.io.threads个数，性能影响不大。

10G网卡 下，100分区，2k数据，发送1000000, ack都为1, 10个Producer与10个Consumer一起跑, Consumer每次从队列开始读取数据，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调大，这两者的差距就更大达到22%

从数据得到的结论：

1.从上面的测试来看，3个线程的压力下，就算queued.max.requests设置为1，broker也能很快处理，不会造成性能剧烈下降。

2.10G 网卡下， queued.max.requests设置为1 与设置为1000比较，能提升22%。

3.按照目前的压力来看，用默认值就可以满足业务要求，发现性能瓶颈可以调大这三个参数就可以。

2 复制3个相关参数

2.1      参数描述

参数

默认值

推荐值

说明

replica.socket.receive.buffer.bytes

64*1024

256k~2M

备份时向leader发送网络请求时的socket receive buffer

replica.fetch.max.bytes

1024*1024

根据业务实际配置

备份时每次fetch的最大值

num.replica.fetchers

1

默认值

从leader备份数据的线程数

1.replica.socket.receive.buffer.bytes： 同TCP buffer的分析，不少于BDP 窗口大小，时延高的可以设大一点2.replica.fetch.max.bytes:  不得少于发往broker消息的最大长度（message.max.bytes），需要根据业务实际消息的大小，然后设大一点即可。

3. num.replica.fetchers： 复制fetch线程设置大一点可以提升获取性能，同时增加备机的IO并行性，但设置太大也没用反而导致空闲，这个同Consumer的fetch thread一样。

在ACK=1的情况下，Produce/Consumer的性能与复制关系不是很大，除非受到网络的瓶颈。

2个broker 创建10个分区的topic， 一定的压力下，通过调整这3个参数，检查性能的变化

单独调大receiver buffer参数：

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

单独调大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

单独调大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

分析结论

1.       单独调这些参数，性能并没用发生比较大的变化，因为正常测试存在波动

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

3.       replica.fetch.max.bytes 根据业务最大消息来配置，稍微大一点就可以了

4.       num.replica.fetchers  默认1个线程就足够了，否则复制会比较占网络流量

3      TCP相关参数

原理分析和理论指导值同Producer端的TCP参数。具体参考下篇producer端

应用性能调优 Kafka

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。