添加:2021/04/22
修改: -
kafka單機壓力測試
由于kafka吞吐量特別大,所以先考慮集群服務(wù)器的自身瓶頸,因為現(xiàn)在測試的是單機所以只會涉及到磁盤IO以及cpu,但是對于kafka來說對于cpu的使用還是可以忽略不計的,
1.測試機磁盤IO瓶頸
1.1磁盤IO寫入瓶頸
使用以下命令測試磁盤IO的寫入瓶頸
sync;time -p bash -c "(dd if=/dev/zero of=test.dd bs=1M count=20000)"
說明: 在當前目錄下創(chuàng)建一個test.dd的文件,寫入20000個1M的數(shù)據(jù)
磁盤寫入IO的結(jié)果
可以看到平均就是187MB/s
1.2 使用iostat命令監(jiān)測磁盤io情況
使用命令
# iostat -x 1
說明: 擴展查看io性能,每秒刷新一次
注意: 如果沒有iostat,請執(zhí)行yum install sysstat -y進行安裝 iostat命令
關(guān)注wkB/s和%util兩個參數(shù)
wkB/s：每秒寫入設(shè)備的數(shù)據(jù)量（單位：KB）
%util：消耗在I/O請求中的CPU時間百分比（設(shè)備帶寬利用率）舔痪。如果該值接近100%說明設(shè)備出現(xiàn)了瓶頸寓调。
如圖現(xiàn)在這臺機器的磁盤IO極限值為187MB/s
1.3 單機版測試kafka性能
因為測試的次數(shù)比較多,也沒有去找kafka中數(shù)據(jù)存儲設(shè)置,所以就使用docker部署單機版的kafka (因為測試的數(shù)據(jù)比較多,也就多次的刪除了容器,重新啟動鏡像)
新建目錄:
mkdir /usr/local/kafka_test
dockerfile
FROM ubuntu:16.04
# 修改更新源為阿里云
ADD sources.list /etc/apt/sources.list
ADD kafka_2.12-2.5.1.tgz /
# 安裝jdk
RUN apt-get update && apt-get install -y openjdk-8-jdk --allow-unauthenticated && apt-get clean all
EXPOSE 9092
# 添加啟動腳本
ADD run.sh .
RUN chmod 755 run.sh
ENTRYPOINT [ "/run.sh"]
run.sh
#!/bin/bash
# 啟動自帶的zookeeper
cd /kafka_2.12-2.5.1
bin/zookeeper-server-start.sh config/zookeeper.properties &
# 啟動kafka
sleep 3
bin/kafka-server-start.sh config/server.properties
sources.list
deb http://mirrors.aliyun.com/ubuntu/ xenial main restricted
deb http://mirrors.aliyun.com/ubuntu/ xenial-updates main restricted
deb http://mirrors.aliyun.com/ubuntu/ xenial universe
deb http://mirrors.aliyun.com/ubuntu/ xenial-updates universe
deb http://mirrors.aliyun.com/ubuntu/ xenial multiverse
deb http://mirrors.aliyun.com/ubuntu/ xenial-updates multiverse
deb http://mirrors.aliyun.com/ubuntu/ xenial-backports main restricted universe multiverse
deb http://mirrors.aliyun.com/ubuntu xenial-security main restricted
deb http://mirrors.aliyun.com/ubuntu xenial-security universe
deb http://mirrors.aliyun.com/ubuntu xenial-security multiverse
目錄結(jié)構(gòu)如下:
./
├── dockerfile
├── kafka_2.12-2.5.1.tgz
├── run.sh
└── sources.list
生成鏡像
docker build -t kafka_test /usr/local/kafka_test
啟動kafka
docker run -d -it kafka_test
測試結(jié)果
| 寫入消息量級 | 分區(qū)數(shù) | 寫入消息數(shù)量/s | MB/s | 平均延遲 | 最大延遲 |
|---|---|---|---|---|---|
| 10W | 1 | 39169.604387 records/sec | 37.36 MB/sec | 651.38 ms avg latency | 1159.00 ms max latency |
| 100W | 1 | 116577.290744 records/sec | 111.18 MB/sec | 264.15 ms avg latency | 548.00 ms max latency |
| 1000W | 1 | 145365.740202 records/sec | 138.63 MB/sec | 223.76 ms avg latency | 1102.00 ms max latency |
| 1000W | 2 | 169241.965238 records/sec | 161.40 MB/sec | 191.89 ms avg latency | 4675.00 ms max latency |
| 1000W | 3 | 180011.520737 records/sec | 171.67 MB/sec | 180.26 ms avg latency | 4732.00 ms max latency |
| 1000W | 4 | 199612.751263 records/sec | 190.37 MB/sec | 162.44 ms avg latency | 5892.00 ms max latency |
| 1000W | 5 | 197949.245813 records/sec | 188.78 MB/sec | 163.77 ms avg latency | 8729.00 ms max latency |
從表格中可以看出來五個分區(qū)就已經(jīng)是極限了
結(jié)果分析
這中間并沒有設(shè)置條數(shù)/每秒,所以就是按照kafka 就會按照量級自動的吞入數(shù)據(jù),如果我們需要對于消息的即時性做控制,還需要再重新測試一下,按照業(yè)務(wù)的延遲找到最合適的數(shù)量(單機版,然后再部署集群,測試適合的數(shù)量)
集群測試:
部署就不再這里說明了
本次測試的是三臺機器集群
測試結(jié)果:
| 寫入消息量級 | 分區(qū)數(shù) | 寫入消息數(shù)量/s | MB/s | 平均延遲 | 最大延遲 |
|---|---|---|---|---|---|
| 1000W | 1 | 183096.528490 records/sec | 174.61 MB/sec | 177.43 ms avg latency | 923.00 ms max latency |
| 1000W | 3 | 422922.393741 records/sec | 403.33 MB/sec | 76.06 ms avg latency | 385.00 ms max latency |
| 1000W | 5 | 453638.178189 records/sec | 432.62 MB/sec | 69.35 ms avg latency | 1708.00 ms max latency |
之后還測試了9個分區(qū)的topic 因為空間不足所以就沒有繼續(xù)測下去,但是看部分數(shù)據(jù)還超過了500MB/s還是有上升空間的
1.3 磁盤IO 讀取瓶頸
使用一下命令測試磁盤IO的讀取瓶頸
hdparm -tT --direct /dev/vda
說明: hdparm命令是顯示與設(shè)定硬盤的參數(shù), -t參數(shù)為評估硬盤的讀取效率(不經(jīng)過磁盤cache), -T參數(shù)為評估硬盤的讀取效率(經(jīng)過磁盤cache).
