添加:2021/04/22
修改: -
kafka单机压力测试
由于kafka吞吐量特别大,所以先考虑集群服务器的自身瓶颈,因为现在测试的是单机所以只会涉及到磁盘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)"
说明: 在当前目录下创建一个test.dd的文件,写入20000个1M的数据
磁盘写入IO的结果
可以看到平均就是187MB/s
1.2 使用iostat命令监测磁盘io情况
使用命令
# iostat -x 1
说明: 扩展查看io性能,每秒刷新一次
注意: 如果没有iostat,请执行yum install sysstat -y进行安装 iostat命令
关注wkB/s和%util两个参数
wkB/s：每秒写入设备的数据量（单位：KB）
%util：消耗在I/O请求中的CPU时间百分比（设备带宽利用率）。如果该值接近100%说明设备出现了瓶颈。
如图现在这台机器的磁盘IO极限值为187MB/s
1.3 单机版测试kafka性能
因为测试的次数比较多,也没有去找kafka中数据存储设置,所以就使用docker部署单机版的kafka (因为测试的数据比较多,也就多次的删除了容器,重新启动镜像)
新建目录:
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
目录结构如下:
./
├── 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
测试结果
| 写入消息量级 | 分区数 | 写入消息数量/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 |
从表格中可以看出来五个分区就已经是极限了
结果分析
这中间并没有设置条数/每秒,所以就是按照kafka 就会按照量级自动的吞入数据,如果我们需要对于消息的即时性做控制,还需要再重新测试一下,按照业务的延迟找到最合适的数量(单机版,然后再部署集群,测试适合的数量)
集群测试:
部署就不再这里说明了
本次测试的是三台机器集群
测试结果:
| 写入消息量级 | 分区数 | 写入消息数量/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个分区的topic 因为空间不足所以就没有继续测下去,但是看部分数据还超过了500MB/s还是有上升空间的
1.3 磁盘IO 读取瓶颈
使用一下命令测试磁盘IO的读取瓶颈
hdparm -tT --direct /dev/vda
说明: hdparm命令是显示与设定硬盘的参数, -t参数为评估硬盘的读取效率(不经过磁盘cache), -T参数为评估硬盘的读取效率(经过磁盘cache).
