首页 > 其他分享 >性能调优

性能调优

时间:2023-12-06 17:14:31浏览次数:19  
标签:log ## max 性能 bytes kafka 调优 replica

Broker

线程数

## broker 处理消息的最大线程数,默认为 3,建议设为 cpu 核数 + 1
num.network.threads = 9
## broker 处理磁盘 IO 的线程数,建议设为 cpu 核数 x 2
num.io.threads = 16

数据落盘策略

## 每当producer写入10000条消息时,刷数据到磁盘
log.flush.interval.messages=10000
## 每间隔5秒钟时间,刷数据到磁盘
log.flush.interval.ms=5000

segment 分段存储策略

## 日志滚动的周期时间,到达指定周期时间时,强制生成一个新的segment
log.roll.hours=72

## segment的索引文件最大尺寸限制,即时log.segment.bytes没达到,也会生成一个新的segment
log.index.size.max.bytes=10*1024*1024

## 控制日志segment文件的大小,超出该大小则追加到一个新的日志segment文件中(-1表示没有限制)
log.segment.bytes=1024*1024*1024

日志清理策略

##   开启日志清理
log.cleaner.enable=true

##  日志清理运行的线程数
log.cleaner.threads = 2

##  日志清理策略选择有:delete和compact主要针对过期数据的处理,或是日志文件达到限制的额度,会被 topic创建时的指定参数覆盖,默认 delete
log.cleanup.policy = delete

##  数据文件保留多长时间, 存储的最大时间超过这个时间会根据log.cleanup.policy设置数据清除策略
##  log.retention.bytes和 log.retention.minutes或 log.retention.hours任意一个达到要求,都会执行删除

## 300 分钟
log.retention.minutes=300
## 24小时
log.retention.hours=24

##   topic每个分区的最大文件大小,-1没有大小限
log.retention.bytes=1G

##  文件大小检查的周期时间,是否触发 log.cleanup.policy中设置的策略
log.retention.check.interval.ms=5minutes

基础配置

## 是否允许自动创建topic,若是false,就需要通过命令创建topic
auto.create.topics.enable =true

## 默认副本的数量,可以根据 Broker 的个数进行设置。
default.replication.factor = 3

## 默认,每个topic的分区个数,若是在topic创建时候没有指定的话会被topic创建时的指定参数覆盖
num.partitions = 3

## 消息体的最大大小,单位是字节,如果发送的消息过大,可以适当的增大该参数
message.max.bytes = 6525000

## socket的发送缓冲区的大小
socket.send.buffer.bytes=102400

## socket的接受缓冲区的大小
socket.request.max.bytes=104857600

副本同步策略

## 默认10s,isr中的follow没有向isr发送心跳包就会被移除
replica.lag.time.max.ms = 10000

## 根据leader 和副本的信息条数差值决定是否从isr 中剔除此副本,此信息条数差值根据配置参数,在broker数量较少,或者网络不足的环境中,建议提高此值.
replica.lag.max.messages = 4000

## follower与leader之间的socket超时时间
replica.socket.timeout.ms=30*1000

## 数据同步时的socket缓存大小
replica.socket.receive.buffer.bytes=64*1024

## replicas每次获取数据的最大大小
replica.fetch.max.bytes =1024*1024

## replicas同leader之间通信的最大等待时间,失败了会重试
replica.fetch.wait.max.ms =500

## fetch的最小数据尺寸,如果leader中尚未同步的数据不足此值,将会阻塞,直到满足条件
replica.fetch.min.bytes =1

## leader进行复制的线程数,增大这个数值会增加follower的IO
num.replica.fetchers=1

## 每个replica检查是否将最高水位进行固化的频率
replica.high.watermark.checkpoint.interval.ms = 5000

## leader的不平衡比例,若是超过这个数值,会对分区进行重新的平衡
leader.imbalance.per.broker.percentage = 10

## 检查leader是否不平衡的时间间隔
leader.imbalance.check.interval.seconds = 300

Producer

spring:
  kafka:
    # kafka服务器地址(可以多个)
    bootstrap-servers: 127.0.0.1:9090,127.0.0.1:9091,127.0.0.1:9092
    producer:
      # key/value的序列化
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.apache.kafka.common.serialization.StringSerializer
      # 批量抓取发送的的缓存大小,默认是16kB,意思是缓存中的数据达到配置的数值大小,kafka的生产端发送数据
      batch-size: 65536
      # 缓存容量 默认值为33554432
      # 用于指定producer端用于缓存消息的缓冲区大小,单位为字节,默认值为:33554432  32M。
      # kafka采用的是异步发送的消息架构,producer启动时会首先创建一块内存缓冲区用于保存待发送的消息,
      # 然后由一个专属线程负责从缓冲区读取消息进行真正的发送。
      # 消息持续发送过程中,当缓冲区被填满后,producer立即进入阻塞状态直到空闲内存被释放出来,这段时间不能超过max.blocks.ms设置的值,
      # 一旦超过,producer则会抛出TimeoutException 异常,因为Producer是线程安全的,若一直报TimeoutException,需要考虑调高buffer.memory了。
      # 用户在使用多个线程共享kafka producer时,很容易把 buffer.memory 打满。
      buffer-memory: 524288
      #失败重试次数
      retries: 3
      # ACK
      # 0:Producer 不等待 Broker 的 ACK,这提供了最低延迟,Broker 一收到数据还没有写入磁盘就已经返回,当 Broker 故障时有可能丢失数据。
      # 1:Producer 等待 Broker 的 ACK,Partition 的 Leader 落盘成功后返回 ACK,如果在 Follower 同步成功之前 Leader 故障,那么将会丢失数据。
      # -1(all):Producer 等待 Broker 的 ACK,Partition 的 Leader 和 Follower 全部落盘成功后才返回 ACK。但是在 Broker 发送 ACK 时,Leader 发生故障,则会造成数据重复。
      acks: 1

Consumer

spring:
  kafka:
    bootstrap-servers: 127.0.0.1:9090,127.0.0.1:9091,127.0.0.1:9092
    consumer:
      #用于标识此使用者所属的使用者组的唯一字符串。
      group-id: consumer
      #当Kafka中没有初始偏移量或者服务器上不再存在当前偏移量时该怎么办,默认值为latest,表示自动将偏移重置为最新的偏移量
      #可选的值为latest, earliest, none
      auto-offset-reset: earliest
      #如果'enable.auto.commit'为true,则消费者偏移自动提交给Kafka的频率(以毫秒为单位),默认值为5000。
      auto-commit-interval: 5000ms
      #如果为true,则消费者的偏移量将在后台定期提交,默认值为true
      enable-auto-commit: false
      #如果没有足够的数据立即满足“fetch.min.bytes”给出的要求,服务器在回答获取请求之前将阻塞的最长时间(以毫秒为单位)
      #默认值为500
      fetch-max-wait: 500ms
      #服务器应以字节为单位返回获取请求的最小数据量,默认值为1,对应的kafka的参数为fetch.min.bytes。
      fetch-min-size: 1
      #心跳与消费者协调员之间的预期时间(以毫秒为单位),默认值为3000
      heartbeat-interval: 3000ms
      #密钥的反序列化器类,实现类实现了接口org.apache.kafka.common.serialization.Deserializer
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      #值的反序列化器类,实现类实现了接口org.apache.kafka.common.serialization.Deserializer
      value-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      #一次调用poll()操作时返回的最大记录数,默认值为500
      max-poll-records: 50
    properties:
      max:
        poll:
          interval:
            ms: 600000 #0.10.1.0版本后新增的,这个参数需要根据实际业务处理时间进行设置,一旦Consumer处理不过来,就会被踢出Consumer Group
      session:
        timeout:
          ms: 1800000
    listener:
      # 监听器的 AckMode
      # MANUAL :当每一批poll()的数据被消费者监听器(ListenerConsumer)处理之后, 手动调用Acknowledgment.acknowledge()后提交
      # MANUAL_IMMEDIATE : 手动调用Acknowledgment.acknowledge()后立即提交
      # RECORD : 当每一条记录被消费者监听器(ListenerConsumer)处理之后提交
      # BATCH :当每一批poll()的数据被消费者监听器(ListenerConsumer)处理之后提交
      # TIME 当每一批poll()的数据被消费者监听器(ListenerConsumer)处理之后,距离上次提交时间大于TIME时提交
      # COUNT 当每一批poll()的数据被消费者监听器(ListenerConsumer)处理之后,被处理record数量大于等于COUNT时提交
      ack-mode: manual
      ## poll拉取数据超时时间
      poll-timeout: 600000
      # ack_mode为COUNT/COUNT_TIME 时配置
      ack-count: 10
      # ack_mode为/COUNT_TIME 时配置
      ack-time: 60000

标签:log,##,max,性能,bytes,kafka,调优,replica
From: https://www.cnblogs.com/ding-dang/p/17606081.html

相关文章

  • Vue 应用程序性能优化:代码压缩、加密和混淆配置详解
    ​简介在Vue应用程序的开发中,代码压缩、加密和混淆是优化应用程序性能和提高安全性的重要步骤。VueCLI是一个功能强大的开发工具,它提供了方便的配置选项来实现这些功能。本文将介绍如何使用VueCLI配置代码压缩、加密和混淆功能,以提高应用程序的性能和安全性。一、配置代......
  • Mercury性能测试模板
    xxxxxxxxxx性能测试报告                                                                   2023年11月8日    目 录   1前言   11第一章XXXXXXXX核心业务系统性能测试概述   1......
  • JFrog Artifactory—高性能软件制品管理仓库
    产品概述    JFrogArtifactory是一个可扩展的通用二进制存储库管理器,可在整个应用程序开发和交付过程中自动管理工件和依赖项。JFrogArtifactory支持大多数开发语言,是整个DevOps流水线中大多数软件包、容器映像和Helm图表的单一数据源。Artifactory对元数据和资产具有丰......
  • oracle 性能排查与锁表处理
     在Oracle数据库中,查看SQL语句的执行计划可以帮助我们理解查询的执行方式,以及如何优化查询性能。以下是几种常用的方法来查看Oracle执行计划:使用EXPLAINPLAN使用EXPLAINPLAN语句可以查看SQL查询的执行计划。执行以下步骤: *首先,执行`EXPLAINPLANF......
  • 性能测试必备基础知识(二)
    1.CPU使用率除了空闲时间外的其他时间占总CPU时间的百分比,就是CPU使用率,即1-空闲时间/CPU总时间。当计算CPU使用率时,我们通常使用/proc/stat文件中的数据。该文件提供了有关CPU的计数器信息,包括各种状态下的节拍数。通过cat  /proc/stat命令就可详细查看其信......
  • Kafka集群调优+能力探底
    一、前言我们需要对4个规格的kafka能力进行探底,即其可以承载的最大吞吐;4个规格对应的单节点的配置如下:标准版:2C4G铂金版:4C8G专业版:8C16G企业版:16C32G另外,一般来讲,在同配置下,kafka的读性能是要优于写性能的,写操作时,数据要从网卡拷贝至堆内存,然后进行一堆数据校验、解......
  • hadoop优化之yarn调优
    yarn.nodemanager.resource.memory-mb(重点)表示该节点上YARN可使用的物理内存总量,默认是8192(MB),注意,如果你的节点内存资源不够8GB,则需要调减小这个值,而YARN不会智能的探测节点的物理内存总量。假如服务器内存64G,设置32G。yarn.nodemanager.vmem-pmem-ratio任务每使用1MB物理内存,最......
  • StoneDB-8.0-V2.2.0 企业版正式发布!性能优化,稳定性提升,持续公测中!
    11月,StoneDB新版本如期而至,这一个月来我们的研发同学加班加点,持续迭代:在2.2.0版本中,我们针对用户提出的需求和做出了重量级更新,修复了一些已知和用户反馈的Bug,同时对部分代码进行了重构,新版本还特别针对备库insert的性能进行了大幅提升。欢迎大家下载试用,遇到任何问题都可以......
  • 系统性能提升2 倍以上【FPGA】XCKU5P-L2SFVB784E、XCKU5P-2SFVB784I
    Kintex™UltraScale+™器件在FinFET节点中提供最佳每瓦价格性能比,为需要高端功能(包括33Gb/s收发器和100G连接内核)的应用提供了经济高效的解决方案。最新的中端产品系列同时支持数据包处理和DSP密集型功能,是无线MIMO技术、Nx100G有线网络、以及数据中心网络和存储加速......
  • 亿级访问高并发下如何进行估算和调优
    Java全能学习+面试指南:https://javaxiaobear.cn这篇主要讲解如何在大流量高并发场景下进行估算和调优。我们知道,垃圾回收器一般使用默认参数,就可以比较好的运行。但如果用错了某些参数,那么后果可能会比较严重,我不只一次看到有同学想要验证某个刚刚学到的优化参数,结果引起了线上G......