一.硬件配置
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 線程/進程數 根據實際的業務需求決定