Kafka 设计解析(五):Kafka Benchmark

阅读数:14364 2016 年 1 月 6 日 16:50

性能测试及集群监控工具

Kafka 提供了非常多有用的工具,如 Kafka 设计解析(三)- Kafka High Availability (下)中提到的运维类工具——Partition Reassign Tool,Preferred Replica Leader Election Tool,Replica Verification Tool,State Change Log Merge Tool。本章将介绍 Kafka 提供的性能测试工具,Metrics 报告工具及 Yahoo 开源的 Kafka Manager。

Kafka 性能测试脚本

  • $KAFKA_HOME/bin/kafka-producer-perf-test.sh 该脚本被设计用于测试 Kafka Producer 的性能,主要输出 4 项指标,总共发送消息量(以 MB 为单位),每秒发送消息量(MB/second),发送消息总数,每秒发送消息数(records/second)。除了将测试结果输出到标准输出外,该脚本还提供 CSV Reporter,即将结果以 CSV 文件的形式存储,便于在其它分析工具中使用该测试结果
  • $KAFKA_HOME/bin/kafka-consumer-perf-test.sh 该脚本用于测试 Kafka Consumer 的性能,测试指标与 Producer 性能测试脚本一样。

Kafka Metrics

Kafka 使用 Yammer Metrics 来报告服务端和客户端的 Metric 信息。Yammer Metrics 3.1.0 提供 6 种形式的 Metrics 收集——Meters,Gauges,Counters,Histograms,Timers,Health Checks。与此同时,Yammer Metrics 将 Metric 的收集与报告(或者说发布)分离,可以根据需要自由组合。目前它支持的 Reporter 有 Console Reporter,JMX Reporter,HTTP Reporter,CSV Reporter,SLF4J Reporter,Ganglia Reporter,Graphite Reporter。因此,Kafka 也支持通过以上几种 Reporter 输出其 Metrics 信息。

使用 JConsole 查看单服务器 Metrics

使用 JConsole 通过 JMX,是在不安装其它工具(既然已经安装了 Kafka,就肯定安装了 Java,而 JConsole 是 Java 自带的工具)的情况下查看 Kafka 服务器 Metrics 的最简单最方便的方法之一。

首先必须通过为环境变量 JMX_PORT 设置有效值来启用 Kafka 的 JMX Reporter。如export JMX_PORT=19797。然后即可使用 JConsole 通过上面设置的端口来访问某一台 Kafka 服务器来查看其 Metrics 信息,如下图所示。

Kafka设计解析(五):Kafka Benchmark

使用 JConsole 的一个好处是不用安装额外的工具,缺点很明显,数据展示不够直观,数据组织形式不友好,更重要的是不能同时监控整个集群的 Metrics。在上图中,在 kafka.cluster->Partition->UnderReplicated->topic4 下,只有 2 和 5 两个节点,这并非因为 topic4 只有这两个 Partition 的数据是处于复制状态的。事实上,topic4 在该 Broker 上只有这 2 个 Partition,其它 Partition 在其它 Broker 上,所以通过该服务器的 JMX Reporter 只看到了这两个 Partition。

通过 Kafka Manager 查看整个集群的 Metrics

Kafka Manager 是 Yahoo 开源的 Kafka 管理工具。它支持如下功能:

  • 管理多个集群
  • 方便查看集群状态
  • 执行 preferred replica election
  • 批量为多个 Topic 生成并执行 Partition 分配方案
  • 创建 Topic
  • 删除 Topic(只支持 0.8.2 及以上版本,同时要求在 Broker 中将delete.topic.enable设置为 true)
  • 为已有 Topic 添加 Partition
  • 更新 Topic 配置
  • 在 Broker JMX Reporter 开启的前提下,轮询 Broker 级别和 Topic 级别的 Metrics
  • 监控 Consumer Group 及其消费状态
  • 支持添加和查看 LogKafka

安装好 Kafka Manager 后,添加 Cluster 非常方便,只需指明该 Cluster 所使用的 Zookeeper 列表并指明 Kafka 版本即可,如下图所示。

Kafka设计解析(五):Kafka Benchmark

这里要注意,此处添加 Cluster 是指添加一个已有的 Kafka 集群进入监控列表,而非通过 Kafka Manager 部署一个新的 Kafka Cluster,这一点与 Cloudera Manager 不同。

Kafka Benchmark

Kafka 的一个核心特性是高吞吐率,因此本文的测试重点是 Kafka 的吞吐率。

本文的测试共使用 6 台安装 Red Hat 6.6 的虚拟机,3 台作为 Broker,另外 3 台作为 Producer 或者 Consumer。每台虚拟机配置如下:

  • CPU:8 vCPU, Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz,2 Sockets,4 Cores per socket,1 Thread per core
  • 内存:16 GB
  • 磁盘:500 GB

开启 Kafka JMX Reporter 并使用 19797 端口,利用 Kafka-Manager 的 JMX polling 功能监控性能测试过程中的吞吐率。

本文主要测试如下四种场景,测试的指标主要是每秒多少兆字节数据,每秒多少条消息。

Producer Only

这组测试不使用任何 Consumer,只启动 Broker 和 Producer。

Producer Number VS. Throughput

实验条件:3 个 Broker,1 个 Topic,6 个 Partition,无 Replication,异步模式,消息 Payload 为 100 字节。

测试项目:分别测试 1,2,3 个 Producer 时的吞吐量。

测试目标:如 Kafka 设计解析(一)- Kafka 背景及架构介绍所介绍,多个 Producer 可同时向同一个 Topic 发送数据,在 Broker 负载饱和前,理论上 Producer 数量越多,集群每秒收到的消息量越大,并且呈线性增涨。本实验主要验证该特性。同时作为性能测试,本实验还将监控测试过程中单个 Broker 的 CPU 和内存使用情况

测试结果:使用不同个数 Producer 时的总吞吐率如下图所示

Kafka设计解析(五):Kafka Benchmark

由上图可看出,单个 Producer 每秒可成功发送约 128 万条 Payload 为 100 字节的消息,并且随着 Producer 个数的提升,每秒总共发送的消息量线性提升,符合之前的分析。

性能测试过程中,Broker 的 CPU 和内存使用情况如下图所示。

(点击放大图像)

Kafka设计解析(五):Kafka Benchmark

由上图可知,在每秒接收约 117 万条消息(3 个 Producer 总共每秒发送 350 万条消息,平均每个 Broker 每秒接收约 117 万条)的情况下,一个 Broker 的 CPU 使用量约为 248%,内存使用量为 601 MB。

Message Size VS. Throughput

实验条件:3 个 Broker,1 个 Topic,6 个 Partition,无 Replication,异步模式,3 个 Producer。

测试项目:分别测试消息长度为 10,20,40,60,80,100,150,200,400,800,1000,2000,5000,10000 字节时的集群总吞吐量。

测试结果:不同消息长度时的集群总吞吐率如下图所示:

Kafka设计解析(五):Kafka Benchmark

由上图可知,消息越长,每秒所能发送的消息数越少,而每秒所能发送的消息的量(MB)越大。另外,每条消息除了 Payload 外,还包含其它 Metadata,所以每秒所发送的消息量比每秒发送的消息数乘以 100 字节大,而 Payload 越大,这些 Metadata 占比越小,同时发送时的批量发送的消息体积越大,越容易得到更高的每秒消息量(MB/s)。其它测试中使用的 Payload 为 100 字节,之所以使用这种短消息(相对短)只是为了测试相对比较差的情况下的 Kafka 吞吐率。

Partition Number VS. Throughput

实验条件:3 个 Broker,1 个 Topic,无 Replication,异步模式,3 个 Producer,消息 Payload 为 100 字节。

测试项目:分别测试 1 到 9 个 Partition 时的吞吐量。

测试结果:不同 Partition 数量时的集群总吞吐率如下图所示:

Kafka设计解析(五):Kafka Benchmark

由上图可知,当 Partition 数量小于 Broker 个数(3 个)时,Partition 数量越大,吞吐率越高,且呈线性提升。本文所有实验中,只启动 3 个 Broker,而一个 Partition 只能存在于 1 个 Broker 上(不考虑 Replication。即使有 Replication,也只有其 Leader 接受读写请求),故当某个 Topic 只包含 1 个 Partition 时,实际只有 1 个 Broker 在为该 Topic 工作。如之前文章所讲,Kafka 会将所有 Partition 均匀分布到所有 Broker 上,所以当只有 2 个 Partition 时,会有 2 个 Broker 为该 Topic 服务。3 个 Partition 时同理会有 3 个 Broker 为该 Topic 服务。换言之,Partition 数量小于等于 3 个时,越多的 Partition 代表越多的 Broker 为该 Topic 服务。如前几篇文章所述,不同 Broker 上的数据并行插入,这就解释了当 Partition 数量小于等于 3 个时,吞吐率随 Partition 数量的增加线性提升。

当 Partition 数量多于 Broker 个数时,总吞吐量并未有所提升,甚至还有所下降。可能的原因是,当 Partition 数量为 4 和 5 时,不同 Broker 上的 Partition 数量不同,而 Producer 会将数据均匀发送到各 Partition 上,这就造成各 Broker 的负载不同,不能最大化集群吞吐量。而上图中当 Partition 数量为 Broker 数量整数倍时吞吐量明显比其它情况高,也证实了这一点。

Replica Number VS. Throughput

实验条件:3 个 Broker,1 个 Topic,6 个 Partition,异步模式,3 个 Producer,消息 Payload 为 100 字节。

测试项目:分别测试 1 到 3 个 Replica 时的吞吐率。

测试结果:如下图所示:

Kafka设计解析(五):Kafka Benchmark

由上图可知,随着 Replica 数量的增加,吞吐率随之下降。但吞吐率的下降并非线性下降,因为多个 Follower 的数据复制是并行进行的,而非串行进行。

Consumer Only

实验条件:3 个 Broker,1 个 Topic,6 个 Partition,无 Replication,异步模式,消息 Payload 为 100 字节。

测试项目:分别测试 1 到 3 个 Consumer 时的集群总吞吐率。

测试结果:在集群中已有大量消息的情况下,使用 1 到 3 个 Consumer 时的集群总吞吐量如下图所示:

Kafka设计解析(五):Kafka Benchmark

由上图可知,单个 Consumer 每秒可消费 306 万条消息,该数量远大于单个 Producer 每秒可消费的消息数量,这保证了在合理的配置下,消息可被及时处理。并且随着 Consumer 数量的增加,集群总吞吐量线性增加。

根据 Kafka 设计解析(四)- Kafka Consumer 设计解析所述,多 Consumer 消费消息时以 Partition 为分配单位,当只有 1 个 Consumer 时,该 Consumer 需要同时从 6 个 Partition 拉取消息,该 Consumer 所在机器的 I/O 成为整个消费过程的瓶颈,而当 Consumer 个数增加至 2 个至 3 个时,多个 Consumer 同时从集群拉取消息,充分利用了集群的吞吐率。

Producer Consumer pair

实验条件:3 个 Broker,1 个 Topic,6 个 Partition,无 Replication,异步模式,消息 Payload 为 100 字节。

测试项目:测试 1 个 Producer 和 1 个 Consumer 同时工作时 Consumer 所能消费到的消息量。

测试结果:1,215,613 records/second。

作者简介

郭俊(Jason),硕士,从事大数据平台研发工作,精通 Kafka 等分布式消息系统,Storm 等流式处理系统及数据仓库性能调优。

个人博客: http://www.jasongj.com

新浪微博:郭俊_Jason

微信: habren

公众号:大数据架构


感谢郭蕾对本文的策划和审校。

给 InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群Kafka设计解析(五):Kafka Benchmark(已满),InfoQ 读者交流群(#2)Kafka设计解析(五):Kafka Benchmark)。

评论

发布