一、Kafka集群参数调优
1、JVM参数调忧
默认启动的Broker进程只会使用1G内存,在实际使用中会导致进程频繁GC,影响Kafka集群的性能和稳定性
通过jstat -gcutil 1000查看到kafka进程GC情况
主要看YGC,YGCT,FGC,FGCT这几个参数,如果这几个值不是很大,就没什么问题。
YGC:young gc发生的次数
YGCT:young gc消耗的时间
FGC:full gc发生的次数
FGCT:full gc消耗的时间
[root@bigdata01 kafka_2.12-2.4.1]# jps
13248 Kafka
18087 Jps
1679 QuorumPeerMain
[root@bigdata01 kafka_2.12-2.4.1]# jstat -gcutil 13248 1000
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 100.00 78.00 14.50 89.97 92.39 28 0.563 0 0.000 0.563
0.00 100.00 78.00 14.50 89.97 92.39 28 0.563 0 0.000 0.563
0.00 100.00 78.00 14.50 89.97 92.39 28 0.563 0 0.000 0.563
0.00 100.00 78.00 14.50 89.97 92.39 28 0.563 0 0.000 0.563
0.00 100.00 78.00 14.50 89.97 92.39 28 0.563 0 0.000 0.563
0.00 100.00 78.00 14.50 89.97 92.39 28 0.563 0 0.000 0.563
如果你发现YGC很频繁,或者FGC很频繁,就说明内存分配的少了
此时需要修改kafka-server-start.sh中的 KAFKA_HEAP_OPTS。
export KAFKA_HEAP_OPTS="-Xmx10g -Xms10g -XX:MetaspaceSize=96m -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:G1HeapRegionSize=16M -XX:MinMetaspaceFreeRatio=50 -XX:MaxMetaspaceFreeRatio=80"
这个配置表示给kafka分配了10G内存,我们的Kafka服务器是16G内存。
2、Replication参数调忧
replica.socket.timeout.ms=60000
这个参数的默认值是30秒,它是控制partiton副本之间socket通信的超时时间,如果设置的太小,有可能会由于网络原因导致造成误判,认为某一个partition副本连不上了。
replica.lag.time.max.ms=50000
如果一个副本在指定的时间内没有向leader节点发送任何请求,或者在指定的时间内没有同步完leader中的数据,则leader会将这个节点从Isr列表中移除。
这个参数的值默认为10秒。
如果网络不好,或者kafka压力较大,建议调大该值,否则可能会频繁出现副本丢失,进而导致集群需要频繁复制副本,导致集群压力更大,会陷入一个恶性循环。
3、Log参数调忧
这块是针对Kafka中数据文件的删除时机进行设置,不是对kafka本身的日志参数配置。
log.retention.hours=24
这个参数默认值为168,单位是小时,就是7天,默认对数据保存7天,可以在这调整数据保存的时间,我们在实际工作中改为了只保存1天,因为kafka中的数据我们会在hdfs中进行备份,保存一份,所以就没有必要在kafka中保留太长时间了。
在kafka中保留只是为了能够让你在指定的时间内恢复数据,或者重新消费数据,如果没有这种需求,那就没有必要设置太长时间。
注意:
这里分析的Replication的参数和Log参数都是在server.properties文件中进行配置。
JVM参数是在kafka-server-start.sh脚本中配置。
二、Kafka Topic命名小技巧
针对Kafka中Topic命名的小技巧
建议在给topic命名的时候在后面跟上r2p10之类的内容
r2:表示Partition的副本因子是2
p10:表示这个Topic的分区数是10
这样的好处是后期我们如果要写消费者消费指定topic的数据,通过topic的名称我们就知道应该设置多少个消费者消费数据效率最高。
因为一个partition同时只能被一个消费者消费,所以效率最高的情况就是消费者的数量和topic的分区数量保持一致。
在这里通过topic的名称就可以直接看到,一目了然。
但是也有一个缺点,就是后期如果我们动态调整了topic的partiton,那么这个topic名称上的partition数量就不准了,针对这个topic,建议大家一开始的时候就提前预估一下,可以多设置一些partition,我们在工作中的时候针对一些数据量比较大的topic一般会设置4050个partition,数据量少的topic一般设置510个partition,这样后期调整topic partiton数量的场景就比较少了。