一.硬件配置
3台服务器配置如下:
CPU: 2物理CPU，12核/CPU , 48 processor Intel(R) Xeon(R) Silver 4116 CPU @ 2.10GHz
内存: 128GB
硬盘: 480GB*1 SSD盘(OS)+6TB*7 SAS盘
Broker节点数: 3个
网络：10GE
二.测试方案
2.1 测试套件
使用kafka官方提供的性能测试工具 kafka-perf-test
1)producer命令
| ./kafka-producer-perf-test.sh --producer-props bootstrap.servers="vm14:6667,vm15:6667,vm16:6667" --topic test-perf-1-1 --num-records 1000000 --record-size 512 --throughput 1000000 --topic TOPIC produce messages to this topic --num-records NUM-RECORDS nuMBer of messages to produce --payload-delimiter PAYLOAD-DELIMITER provides delimiter to be used when --payload-file is provided. Defaults to new line. Note that this parameter will be ignored if --payload-file is not provided. (default: \n) --throughput THROUGHPUT throttle maximum message throughput to *approximately* THROUGHPUT messages/sec --producer-props PROP-NAME=PROP-VALUE [PROP-NAME=PROP-VALUE ...] kafka producer related configuration properties like bootstrap.servers,client.id etc. These configs take precedence over those passed via --producer.config. --producer.config CONFIG-FILE producer config properties file. --print-metrics print out metrics at the end of the test. (default: false) --transactional-id TRANSACTIONAL-ID The transactionalId to use if transaction-duration-ms is > 0. Useful when testing the performance of concurrent transactions. (default: performance-producer- default-transactional-id) --transaction-duration-ms TRANSACTION-DURATION The max age of each transaction. The commitTransaction will be called after this time has elapsed. Transactions are only enabled if this value is positive. (default: 0) either --record-size or --payload-file must be specified but not both. --record-size RECORD-SIZE message size in bytes. Note that you must provide exactly one of --record-size or --payload-file. --payload-file PAYLOAD-FILE file to read the message payloads from. This works only for UTF-8 encoded text files. Payloads will be read from this file and a payload will be randomly selected when sending messages. Note that you must provide exactly one of --record-size or --payload-file. |
2)consumer命令
| ./kafka-consumer-perf-test.sh --broker-list "vm14:6667,vm15:6667,vm16:6667" --topic test-perf-1-1 --fetch-size 1000000 --messages 1000000 --threads 1 --broker-list <String: host> REQUIRED: The server(s) to connect to. --consumer.config <String: config file> Consumer config properties file. --date-format <String: date format> The date format to use for formatting the time field. See java.text. SimpleDateFormat for options. (default: yyyy-MM-dd HH:mm:ss:SSS) --fetch-size <Integer: size> The amount of data to fetch in a single request. (default: 1048576) --from-latest If the consumer does not already have an established offset to consume from, start with the latest message present in the log rather than the earliest message. --group <String: gid> The group id to consume on. (default: perf-consumer-61359) --help Print usage. --hide-header If set, skips printing the header for the stats --messages <Long: count> REQUIRED: The nuMBer of messages to send or consume --num-fetch-threads <Integer: count> NuMBer of fetcher threads. (default: 1) --print-metrics Print out the metrics. --reporting-interval <Integer: Interval in milliseconds at which to interval_ms> print progress info. (default: 5000) --show-detailed-stats If set, stats are reported for each reporting interval as configured by reporting-interval --socket-buffer-size <Integer: size> The size of the tcp RECV size. (default: 2097152) --threads <Integer: count> NuMBer of processing threads. (default: 10) --timeout [Long: milliseconds] The maximum allowed time in milliseconds between returned records. (default: 10000) --topic <String: topic> REQUIRED: The topic to consume from. |
2.2 Producer测试方案
第一组：测试单磁盘情况下topic的paritition数量变化对写入速度的影响
思路:partition数量对应的是producer的并行写入kafka的数量，通过本用例可以观察单磁盘情况下partition的增加是否对写入速度产生影响。
1 broker, 1 disks, 1 replication, record-size 512, records 10000000, throughput 1000000
| partition |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 1 |
115107.9137 |
56.21 |
546.61 |
744 |
| 3 |
152898.1851 |
74.66 |
410.3 |
647 |
| 5 |
172286.0638 |
84.12 |
363.76 |
647 |
| 7 |
196900.7817 |
96.14 |
316.89 |
587 |
| 9 |
191398.5492 |
93.46 |
325.96 |
582 |
结论：通过测试在单个节点单个磁盘不同数量partition下的写入速度，可以看出当在一定范围内（本例中为1-7）随着partition数量增加，写入速度会增加，超过极值点（本例中为7）后有下降趋势
第二组：测试磁盘增加对写入速度的影响
思路:磁盘数量对应kafka的服务端接收到producer的消息后，处理写入的并行数，一般会配置kafka的io.threads数量和磁盘的数量相等。通过本用例可以观察磁盘增加是否对写入速度产生影响。
1 broker, 5 partition, 1 replication, record-size 512, records 10000000, throughput 1000000
| disks |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 2 |
147303.6075 |
71.93 |
425.62 |
869 |
| 4 |
147331.8207 |
71.94 |
425.91 |
861 |
| 7 |
173391.3616 |
84.66 |
361.04 |
716 |
1 broker, 10 partition, 1 replication, record-size 512, records 10000000, throughput 1000000
| disks |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 2 |
174012.9118 |
84.97 |
359.21 |
610 |
| 4 |
188253.012 |
91.92 |
331.02 |
755 |
| 7 |
212075.5837 |
103.55 |
293.08 |
532 |
1 broker, 15 partition, 1 replication, record-size 512, records 10000000, throughput 1000000
| disks |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 2 |
177154.195 |
86.5 |
352.47 |
606 |
| 4 |
192126.6499 |
93.81 |
324.63 |
671 |
| 7 |
209784.3417 |
102.43 |
297.05 |
605 |
1 broker, 20 partition, 1 replication, record-size 512, records 10000000, throughput 1000000
| disks |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 2 |
172532.7812 |
84.24 |
361.79 |
621 |
| 4 |
192481.6661 |
93.99 |
323.99 |
613 |
| 7 |
214174.0378 |
104.58 |
289.85 |
755 |
结论：通过测试在单节点下挂载2块，4块，7块硬盘时的写入速度，分别在partition数量为5，10，15，20的情况下进行测试，可以看出不同partition数量时当硬盘数量增多时，写入速度都会增加，但是增量都不是特别显著，猜测是由于单个进程producer造成的写入速度瓶颈。
第三组：测试磁盘和parition数量关系对写入速度的影响
思路:当kafka在新建一个partition时，会选择所有kafka服务器中partition数量最少的目录来新建。单个topic的所有partition是均匀分布在服务器中的各个目录的，最好的情况下，将topic的partition均匀分配在不同的磁盘中可以最大化提升并行写入和读取的速度。另外，当paritition数量是磁盘数量的整数倍的时候，可以保证partition在磁盘中的均匀分布，当不成整数倍的时候，不能保证partition的均匀分布。
通过本用例可以观察磁盘和paritition的数量变化对性能的影响，以及磁盘和partition的数量对应的倍数关系是否对写入性能有影响。
1 broker, 2 disks, 1 replication, record-size 512, records 10000000, throughput 1000000
| partition |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 2 |
109996.4801 |
53.71 |
572.67 |
2578 |
| 4 |
174926.0937 |
85.41 |
358.69 |
826 |
| 8 |
193569.6173 |
94.52 |
323.65 |
740 |
| 16 |
220891.9617 |
107.86 |
282.22 |
418 |
| 32 |
183046.2558 |
89.38 |
341.95 |
1839 |
| 补充组 |
||||
| 12 |
210194.4298 |
102.63 |
296.18 |
520 |
| 14 |
205090.3423 |
100.14 |
304.13 |
572 |
| 16 |
220891.9617 |
107.86 |
282.22 |
418 |
| 18 |
203417.4125 |
99.32 |
304.77 |
602 |
| 20 |
189530.3438 |
92.54 |
329.59 |
684 |
测试2块硬盘时partition数量成倍增加时写入速度的变化，先以大步长进行测试，找到大致的极值范围，再缩小步长进行测试，最佳点大致在partition=16左右
1 broker, 4 disks, 1 replication, record-size 512, records 10000000, throughput 1000000
| partition |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 4 |
145342.4996 |
70.97 |
431.95 |
647 |
| 8 |
171004.4803 |
83.5 |
367.04 |
923 |
| 16 |
182328.7022 |
89.03 |
343.28 |
769 |
| 32 |
186863.4962 |
91.24 |
333.92 |
753 |
| 64 |
183705.3366 |
89.7 |
339.13 |
847 |
| 补充组 |
||||
| 18 |
195809.673 |
95.61 |
317.23 |
736 |
| 20 |
195182.8864 |
95.3 |
319.75 |
978 |
| 22 |
189243.4049 |
92.4 |
329.94 |
817 |
| 24 |
187230.8556 |
91.42 |
332.49 |
857 |
| 28 |
182969.2246 |
89.34 |
341.24 |
1602 |
测试4块硬盘时partition数量成倍增加时写入速度的变化，先以大步长进行测试，找到大致的极值范围，再缩小步长进行测试，最佳点大致在partition=20左右
1 broker, 7 disks, 1 replication, record-size 512, records 10000000, throughput 1000000
| partition |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 7 |
164972.9444 |
80.55 |
379.46 |
580 |
| 14 |
187747.5921 |
91.67 |
333.13 |
841 |
| 28 |
186198.9349 |
90.92 |
334.86 |
765 |
| 56 |
171812.4495 |
83.89 |
358.76 |
1313 |
| 补充组 |
||||
| 16 |
199632.6759 |
97.48 |
313.02 |
830 |
| 18 |
188786.1053 |
92.18 |
329.63 |
994 |
| 20 |
191769.2632 |
93.64 |
324.96 |
776 |
测试7块硬盘时partition数量成倍增加时写入速度的变化，先以大步长进行测试，找到大致的极值范围，再缩小步长进行测试，最佳点大致在partition=16左右
结论：通过测试不同磁盘数量，不同partition数量的情况下写入速度的变化，可以看出磁盘和partition的数量对应的倍数关系对写入速度的影响不大。
第四组：测试单条消息大小的影响：
思路: 由于处理单条消息额外的性能消耗，单条消息的大小可能会对性能产生影响。可以推测:随着消息大小变大，吞吐量增加，每秒处理的消息条数逐渐变少。通过本用例可以观察单条消息大小对性能的影响。
3 broker, 7 disks, 1 replication, 48 partition, records 10000000, throughput 1000000
| record-size |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 128 |
897988.5057 |
109.62 |
11.64 |
253 |
| 256 |
798594.4737 |
194.97 |
63.54 |
324 |
| 512 |
425170.068 |
207.6 |
136.19 |
1123 |
| 1024 |
227019.9096 |
221.7 |
129.93 |
990 |
| 2048 |
107975.0362 |
210.89 |
128.92 |
873 |
结论：通过测试在3个节点挂载7块硬盘时单条消息大小分别为128，256，512，1024，2048的情况下测试写入速度，可以看出当单条消息由128增大到256时每秒消息条数略有下降，写入速度几乎成倍增加，再成倍增大时相应的每秒消息条数也几乎成倍减少，写入速度略有增大，增大到2048时不增反降，因此单条消息大小为256时即可以保持较高的写入速度，又可以保持每秒传输的消息数量较多，单条消息大小不应该超过1024。
第五组：测试副本数对写入性能的影响：
思路: 为了保证可靠性，一般会存多副本，但是副本的增加可能会降低kafka的写入性能，通过本用例可以观察副本数对kafka的写入性能的影响。
3 broker, 1 disks, 21 partition, record-size 512, records 10000000, throughput 1000000
| replication |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 1 |
422243.8036 |
206.17 |
143.41 |
541 |
| 2 |
409701.7371 |
200.05 |
148.78 |
523 |
| 3 |
406702.4565 |
198.59 |
148.98 |
927 |
结论：通过测试在3个节点挂载单块硬盘时，21partition，副本数量分别为1，2，3时的写入速度，可以看出当副本增加时写入速度略有下降，但不明显，差别很微小，这里猜测是由于cpu和网络并没有完全跑满，有富余的能力处理额外的副本。
* 补充：测试多进程producer下副本数对写入性能的影响
思路：为验证第五组测试的猜想，本例使用3*5个进程的producer产生数据，将cpu/网络资源跑满，再增加副本数量，来验证以上猜想以及副本数量在满cpu/网络的情况下对写入速度的影响。
3 broker, 1 disks, 21 partition, record-size 512, records 10000000, throughput 1000000，acks=-1
| replication |
records/sec(sum) |
MB/sec(sum) |
| 1 |
665.96 |
1363900 |
| 2 |
312.23 |
639443.6 |
| 3 |
196.38 |
402189.8 |
结论：可以看出当采用多进程的producer的时候，随着副本数量增加，由于kafka需要额外复制副本，写入速度下降了很多。
第六组：测试服务器个数对写入性能的影响：
思路: kafka是一个支持线性扩展的分布式消息中间件，写入性能会随着增加服务器而增加，通过本用例可以观察增加服务器数量对kafka的写入性能的影响。
1 broker, 1 disks, 1 replication, record-size 512, records 10000000, throughput 1000000
| partition |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 1 |
115107.9137 |
56.21 |
546.61 |
744 |
| 3 |
152898.1851 |
74.66 |
410.3 |
647 |
| 5 |
172286.0638 |
84.12 |
363.76 |
647 |
| 7 |
196900.7817 |
96.14 |
316.89 |
587 |
| 9 |
191398.5492 |
93.46 |
325.96 |
582 |
3 broker, 1 disks, 1 replication, record-size 512, records 10000000, throughput 1000000
| partition |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 1 |
77468.93496 |
37.83 |
814.41 |
1319 |
| 3 |
220448.8338 |
107.64 |
282.7 |
919 |
| 5 |
288383.8966 |
140.81 |
215.23 |
626 |
| 7 |
337336.3919 |
164.72 |
182.23 |
679 |
| 9 |
366609.2312 |
179.01 |
168.02 |
712 |
*这里可以看到broker的增加可以明显提高Kafka集群的写入性能，但没有达到理想的或近似线性的扩容。
结论：通过分别测试在1个节点和3个节点挂载单块硬盘时，不同partition数量的写入速度，可以看出当partition数量较少时（本例中为1partition），broker数量增多但由于只有1partition因此写数据时还是只往一个broker中写数据，因此没有提升写入速度，因为增加了寻找partition的开销导致写入速度下降，而当partition数量较多时，所有的partition会分散到不同的broker上，同时写数据，写入速度有明显提升。
第七组：测试开启异步写入对写入性能的影响：
思路: 在同步写入模式中，必须在落盘后才会写入成功，而在异步写入模式中，写入到kafka的内存中即可，开启异步写入应该会对写入性能产生明显提升。通过本用例可以观察异步写入对kafka写入性能的影响。
3 broker, 7 disks, 49 partition, 3 replication, record-size 512, records 10000000, throughput 1000000
| acks |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 0 |
451814.0333 |
220.61 |
130.81 |
534 |
| 1 |
411336.4321 |
200.85 |
143.81 |
573 |
| -1 |
144789.0424 |
70.7 |
421.57 |
1677 |
3 broker, 7 disks, 49 partition, 2 replication, record-size 512, records 10000000, throughput 1000000
| acks |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 0 |
457414.6922 |
223.35 |
130.35 |
531 |
| 1 |
432208.1514 |
211.04 |
137.79 |
714 |
| -1 |
235687.855 |
115.08 |
260.54 |
710 |
3 broker, 7 disks, 49 partition, 1 replication, record-size 512, records 10000000, throughput 1000000
| acks |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 0 |
456246.0078 |
222.78 |
130.44 |
429 |
| 1 |
425170.068 |
207.6 |
138.88 |
920 |
| -1 |
409819.2697 |
200.11 |
144.16 |
586 |
说明：
acks=0 the producer will not wait for any acknowledgment from the server at all.
acks=1 the leader will write the record to its local log but will respond without awaiting full acknowledgement from all followers.
acks=-1 the leader wait for the full set of in-sync replicas to acknowledge the record.
结论：通过测试在3个节点挂载7块硬盘时不同副本数下，测试不同的acks位下的写入速度，可以看出多副本时acks=0时速度最快，其次时acks=1时速度略小于acks=0的情况，而默认的acks=-1/all的情况最差，但单副本的情况下区别不明显。
第八组：测试ssd对写入性能的影响：
3 broker, 1 disks, 1 replication, records 10000000, throughput 1000000
| partition |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 1 |
77468.93496 |
37.83 |
814.41 |
1319 |
| 3 |
220448.8338 |
107.64 |
282.7 |
919 |
| 5 |
288383.8966 |
140.81 |
215.23 |
626 |
| 7 |
337336.3919 |
164.72 |
182.23 |
679 |
| 9 |
366609.2312 |
179.01 |
168.02 |
712 |
3 broker, 1 ssd, 1 replication, records 10000000, throughput 1000000
| partition |
records/sec |
MB/sec |
avg latency(ms) |
max latency(ms) |
| 1 |
79650.81085 |
38.89 |
792.23 |
995 |
| 3 |
197339.8587 |
96.36 |
315.64 |
1012 |
| 5 |
250356.7584 |
122.24 |
247.9 |
677 |
| 7 |
334784.0643 |
163.47 |
184.69 |
506 |
| 9 |
359027.7528 |
175.31 |
171.19 |
582 |
结论：通过测试在3个节点挂载1块硬盘/ssd时不同partition的写入速度，可以看出硬盘和ssd的写入速度相差不是很大，ssd盘写入速度甚至略小与sas盘，猜测可能和ssd盘为系统盘有关系。
第九组：测试producer线程数对写入性能的影响：
1 broker, 7 disks , 21 partition, 1 replication, records 1000000, throughput 1000000
| threads |
records/sec |
MB/sec |
| 1 |
67930.1678 |
33.1690 |
| 10 |
536480.6867 |
261.9535 |
| 20 |
563063.0631 |
274.9331 |
| 30 |
475285.1711 |
232.0728 |
结论：通过测试在1个节点挂载7块硬盘producer采用不同线程数时的写入速度，可以看出线程数在20左右的时候达到峰值，另有测更多partition和broker的情况下峰值时的线程数也在20左右，猜测瓶颈时在producer客户端。
* 在多线程模式下broker数量对写入性能的影响：
22 threads, 7 disks , 1 replication, records 1000000, throughput 1000000
| broker |
partition |
records/sec |
MB/sec |
| 1 |
7 |
553703.2115 |
270.3629 |
| 3 |
7 |
406499.1870 |
198.4859 |
| 3 |
21 |
393541.1255 |
192.1588 |
结论：通过测试在22线程下1个broker和三个broker的写入速度，可以看到随着broker数量增加速度反而下降，与预期相反，也从侧面说明了可能时producer本身的性能达到了瓶颈。
第十组：测试磁盘大小对写入性能的影响：
另外3台服务器配置如下:
CPU: 2物理CPU，12核/CPU , 48 processor Intel(R) Xeon(R) Gold 5118 CPU @ 2.30GHz（这里cpu主频有变化）
内存: 128GB
硬盘: 480GB*1 SSD盘(OS)+4TB*7 SAS盘（这里硬盘大小有变化）
Broker节点数: 3个
对比第六组测试:
1 broker, 1 disks, 1 replication, records 10000000, throughput 1000000
| partition |
records/sec (2.3GHZ cpu) |
records/sec (2.1GHZ cpu) |
MB/sec (2.3GHZ cpu) |
MB/sec (2.1GHZ cpu) |
avg latency(ms) (2.3GHZ cpu) |
avg latency(ms) (2.1GHZ cpu) |
max latency(ms) (2.3GHZ cpu) |
max latency(ms) (2.1GHZ cpu) |
| 1 |
286196.7316 |
115107.9137 |
139.74 |
56.21 |
218.8 |
546.61 |
471 |
744 |
| 3 |
406421.4591 |
152898.1851 |
198.45 |
74.66 |
153.01 |
410.3 |
379 |
647 |
| 5 |
448350.0717 |
172286.0638 |
218.92 |
84.12 |
136.45 |
363.76 |
243 |
647 |
| 7 |
480145.9644 |
196900.7817 |
234.45 |
96.14 |
128.02 |
316.89 |
208 |
587 |
| 9 |
475036.8154 |
191398.5492 |
231.95 |
93.46 |
128.89 |
325.96 |
213 |
582 |
3 broker, 1 disks, 1 replication, records 10000000, throughput 1000000
| partition |
records/sec (2.3GHZ cpu) |
records/sec (2.1GHZ cpu) |
MB/sec (2.3GHZ cpu) |
MB/sec (2.1GHZ cpu) |
avg latency(ms) (2.3GHZ cpu) |
avg latency(ms) (2.1GHZ cpu) |
max latency(ms) (2.3GHZ cpu) |
max latency(ms) (2.1GHZ cpu) |
| 1 |
260613.4841 |
77468.93496 |
127.25 |
37.83 |
240.41 |
814.41 |
472 |
1319 |
| 3 |
320821.3025 |
220448.8338 |
156.65 |
107.64 |
193.25 |
282.7 |
632 |
919 |
| 5 |
520562.2072 |
288383.8966 |
254.18 |
140.81 |
117.29 |
215.23 |
595 |
626 |
| 7 |
374882.8491 |
337336.3919 |
183.05 |
164.72 |
163.95 |
182.23 |
968 |
679 |
| 9 |
482346.1316 |
366609.2312 |
235.52 |
179.01 |
125.88 |
168.02 |
414 |
712 |
结论：通过测试在两个不同的集群测试相同条件下的写入速度，来验证磁盘大小对写入速度的影响，这里结果相差较大，与预期的影响较小有较大差别，因为两个集群的cpu的主频有差别，所以这里的测试结果不能得到一个准确的评判，这里猜测由于cpu的性能提升而引起的写入速度增大的可能性更大。
2.3 Producer多并发情况下的性能评测
通过2.2节第九组测试用例《测试producer线程数对写入性能的影响》的结果可以看出，当同一个进程中的Producer线程数达到特定值（测试集群中为22），Producer的写入速度最快。
同时，在Producer的线程数为22时，当Broker从1增加到3，写入速度反而有小幅下降。这是比较反常的。
因此我们猜测，服务器的cpu处理性能是限制Producer写入速度的关键原因之一。
另外，由于每个Producer线程都在堆内存中有自己的buffer.memory缓冲区，同一个进程的所有线程又共用jvm的堆内存，因此可以考虑JVM的垃圾回收和内存分配机制也会影响Producer的写入性能。
基于上述的猜想，可得出如下推论:
1. 单机单线程producer的写入性能，受单个cpu核心的性能限制。
2. 单机多线程producer的写入性能，受服务器cpu总处理能力，以及线程所属客户端进程堆内存大小的限制。由于每个producer都会使用一个默认的32MB的buffer.memory内存缓冲区，当进程的堆内存分配不足时，会导致频繁GC，进而影响producer的写入性能。
3. 单机多进程producer的写入性能，受服务器cpu总处理能力的限制。
4. 多机多进程producer的写入性能，受kafka集群总处理能力的限制。
下面通过六组测试用例，对如上猜想和推论作验证。
测试条件:2Broker，14Partition，吞吐量 240000records/s，单条消息大小为512bytes
第一组 单机单线程producer的写入性能
| records/sec |
MB/sec |
avg latency |
max latency |
| 261793 |
127.83 |
231.81 |
573 |
第二组 单机24线程producer的不同堆内存配置下的写入性能
| 堆内存配置 |
records/sec |
MB/sec |
| 512MB 仅设置Xmx |
423584 |
206.8 |
| 1024MB 仅设置Xmx |
551875 |
269.47 |
| 2048MB 仅设置Xmx |
900737 |
439.81 |
| 2048MB 设置Xms=Xmx |
927298 |
452.78 |
| 4096MB 仅设置Xmx |
900737 |
439.81 |
| 4096MB 设置Xms=Xmx |
1305480 |
637.44 |
增加堆内存对提升性能有明显帮助，当堆内存到4096MB时，设置Xms=Xmx能显著提升性能。
第三组 单机多进程producer的写入性能
多个独立进程和单个线程的多个进程相比，写入性能有所提升。24线程的Producer写入速度为637.44MB，而24进程的Producer写入速度为726.17MB/s。
1）单机5进程
| 进程号 |
records/sec |
MB/sec |
avg latency |
max latency |
| 1 |
233934 |
114.23 |
252.16 |
751 |
| 2 |
232828 |
113.69 |
252.03 |
756 |
| 3 |
232460 |
113.51 |
252.88 |
754 |
| 4 |
232471 |
113.51 |
253.65 |
748 |
| 5 |
232401 |
113.48 |
253.06 |
740 |
| 合计 |
1164094 |
568.42 |
252.756 |
756 |
2）单机8进程
| 进程号 |
records/sec |
MB/sec |
avg latency |
max latency |
| 1 |
141310 |
69 |
424.15 |
1028 |
| 2 |
140773 |
68.74 |
426.79 |
1126 |
| 3 |
140552 |
68.63 |
430.17 |
950 |
| 4 |
140738 |
68.72 |
425.97 |
1107 |
| 5 |
140394 |
68.55 |
426.58 |
868 |
| 6 |
140044 |
68.38 |
430.2 |
1012 |
| 7 |
139155 |
67.95 |
434 |
873 |
| 8 |
138607 |
67.68 |
433.3 |
1104 |
| 合计 |
1121573 |
547.67 |
503.2 |
1126 |
3）单机24进程
| 进程号 |
records/sec |
MB/sec |
avg latency |
max latency |
| 1 |
62516 |
30.53 |
963.44 |
2560 |
| 2 |
62455 |
30.5 |
967.1 |
2562 |
| 3 |
62374 |
30.46 |
963.11 |
1965 |
| 4 |
62354 |
30.45 |
962.21 |
2116 |
| 5 |
62302 |
30.42 |
970.93 |
2361 |
| 6 |
62312 |
30.43 |
962.87 |
2333 |
| 7 |
62175 |
30.36 |
983.57 |
2145 |
| 8 |
62125 |
30.33 |
980.07 |
2188 |
| 9 |
62107 |
30.33 |
970.76 |
2234 |
| 10 |
62043 |
30.29 |
974.63 |
2584 |
| 11 |
62068 |
30.31 |
973.67 |
2128 |
| 12 |
61958 |
30.25 |
978.48 |
2512 |
| 13 |
61931 |
30.24 |
976.52 |
2280 |
| 14 |
61906 |
30.23 |
975.36 |
2211 |
| 15 |
61845 |
30.2 |
983.59 |
2411 |
| 16 |
61773 |
30.16 |
980.99 |
2438 |
| 17 |
61700 |
30.13 |
984.88 |
2366 |
| 18 |
61677 |
30.12 |
987.6 |
2073 |
| 19 |
61599 |
30.08 |
981.48 |
2083 |
| 20 |
61563 |
30.06 |
988.25 |
2426 |
| 21 |
61639 |
30.1 |
985.35 |
1918 |
| 22 |
61632 |
30.09 |
983.79 |
2350 |
| 23 |
61543 |
30.05 |
988.65 |
2423 |
| 24 |
61549 |
30.05 |
990.83 |
2061 |
| 合计 |
1487146 |
726.17 |
977.42 |
2584 |
第四组 多机多进程producer的写入性能
该用例证明，Producer写入的瓶颈经常发生在客户端服务器，受限于客户端服务器的cpu处理能力。
如下用例中，随着客户端从2台服务器增加到3台服务器，kafka集群的写入的总吞吐量从1066.53MB/s上升到了1694.22MB/s。
在达到kafka集群的处理能力瓶颈之前，随着客户端服务器的增加，kafka集群的吞吐量应该是线性提升的。
本测试用例中，kafka集群由2台broker组成，因此NIC的上限应为2*10Gb/s(实际用iperf测试的结果为7Gb/s-9Gb/s)，这也是kafka集群吞吐量的理论上限值。
由于只有三台服务器可以用来作为Producer客户端进行测试，并且还存在本地写入数据获得的网络流量节约收益的影响，本测试用例中的1694.22MB/s还远没有达到集群吞吐量上限。
1）2节点客户端，5producer进程/节点
| 机器号-进程号 |
records/sec |
MB/sec |
avg latency |
max latency |
| vm16_1 |
199664 |
97.49 |
292.58 |
801 |
| vm16_2 |
198822 |
97.08 |
299.17 |
740 |
| vm16_3 |
198483 |
96.92 |
297.13 |
797 |
| vm16_4 |
196749 |
96.07 |
290.9 |
796 |
| vm16_5 |
195549 |
95.48 |
298.77 |
803 |
| vm15_1 |
239854 |
117.12 |
165.63 |
891 |
| vm15_2 |
239842 |
117.11 |
182.91 |
870 |
| vm15_3 |
238914 |
116.66 |
233.13 |
903 |
| vm15_4 |
238504 |
116.46 |
242.8 |
913 |
| vm15_5 |
237857 |
116.14 |
247.24 |
1005 |
| 合计 |
2184238 |
1066.53 |
255.026 |
1005 |
2）3节点客户端，5producer进程/节点
| 机器号-进程号 |
records/sec |
MB/sec |
avg latency |
max latency |
| vm16_1 |
232309 |
113.43 |
260 |
880 |
| vm16_2 |
232331 |
113.44 |
258.14 |
821 |
| vm16_3 |
230669 |
112.63 |
262.34 |
848 |
| vm16_4 |
229378 |
112 |
262.2 |
914 |
| vm16_5 |
225794 |
110.25 |
262.96 |
863 |
| vm15_1 |
236060 |
115.26 |
254.35 |
811 |
| vm15_2 |
236540 |
115.5 |
251.07 |
811 |
| vm15_3 |
232363 |
113.46 |
257.94 |
824 |
| vm15_4 |
231117 |
112.85 |
256.49 |
851 |
| vm15_5 |
230223 |
112.41 |
258.53 |
886 |
| vm14_1 |
231867 |
113.22 |
259 |
1077 |
| vm14_2 |
231042 |
112.81 |
259.87 |
1051 |
| vm14_3 |
230001 |
112.31 |
260.51 |
1028 |
| vm14_4 |
230043 |
112.33 |
260.11 |
1021 |
| vm14_5 |
230033 |
112.32 |
260.52 |
1037 |
| 合计 |
3469770 |
1694.22 |
258.9353333 |
1077 |
第五组 多机多进程producer在单机Broker下的写入性能
本用例将Broker数量减小至1台，7parititon，部署在vm14上，以测试多机多进程Producer写入单机Broker的吞吐量上限。
可以看到其中vm15,vm16写入vm14的网络流量之和达到800MB/s，接近vm14的网卡上限。
而vm14上的客户端由于不需要走网络流量，使得三台producer客户端写入Broker的速度达到1238.7MB/s，高于vm14的网卡速率。
因此可以假设:Kafka的写入速度瓶颈并不在磁盘上，而是在网卡上。该假设将在下一组实验中论证。
| 机器号-进程号 |
records/sec |
MB/sec |
avg latency |
max latency |
| vm16_1 |
169136 |
82.59 |
364.4 |
1132 |
| vm16_2 |
167914 |
81.99 |
366.66 |
1153 |
| vm16_3 |
167324 |
81.7 |
368.2 |
1180 |
| vm16_4 |
167622 |
81.85 |
367.47 |
1227 |
| vm16_5 |
165332 |
80.73 |
373.78 |
1187 |
| vm15_1 |
162723 |
79.45 |
377.7 |
789 |
| vm15_2 |
161274 |
78.75 |
380.7 |
867 |
| vm15_3 |
160632 |
78.43 |
382.7 |
871 |
| vm15_4 |
158836 |
77.56 |
387.53 |
863 |
| vm15_5 |
157898 |
77.1 |
389.6 |
881 |
| vm14_1 |
180564 |
88.17 |
339.76 |
756 |
| vm14_2 |
180108 |
87.94 |
340 |
749 |
| vm14_3 |
179700 |
87.74 |
341.87 |
846 |
| vm14_4 |
179166 |
87.48 |
343.58 |
840 |
| vm14_5 |
178635 |
87.22 |
344.29 |
799 |
| 合计 |
2536864 |
1238.7 |
364.5493333 |
1227 |
第六组 多机多进程producer在单机Broker下缩减磁盘后的写入性能
在上一组测试中证明单个服务器Broker挂满磁盘的情况下，从其他客户端写入数据的吞吐量可以接近网络流量上限，尝试缩减Broker的磁盘个数，观察是否仍然能够使写入速度达到网络上限？
1）修改磁盘数:7=>6 partition7=>6
vm16,vm15流量之和为754.14MB/s
| 机器号-进程号 |
records/sec |
MB/sec |
avg latency |
max latency |
| vm16_1 |
158861 |
77.57 |
389.48 |
1114 |
| vm16_2 |
158548 |
77.42 |
391.12 |
1136 |
| vm16_3 |
158478 |
77.38 |
389.29 |
1118 |
| vm16_4 |
158323 |
77.31 |
390.9 |
1116 |
| vm16_5 |
158192 |
77.24 |
391.15 |
1121 |
| vm15_1 |
150838 |
73.65 |
409.12 |
1908 |
| vm15_2 |
150957 |
73.71 |
409.14 |
1915 |
| vm15_3 |
150747 |
73.61 |
412.26 |
1903 |
| vm15_4 |
150756 |
73.61 |
409.54 |
1908 |
| vm15_5 |
148774 |
72.64 |
413.31 |
1921 |
| vm14_1 |
156474 |
76.4 |
381.89 |
1899 |
| vm14_2 |
155705 |
76.03 |
391.09 |
1893 |
| vm14_3 |
154985 |
75.68 |
399.37 |
1910 |
| vm14_4 |
154971 |
75.67 |
398.95 |
1887 |
| vm14_5 |
155178 |
75.77 |
398.21 |
1900 |
| 合计 |
2321787 |
1133.69 |
398.3213333 |
1921 |
尝试降低本地客户端的影响：虽然磁盘数量从7降到6，但vm15,vm16写入vm14的流量仍达到915MB/s，接近或达到网卡速率上限。
若不考虑在kafka所在服务器上部署producer，可以稍微降低磁盘的配置，因为由于万兆网卡的速率限制，Broker上的磁盘写入能力并没有充分利用起来。
另一方面，将producer部署在kafka的Broker所在节点上，虽然提升了磁盘利用率，但可能会造成Broker中的内存和cpu资源被其他进程抢占，造成意外情况。
| 机器号-进程号 |
records/sec |
MB/sec |
avg latency |
max latency |
| vm16_1 |
195863 |
95.64 |
312.67 |
605 |
| vm16_2 |
194355 |
94.9 |
316.09 |
717 |
| vm16_3 |
194084 |
94.77 |
316.81 |
706 |
| vm16_4 |
193963 |
94.71 |
316.49 |
611 |
| vm16_5 |
192938 |
94.21 |
319.66 |
767 |
| vm15_1 |
186219 |
90.93 |
329.85 |
584 |
| vm15_2 |
183742 |
89.72 |
334.99 |
663 |
| vm15_3 |
178628 |
87.22 |
344.36 |
660 |
| vm15_4 |
177948 |
86.89 |
344.72 |
653 |
| vm15_5 |
176584 |
86.22 |
347.81 |
665 |
| 合计 |
1874324 |
915.21 |
328.345 |
767 |
2）修改磁盘数:7=>3 partition7=>6
vm16,vm15流量之和为540.8MB/s
| 机器号-进程号 |
records/sec |
MB/sec |
avg latency |
max latency |
| vm16_1 |
117913 |
57.57 |
525.2 |
9036 |
| vm16_2 |
117796 |
57.52 |
525.43 |
9050 |
| vm16_3 |
117553 |
57.4 |
528.17 |
9041 |
| vm16_4 |
117354 |
57.3 |
529.09 |
9043 |
| vm16_5 |
115561 |
56.43 |
537.25 |
9040 |
| vm15_1 |
105028 |
51.28 |
592.25 |
9090 |
| vm15_2 |
104716 |
51.13 |
593.88 |
9174 |
| vm15_3 |
104171 |
50.86 |
595.53 |
9173 |
| vm15_4 |
104112 |
50.84 |
595.75 |
9174 |
| vm15_5 |
103365 |
50.47 |
599.82 |
9156 |
| vm14_1 |
109101 |
53.27 |
571.93 |
9040 |
| vm14_2 |
109072 |
53.26 |
571.99 |
9037 |
| vm14_3 |
108882 |
53.17 |
573.01 |
9024 |
| vm14_4 |
108825 |
53.14 |
573.27 |
9037 |
| vm14_5 |
108672 |
53.06 |
574.35 |
9028 |
| 合计 |
1652121 |
806.7 |
565.7946667 |
9174 |
尝试降低本地客户端的影响，当磁盘数降到3时，可以看出Broker的吞吐量下降了。
| 机器号-进程号 |
records/sec |
MB/sec |
avg latency |
max latency |
| vm16_1 |
141087 |
68.89 |
438.53 |
7580 |
| vm16_2 |
139532 |
68.13 |
443.67 |
7567 |
| vm16_3 |
139349 |
68.04 |
443.77 |
7575 |
| vm16_4 |
139326 |
68.03 |
444.55 |
7564 |
| vm16_5 |
138220 |
67.49 |
448.9 |
7600 |
| vm15_1 |
140024 |
68.37 |
440.56 |
7655 |
| vm15_2 |
138669 |
67.71 |
444.13 |
7659 |
| vm15_3 |
138385 |
67.57 |
445.16 |
7663 |
| vm15_4 |
138163 |
67.46 |
445.63 |
7647 |
| vm15_5 |
138159 |
67.46 |
443.56 |
7659 |
| 合计 |
1390914 |
679.15 |
443.846 |
7663 |
2.4 Consumer测试方案
第一组：topic的paritition数量变化对Consumer读取速度的影响
Partition是Consumer消费的基本单元，一个Partition最多只能被一个Consumer实例消费，而一个Consumer实例能够同时消费多个Partition。
当存在多个Partition时，通过多个Consumer实例可以使数据读取得到很好的扩展性。
1）单磁盘
| brokers |
disks |
partition |
fetch.MB.sec |
fetch.nMsg.sec |
| 1 |
1 |
1 |
202.5608 |
414844.603 |
| 1 |
1 |
3 |
251.7045 |
515490.7216 |
| 1 |
1 |
5 |
273.7764 |
560694.1018 |
| 1 |
1 |
7 |
284.5266 |
582710.4067 |
结论：单磁盘的情况下，增加partition的数量可以提高消费能力。
2）多磁盘
| brokers |
disks |
partition |
fetch.MB.sec |
fetch.nMsg.sec |
| 1 |
1 |
1 |
202.5608 |
414844.603 |
| 1 |
2 |
1 |
223.2095 |
457133.1139 |
| 1 |
2 |
2 |
247.9393 |
507779.6283 |
结论：增加磁盘数量可以提高消费能力。
3）多服务器
| brokers |
disks |
partition |
fetch.MB.sec |
fetch.nMsg.sec |
| 1 |
1 |
1 |
202.5608 |
414844.603 |
| 2 |
1 |
1 |
225.9357 |
462716.2687 |
| 2 |
1 |
2 |
330.2849 |
676423.4307 |
结论：增加broker数量可以提高消费能力
*本例只测试了单consumer单线程的本机消费能力，关于多个consumer和多线程的情况在后续用例中补充，该测试用例的结果均时在单consumer单线程的前提下进行的测试
第二组：测试ssd对Consumer读取性能的影响
ssd盘在数据读取时可能会对consumer的读取性能有提升
对照组sas盘：
| brokers |
disks |
partition |
fetch.MB.sec |
fetch.nMsg.sec |
| 1 |
1 |
1 |
202.5608 |
414844.603 |
| 1 |
1 |
3 |
251.7045 |
515490.7216 |
| 1 |
1 |
5 |
273.7764 |
560694.1018 |
实验组ssd盘：
| brokers |
ssd |
partition |
fetch.MB.sec |
fetch.nMsg.sec |
| 1 |
1 |
1 |
498.5514 |
1021033.2857 |
| 1 |
1 |
3 |
744.3312 |
3048780.4878 |
| 1 |
1 |
5 |
425.6287 |
1743375.1743 |
*多线程consumer对比实验组（数量等于partition数）
| brokers |
ssd |
partition |
fetch.MB.sec |
fetch.nMsg.sec |
| 1 |
1 |
3 |
254.1190 |
1040871.5564 |
| 1 |
1 |
5 |
213.6263 |
875013.1252 |
结论：使用ssd可用提升consumer的读取性能。
第三组：测试并发情况下consumer的性能
单个broker在vm15上，7块硬盘，7个partition
* 先后在三个节点上启动consumer（不同时启动，而是分别在不同节点进行测试）
单进程单线程
| host |
fetch.MB.sec |
fetch.nMsg.sec |
| vm14 |
252.7953 |
517724.7877 |
| vm15 |
442.6969 |
906643.3364 |
| vm16 |
293.3786 |
600839.4617 |
7进程单线程
| host |
fetch.MB.sec |
fetch.nMsg.sec |
| vm14 |
664.4753 |
1360845.456 |
| vm15 |
979.4621 |
2005938.397 |
| vm16 |
646.7693 |
1324583.567 |
第四组：测试有无group对consumer性能的影响
本组实验主要测试多个consumer同时消费时是否在同一组对总消费能力的影响
* 先后在三个节点上启动consumer（不同时启动，而是分别在不同节点进行测试）
单个broker在vm15上，7块硬盘，7个partition，7进程单线程
不带group_id
| host |
fetch.MB.sec |
fetch.nMsg.sec |
| vm14 |
925.1035 |
1894612.27 |
| vm15 |
1047.9904 |
2146284.597 |
| vm16 |
986.2786 |
2019898.688 |
带group_id
| host |
fetch.MB.sec |
fetch.nMsg.sec |
| vm14 |
670.608 |
1373405.073 |
| vm15 |
1075.5057 |
2202635.803 |
| vm16 |
654.3338 |
1340075.742 |
结论：vm15上是否有group id的影响不大，考虑到单broker在vm15上，所以忽略掉这组数据。在vm14和vm16上当带着相同的group id消费时，消费能力明显下降。多个消费者不属于一个组时，读取的是相同的一份数据，只有第一个取数据的消费之会经历从磁盘-内存-网络-客户端，之后的消费之会直接使用内存中的缓存数据，省略掉磁盘到内存的过程，相比之下，总消费能力高于同一组消费者消费的情况。
第五组：多broker对consumer性能的影响
* 先后在三个节点上启动consumer（不同时启动，而是分别在不同节点进行测试）
broker：vm15、vm16，7块硬盘，14个partition，consumer：14进程单线程
| host |
fetch.MB.sec |
fetch.nMsg.sec |
| vm14 |
959.2592 |
1964563 |
| vm15 |
1232.547 |
2524258 |
| vm16 |
1038.836 |
2127535 |
结论：与第三组的数据做对比发现在多进程的consumer消费时，broker增加一个，消费能力明显提升（vm14达到网络瓶颈，vm16上有ambari server）。
第六组：了解consumer运行时的资源消耗
思路：通过观察consumer运行时broker上的资源使用以及consumer上的资源使用情况，了解Kafka读数据时对各个节点的哪些资源消耗较大。
broker：vm15，consumer：vm14、vm16， 两个consumer(单进程)，topic：7partition，大致时间段：15：20-15：40
broker（vm15）：
consumer（vm14）：cpu使用率在7%左右，内存无变化
consumer（vm16）：cpu使用率在7%左右，内存无变化
分析：从整体来看broker节点网络资源out量=consumer节点网络资源in总量，broker节点的cpu几乎无波动（使用率在1%以内），consumer节点的cpu使用率在7%左右。由此可见consumer读取数据时对broker的压力主要体现在网络上，对cpu的压力几乎可以忽略，这得益于Kafka的零拷贝技术。
2.5 同时读写情况下Kafka的性能表现
1)2.3节 第五组 多机多进程producer在单机Broker下的写入性能 的结果如下, 3client*5process,7 SAS disk 7parititon Topic，Broker 部署在node3上
| 机器号-进程号 |
records/sec |
MB/sec |
avg latency |
max latency |
| vm16_1 |
169136 |
82.59 |
364.4 |
1132 |
| vm16_2 |
167914 |
81.99 |
366.66 |
1153 |
| vm16_3 |
167324 |
81.7 |
368.2 |
1180 |
| vm16_4 |
167622 |
81.85 |
367.47 |
1227 |
| vm16_5 |
165332 |
80.73 |
373.78 |
1187 |
| vm15_1 |
162723 |
79.45 |
377.7 |
789 |
| vm15_2 |
161274 |
78.75 |
380.7 |
867 |
| vm15_3 |
160632 |
78.43 |
382.7 |
871 |
| vm15_4 |
158836 |
77.56 |
387.53 |
863 |
| vm15_5 |
157898 |
77.1 |
389.6 |
881 |
| vm14_1 |
180564 |
88.17 |
339.76 |
756 |
| vm14_2 |
180108 |
87.94 |
340 |
749 |
| vm14_3 |
179700 |
87.74 |
341.87 |
846 |
| vm14_4 |
179166 |
87.48 |
343.58 |
840 |
| vm14_5 |
178635 |
87.22 |
344.29 |
799 |
| 合计 |
2536864 |
1238.7 |
364.5493333 |
1227 |
由于上述节点的一些问题，改用第二组服务器(node1-node3)测试
| 服务器编号-进程编号 |
record/s |
MB/s |
avg latency(ms) |
max latency(ms) |
| node1-1 |
159994 |
78.12 |
387.58 |
916 |
| node1-2 |
157059 |
76.69 |
394.26 |
929 |
| node1-3 |
156040 |
76.19 |
395.68 |
823 |
| node1-4 |
155048 |
75.71 |
398.69 |
865 |
| node1-5 |
154263 |
75.32 |
400.97 |
900 |
| node2-1 |
157099 |
76.71 |
391.65 |
1085 |
| node2-2 |
155289 |
75.82 |
396.97 |
1155 |
| node2-3 |
152816 |
74.62 |
401.88 |
1057 |
| node2-4 |
152063 |
74.25 |
405.24 |
1127 |
| node2-5 |
150661 |
73.57 |
407.64 |
1015 |
| node3-1 |
159098 |
77.68 |
383.47 |
929 |
| node3-2 |
158277 |
77.28 |
386.23 |
955 |
| node3-3 |
154549 |
75.46 |
395.06 |
913 |
| node3-4 |
153884 |
75.14 |
398.12 |
970 |
| node3-5 |
151299 |
73.88 |
404.66 |
981 |
| 总计 |
2327439 |
1136.44 |
396.54 |
1155 |
2)多机多进程Consumer在单机Broker下的读取性能 的结果如下, 3client*1process,7 SAS disk 7parititon Topic，Broker 部署在node3上:
| 服务器编号-进程编号 |
record/s |
MB/s |
| node1-1 |
790954.2866 |
386.2081 |
| node2-1 |
868217.3989 |
423.9343 |
| node3-1 |
1016968.68 |
496.5667 |
| 总计 |
2676140.366 |
1306.7091 |
3)多机单进程Consumer和多机多进程producer在单机Broker下同时读写性能 的结果如下，3client*1process consumer, 3client*5process producer,7 SAS disk 7parititon Topic，Broker 部署在node3上:
producer
| 服务器编号-进程编号 |
record/s |
MB/s |
avg latency(ms) |
max latency(ms) |
| node1-1 |
128985.6568 |
62.98 |
477.37 |
1298 |
| node1-2 |
128769.734 |
62.88 |
479.43 |
1314 |
| node1-3 |
128293.9471 |
62.64 |
481.55 |
1318 |
| node1-4 |
127828.1989 |
62.42 |
483.78 |
1349 |
| node1-5 |
127616.1307 |
62.31 |
482.98 |
1364 |
| node2-1 |
130712.1196 |
63.82 |
473.27 |
1330 |
| node2-2 |
129292.5114 |
63.13 |
479.4 |
1356 |
| node2-3 |
128945.7396 |
62.96 |
480.19 |
1359 |
| node2-4 |
127851.0791 |
62.43 |
484.19 |
1286 |
| node2-5 |
127775.9321 |
62.39 |
484.2 |
1360 |
| node3-1 |
128882.588 |
62.93 |
478.95 |
1001 |
| node3-2 |
127769.4018 |
62.39 |
481.74 |
855 |
| node3-3 |
127411.2581 |
62.21 |
484.46 |
1036 |
| node3-4 |
127171.4526 |
62.1 |
485.22 |
1034 |
| node3-5 |
126874.5718 |
61.95 |
486.4 |
980 |
| 总计 |
1924180.321 |
939.54 |
481.542 |
1364 |
consumer
| 服务器编号-进程编号 |
record/s |
MB/s |
| node1-1 |
587482.552 |
286.8567 |
| node2-1 |
537564.2873 |
262.4826 |
| node3-1 |
475098.2423 |
231.9816 |
| 总计 |
1600145.082 |
781.3209 |
通过对比同时读写和单独读写的情况下读取速度和写入速度，可以发现同时读写时，写入速度和读取速度都有所下降，其中写入总量由1136.44MB/s下降到939.54MB/s，读取总量从1306.7091MB/s下降到781.3209MB/s，考虑到同时读写时读和写都在三台机子上同时进行可能带来影响，还需要补充读写不在同一台机器上时的情况。
*1)单机进程producer在单机Broker下的写入性能 的结果如下, 1client*5process,7 SAS disk 7parititon Topic，Broker 部署在node3上，producer在node1上
| 服务器编号-进程编号 |
record/s |
MB/s |
avg latency(ms) |
max latency(ms) |
| node1-1 |
144529.5563 |
70.57 |
425.11 |
782 |
| node1-2 |
144146.2219 |
70.38 |
427.25 |
790 |
| node1-3 |
143653.3931 |
70.14 |
428.03 |
787 |
| node1-4 |
143620.3826 |
70.13 |
428.89 |
785 |
| node1-5 |
143266.4756 |
69.95 |
431.02 |
790 |
| 总计 |
719216.0296 |
351.17 |
428.06 |
790 |
*2)单机单进程Consumer在单机Broker下的读取性能 的结果如下, 1client*1process,7 SAS disk 7parititon Topic，Broker 部署在node3上，Consumer在node2上:
| 服务器编号-进程编号 |
record/s |
MB/s |
| node2-1 |
936691.6448 |
457.3690 |
*3)单机单进程Consumer和单机多进程producer在单机Broker下同时读写性能 的结果如下，1client*1process consumer, 1client*5process producer,7 SAS disk 7parititon Topic，Broker 部署在node3上，Producer在node1上，Consumer在node2上:
producer
| 服务器编号-进程编号 |
record/s |
MB/s |
avg latency(ms) |
max latency(ms) |
| node1-1 |
148628.1621 |
72.57 |
414.32 |
652 |
| node1-2 |
147719.2153 |
72.13 |
414.7 |
649 |
| node1-3 |
146877.3868 |
71.72 |
418.55 |
651 |
| node1-4 |
145747.0996 |
71.17 |
420.68 |
667 |
| node1-5 |
145158.949 |
70.88 |
421.91 |
650 |
| 总计 |
734130.8128 |
358.47 |
418.032 |
667 |
consumer
| 服务器编号-进程编号 |
record/s |
MB/s |
| node2-1 |
817825.9732 |
399.3291 |
Broker 部署在node3上，Producer在node1上，Consumer在node2上，通过对比同时读写和单独读写的情况下读取速度和写入速度，可以看出写入速度只有略微的下降，读取速度下降的较为明显
结论：在同时读写时，读写不同机时读取会受到一些影响，对于写入几乎没有影响，读写同机时读取影响较大，写入影响较小。
2.6 长时间写入的情况下kafka的性能表现
Kafka Broker为了提升写入效率，会将接收到的数据先缓存到os cache层，然后再批量写入到磁盘中。本用例用于观察Kafka在大批量长时间的数据写入时，写入性能是否稳定。
测试条件: 一台Broker，7*6T SAS盘， 7partition，7-14个 Producer进程同时写入。
1）磁盘io观测
磁盘写入IO最大值可达到单磁盘200MB/s左右 ，服务器总写入磁盘io约为1400MB/s。
一般来说，小文件的读写速度会远小于大文件，而kafka由于是将数据批量flush到硬盘中，避免了小文件问题导致的性能影响，理论上能达到磁盘的写入上限，下面通过dd命令测试磁盘的最大写入速度。
sudo time dd if=/dev/zero of=/data/data1/test.dbf bs=8k count=300000 oflag=direct
of: 输出文件位置，对应挂载的磁盘。 oflag=direct: 关闭OS缓存。
| 文件总大小 |
文件个数 |
单个文件大小 |
是否开启OS缓存 |
磁盘 |
CPU利用率 |
写入速度 |
命令 |
| 2.4GB |
300000 |
8kB |
否 |
SAS |
0% |
974 kB/s |
sudo time dd if=/dev/zero of=/data/data1/test.dbf bs=8k count=300000 oflag=direct |
| 2.4GB |
300000 |
8kB |
是 |
SAS |
25% |
185 MB/s |
sudo time dd if=/dev/zero of=/data/data1/test.dbf bs=8k count=300000 |
| 2.4GB |
300000 |
8kB |
否 |
SSD |
10% |
200 MB/s |
sudo time dd if=/dev/zero of=/home/work/test.dbf bs=8k count=300000 oflag=direct |
| 2.4GB |
300000 |
8kB |
是 |
SSD |
41% |
314 MB/s |
sudo time dd if=/dev/zero of=/home/work/test.dbf bs=8k count=300000 |
| 2.4GB |
30 |
80MB |
否 |
SAS |
14% |
205 MB/s |
sudo time dd if=/dev/zero of=/data/data1/test.dbf bs=80000k count=30 oflag=direct |
| 24GB |
30 |
80MB |
是 |
SAS |
99% |
1.0 GB/s |
sudo time dd if=/dev/zero of=/data/data1/test.dbf bs=80000k count=300 |
| 2.4GB |
30 |
80MB |
否 |
SSD |
19% |
389 MB/s |
sudo time dd if=/dev/zero of=/home/work/test.dbf bs=80000k count=30 oflag=direct |
| 24GB |
30 |
80MB |
是 |
SSD |
99% |
1.5 GB/s |
sudo time dd if=/dev/zero of=/home/work/test.dbf bs=80000k count=300 |
在不开缓存的情况下，SAS盘写大文件的速度上限约为200MB/s。
2) 每秒写入记录数观测
随着Producer的进程数由7个增至14个，写入速度从80w条/秒上升至207w条/秒，并稳定运行。
3) jvm状况观测
4) 内存状况观测
5) 总写入数据量
1.9TB*7=13.3TB
2.7 大数据量下压测kafka至磁盘空间不足时的表现
为了进一步观测kafka长时间运行的表现，可以考虑Kafka的单个Broker在最坏情况下的表现。极限的情况是，Broker所在服务器的磁盘被写满，观察这种情况对性能的影响。
本用例的运行条件与2.6相同，是在2.6的基础上继续执行同样的测试命令，14个其他服务器的客户都拿进程同时写入vm15中的kafka至磁盘达到饱和状态。
1)磁盘变化情况
磁盘空间一开始呈线性下降趋势，当服务器可用总空间仅剩98.9.9GB时，磁盘空间停止下降， 在8点40左右继续开始小幅下降。
2)写入速度的变化
消息写入速度从200w条/秒，经过4个小时的写入后组逐渐下降至100w条/秒左右，在23点20左右磁盘空间不足后短暂异常飙升，然后降至0，在第二天8点40后恢复5w条/秒的写入速度,之后又降为0。
3）df -h查看已使用磁盘空间为100%
4）内存使用情况
整个过程内存使用情况平稳。
5）cpu和负载
整个过程CPU负载随着写入情况变化，负载较低。
6）网络流量负载
整个过程中网络流量随写入速度变化明显。
7) 问题分析
问题1.vm.max_map_count=65535不太够用,需要调整为262144
| root@vm15 # sysctl -w vm.max_map_count=262144 root@vm15 # sysctl -a|grep vm.max_map_count vm.max_map_count = 262144 |
查看kafka 的vm.maps,
问题2. 硬盘空间不足导致Kafka Broker强制退出
| [2019-10-29 23:17:11,054] ERROR Error while appending records to test_long_time-0 in dir /data/data7/kafka-logs (kafka.server.LogDirFailureChannel) [2019-10-29 23:17:11,097] ERROR Error while appending records to test_long_time-3 in dir /data/data1/kafka-logs (kafka.server.LogDirFailureChannel) [2019-10-29 23:17:12,054] ERROR Error while appending records to test_long_time-5 in dir /data/data6/kafka-logs (kafka.server.LogDirFailureChannel) [2019-10-29 23:17:12,056] ERROR Error while appending records to test_long_time-4 in dir /data/data4/kafka-logs (kafka.server.LogDirFailureChannel) [2019-10-29 23:17:45,410] ERROR Error while appending records to test_long_time-1 in dir /data/data5/kafka-logs (kafka.server.LogDirFailureChannel) [2019-10-29 23:17:27,101] ERROR Error while appending records to test_long_time-2 in dir /data/data2/kafka-logs (kafka.server.LogDirFailureChannel) [2019-10-29 23:18:11,235] ERROR Shutdown broker because all log dirs in /data/data1/kafka-logs, /data/data2/kafka-logs, /data/data3/kafka-logs, /data/data4/kafka-logs, /data/data5/kafka-logs, /data/data6/kafka-logs, /data/data7/kafka-logs have failed (kafka.log.LogManager) |
系统优化
内存优化
这里主要针对三个参数进行调优测试：vm.swappiness、vm.dirty_background_ratio、vm.dirty_ratio。
vm.swappiness 表示 VM 系统中的多少百分比用来作为 swap 空间；
vm.dirty_background_ratio 指的是被内核进程刷新到磁盘之前缓存脏页数量占系统内存的百分比，异步flush，不影响正常I/O；
vm.dirty_ratio 指的是被内核进程刷新到磁盘之前的脏页数量，同步I/O，影响正常I/O。
对 照 组：vm.swappiness=60 vm.dirty_background_ratio=10 vm.dirty_ratio=20（系统默认值）
实验组一：vm.swappiness=1 vm.dirty_background_ratio=5 vm.dirty_ratio=60
实验组二：vm.swappiness=1 vm.dirty_background_ratio=5 vm.dirty_ratio=20
实验组三：vm.swappiness=1 vm.dirty_background_ratio=10 vm.dirty_ratio=20
实验组四：vm.swappiness=1 vm.dirty_background_ratio=10 vm.dirty_ratio=60
相对与对照组的吞吐量和稳定性，四个实验组可以得出以下结论：
| vm.swappiness |
vm.dirty_background_ratio |
vm.dirty_ratio |
吞吐量 |
稳定性 |
| 1 |
5 |
60 |
降低 |
提高 |
| 1 |
5 |
20 |
降低 |
提高 |
| 1 |
10 |
20 |
不变 |
不变 |
| 1 |
10 |
60 |
不变 |
略好 |
根据实验组三可以看出 vm.swappiness 参数修改前后变化不大，考虑到系统内存很大，没用到 swap 的情况，可以暂时忽略该参数的影响，以下主要分析 vm.dirty_background_ratio 和 vm.dirty_ratio 的影响：
首先 vm.dirty_background_ratio 指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如5%）就会触发将一定缓存的脏页异步地刷入磁盘；vm.dirty_ratio 则指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如10%），系统不得不开始处理缓存脏页，在此过程中很多应用进程可能会因为系统转而处理文件IO而阻塞。
从实验现象中也可以看出 vm.dirty_background_ratio 的调整无论是对吞吐量还是稳定性都有很大的影响，10→5时，系统处理脏页（异步刷到磁盘）的频率会增加，由此造成了吞吐量的降低和吞吐量的更加稳定，而 vm.dirty_ratio 的调整要小一些，主要影响稳定性方面(不是很明显)，20->60时，系统必须同步处理脏页的频率又有所下降，由此消除了一些吞吐量较低的点（由于阻塞式刷数据造成的吞吐量下降）。
最佳实践
一、存储
1.1 磁盘类型 大部分时候选择普通的sas盘即可
1.2 磁盘大小/数量 根据业务的数据量大小、副本数量、保存天数等策略的选择，计算出所需的总存储量来综合决定
二、主题
2.1 分区数量 24（3broker*7disk，均衡消费者的负载，同时尽量的将分区均摊到每块硬盘）
2.2 副本数量 一般情况下选择2，一致性要求较高时选择3
三、生产者/消费者 客户端
3.1 配置堆内存大小 -Xmx4096M -Xms4096M
3.2 线程/进程数 根据实际的业务需求决定
来源：oschina
链接：https://my.oschina.net/u/4295105/blog/4702328