kafka性能关键参数配置指导

南墨1年前技术文章791

本文为kafka调优过程中主要参数以及参数相关释意,在遇到kafak性能问题时可优先调整一下参数

1.Broker参数指导

KAFKA_HEAP_OPTS:-Xmx6G
    在producer异步发送模式下对内存消耗要求较大,建议修改该参数为-Xmx4G,实际测试中可以进一步调大观察性能选择一个合适的值。
num.io.threads:8
    Broker用来处理磁盘I/O的线程数目,这个线程数目建议设置为磁盘个数*2
num.network.threads:3
    用于接收并处理网络请求的线程数,默认为3。其内部实现是采用Selector模型。启动一个线程作为Acceptor来负责建立连接,再配合启动num.network.threads个线程来轮流负责从Sockets里读取请求,建议配置为CPU核数加1
num.partitions:2
    指定由服务端自动创建Topic时的默认分区数。如果对TopicPartition未做部署规划,由服务端自动创建,则会以此参数创建Partition个数,Partition的数量会直接影响到Kafka集群的吞吐性能。在集群总Partition的数量可控的情况下尽量增大单个Topic的数量可以增加集群的吞吐性能。 建议在创建Topic时根据性能需求规划该参数,使用客户端命令行去规划创建,不建议由Kafka自动创建。
num.replica.fetchers:1
    对于任意(Broker, Leader)元组,都会有replication.factor-1Broker作为Replica,在Replica上会启动若干Fetch线程把对应的数据同步到本地,而num.replica.fetchers这个参数是用来控制Fetch线程的数量。 一般来说如果发现PartitionISR当中只有自己一个Partition,且长时间没有新的Replica增加进来时,单个broker上的partition数量较多(上千个以上)时就可以考虑适当的增大这个参数加快复制进度。
default.replication.factor:2
    此参数对应于num.partitions,都是由Kafka自动创建Topic时使用,一般建议在保持默认值2即可。
compression.type:producer
    指定Topic最终的数据压缩方式,如果设置为producer,那么将保留Producer的压缩方式。默认发送不进行压缩,推荐配置一种适合的压缩算法,可以大幅度的减缓网络压力和Broker的存储压力。常用的压缩方式是snappy。配置压缩后Consumer端进行消费不需要进行额外的设置可以跟不压缩的消息一样进行数据消费。
zookeeper.connection.timeout.ms
    Broker连接ZooKeeper的超时时间,单位毫秒。现网的网络环境比较复杂,建议将该值调整为9000090s),以提高Kafka集群的可靠性,避免BrokerZooKeeper的连接出现间歇性的出现闪断现象。
zookeeper.session.timeout.ms
    BrokerZooKeeper之间的会话超时时间,单位毫秒。如果Broker在此时间内未向ZooKeeper上报心跳,则被认为失效。建议调整为9000090s)。

2.Producer参数配置

producer.type
    建议可靠性要求高的消息配置为sync同步模式发送,可靠性要求低的消息发送配置为async异步模式发送性能较高可靠性低,在异常情况下会丢失部分数据。
request.required.acks
    这个配置可以设定发送消息后是否需要Broker端返回确认。
          0:不需要进行确认,速度最快。存在丢失数据的风险。
         1:仅需要Leader进行确认,不需要ISR进行确认。是一种效率和安全折中的方式。
        all:需要ISR中所有的Replica给予接收确认,速度最慢,安全性最高,但是由于ISR可能会缩小到仅包含一个Replica,所以设置参数为all并不能一定避免数据丢失。
    对于概率统计类应用即使丢失少量数据也不影响统计分析结果建议配置acks0,可以获得较高的性能;对于对消息要求较高的应用配置acksall可以获得较高的可靠性但是会大大降低性能。
compression.codec:none
    Message落地时是否采用以及采用何种压缩算法。一般都是把Producer发过来Message直接保存,不再改变压缩方式。
linger.ms:0
    Producer默认会把两次发送时间间隔内收集到的所有Requests进行一次聚合然后再发送,以此提高吞吐量,而linger.ms则更进一步,这个参数为每次发送增加一些delay,以此来聚合更多的Message
compression.type:none
    指定producer生成的数据是否进行压缩后发送给服务端(broker)默认发送不进行压缩,推荐配置一种适合的压缩算法(常用snappy,性能较好),可以大幅度的减缓网络压力和Broker的存储压力。

3. Consumer参数配置

num.consumer.fetchers:1
    启动Consumer的个数,适当增加可以提高并发度,以提高数据消费的吞吐量。 对应的需要增大consumer的内存配置。
fetch.min.bytes:1
    每次Fetch Request至少要拿到多少字节的数据才可以返回。 适当增大每次获取的数据可以提高数据消费的吞吐量。该值设置过大又会导致时延过大,需要结合下面一个参数使用。
fetch.wait.max.ms:500
    在Fetch Request获取的数据至少达到fetch.min.bytes之前,允许等待的最大时长。如果该值设置的太大在数据量较小的情况下会导致时延过大。


相关文章

HDP实操--NameNode开启高可用

HDP实操--NameNode开启高可用

为了确定在namenode组件失败后集群中有其他的namenode可以工作,需要对hdp集群配置高可用,当前我们配置的非安全集群的高可用。前置条件:(1)确保你的集群至少有3个节点并且至少有3个Apa...

数据湖技术之iceberg(十三)Iceberg与Hudi对比

Iceberg和Hudi都是数据湖技术,从社区活跃度上来看,Iceberg有超越Hudi的趋势。他们有以下共同点:l   都是构建于存储格式之上的数据组织方式l &nbs...

大数据即席查询-Presto

一、Presto 概念Presto 是一个开源的分布式 SQL 查询引擎,数据量支持 GB 到 PB 字节,主要用来秒级查询的场景。注:虽然 Presto 可以解析 SQL,但它不是一个标准的数据库。...

Atlas集成HBase

Atlas集成HBase

1 集成原理 Atlas HBase hook与HBase master注册为协处理器。在检测到对HBase名称空间/表/列族的更改时, Atlas Hook过Kafka通知更新Atlas中的元数据。...

Python 序列化与反序列化

1、为什么要序列化内存中的字典、列表、集合以及各种对象,如何保存到一个文件中?如果是自己定义的类的实例,如何保存到一个文件中?如何从文件中读取数据,并让它们在内存中再次恢复成自己对应的类的实例?要设计...

Oracle数据库恢复演练

1、演练目的验证核心系统数据库备份的有效性,在极端数据库故障情况下保证数据库存在一份可用的备份文件,为业务数据的安全提供保障。 2、演练准备提供一台2C16G本地60G的阿里ecs服务器,操...

发表评论    

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。