Kafka -- 调优

调优目标

  1. 主要目标:高吞吐量低延时
  2. 吞吐量
    • TPS,指的是Broker端进程或Client端应用程序每秒能处理的字节数消息数
  3. 延时,可以有两种理解
    • Producer发送消息Broker持久化完成之间的时间间隔
    • 端到端的延时,即从Producer发送消息Consumer成功消费该消息的总时长

优化漏斗

优化漏斗是调优过程中的分层漏斗,层级越靠上,调优的效果越明显

操作系统层

  1. mount -o noatime
    • 挂载文件系统时禁用atime(Access Time)更新,记录的是文件最后被访问的时间
    • 记录atime需要操作系统访问inode资源,禁用atime可以避免inode访问时间的写入操作
  2. 文件系统选择ext4XFSZFS
  3. swappiness设置成一个很小的值(1~10,默认是60),防止Linux的OOM Killer开启随机杀掉进程
    • swappiness=0,并不会禁止对swap的使用,只是最大限度地降低使用swap的可能性
      • 因为一旦设置为0,当物理内存耗尽时,操作系统会触发OOM Killer
      • OOM Killer会随机挑选一个进程然后kill掉,不会给出任何预警
    • swappiness=N,表示内存使用(100-N)%时,开始使用Swap
  4. ulimit -n设置大一点,否则可能会出现Too Many File Open错误
  5. vm.max_map_count也设置大一点(如655360,默认值65530)
    • 在一个主题数超多的机器上,可能会碰到OutOfMemoryError:Map failed错误
  6. 页缓存大小
    • 给Kafka预留的页缓存至少也要容纳一个日志段的大小(log.segment.bytes,默认值为1GB
    • 消费者程序在消费时能直接命中页缓存,从而避免昂贵的物理磁盘IO操作

JVM层

  1. 堆大小,经验值为6~8GB
    • 如果需要精确调整,关注Full GC后堆上存活对象的总大小,然后将堆大小设置为该值的1.5~2倍
    • jmap -histo:live <pid>可以人为触发Full GC
  2. 选择垃圾收集器
    • 推荐使用G1,主要原因是优化难度比CMS小
    • 如果使用G1后,频繁Full GC,配置-XX:+PrintAdaptiveSizePolicy,查看触发Full GC的原因
    • 使用G1的另一个问题是大对象,即too many humongous allocations
      • 大对象一般指的是至少占用半个Region大小的对象,大对象会被直接分配在大对象区
      • 可以适当增大-XX:+G1HeapRegionSize=N
  3. 尽量避免Full GC!!

框架层

尽量保持客户端版本和Broker端版本一致,否则可能会丧失很多性能收益,如Zero Copy

应用程序层

  1. 不要频繁创建Producer和Consumer对象实例,构造这些对象的开销很大
  2. 用完及时关闭
    • Producer对象和Consumer对象会创建很多物理资源,如Socket连接、ByteBuffer缓冲区,很容易造成资源泄露
  3. 合理利用多线程来改善性能,Kafka的Java Producer是线程安全的,而Java Consumer不是线程安全的

性能指标调优

TPS != 1000 / Latency(ms)**

  1. 假设Kafka Producer以2ms的延时来发送消息,如果每次都只发送一条消息,那么TPS=500
  2. 但如果Producer不是每次只发送一条消息,而是在发送前等待一段时间,然后统一发送一批消息
  3. 如Producer每次发送前等待8ms,总共缓存了1000条消息,总延时累加到了10ms,但TPS=100,000
    • 虽然延时增加了4倍,但TPS却增加了200倍,这就是批次化微批次化的优势
    • 用户一般愿意用较小的延时增加的代价,去换取TPS的显著提升,Kafka Producer就是采用了这样的思路
    • 基于的前提:内存操作(几百纳秒)和网络IO操作(毫秒甚至秒级)的时间量级不同

调优吞吐量

  1. Broker端
    • 适当增加num.replica.fetchers(默认值为1),但不用超过CPU核数
      • 生产环境中,配置了acks=all的Producer程序吞吐量被拖累的首要因素,就是副本同步性能
    • 调优GC参数避免频繁Full GC
  2. Producer端
    • 适当增加batch.size(默认值为16KB,可以增加到512KB1MB
      • 增加消息批次的大小
    • 适当增加linger.ms(默认值为0,可以增加到10~100)
      • 增加消息批次的缓存时间
    • 修改compression.type(默认值为none,可以修改为lz4zstd,适配最好)
    • 修改acks(默认值为1,可以修改为01
      • 优化的目标是吞吐量,不要开启acks=all(引入的副本同步时间通常是吞吐量的瓶颈)
    • 修改retries(修改为0
      • 优化的目标是吞吐量,不要开启重试
    • 如果多线程共享同一个Producer,增加buffer.memory(默认为32MB
      • TimeoutException:Failed to allocate memory within the configured max blocking time
  3. Consumer端
    • 采用多Consumer进程或线程同时消费数据
    • 适当增加fetch.min.bytes(默认值为1Byte,可以修改为1KB或更大)

调优延时

  1. Broker端
    • 适当增加num.replica.fetchers
  2. Producer端
    • 设置linger.ms=0
    • 设置compression.type=none
      • 压缩会消耗CPU时间
    • 设置acks=1
  3. Consumer端
    • 设置fetch.min.bytes=1
0%