Kafka——系统调优
操作系统调优
-
文件描述符限制
ulimit -n 的默认值是1024,此值如果设置得太小,你会碰到 Too Many File Open 这类的错误。因此,我建议在生产环境中适当调大此值,比如将其设置为 655360。
vim /etc/security/limits.conf # 加入以下配置,重启机器生效 * soft nofile 655350 * hard nofile 655350
-
文件系统类型
至于文件系统,我建议你至少选择 ext4 或 XFS。尤其是 XFS 文件系统,它具有高性能、高伸缩性等特点,特别适用于生产服务器。
-
Swappiness
建议将 swappiness 设置成一个很小的值,比如 1~10 之间,以防止 Linux 的 OOM Killer 开启随意杀掉进程。
vim /etc/sysctl.conf
# 加入以下配置,重启机器生效
vm.swappiness=N
-
max_map_count
此值如果太小,在一个主题数超多的 Broker 机器上,你会碰到 OutOfMemoryError:Map failed 的严重错误,因此,我建议在生产环境中适当调大此值,比如将其设置为 655360。
vim /etc/sysctl.conf # 加入以下配置,重启机器生效 vm.max_map_count=655360
-
操作系统页缓存大小
给 Kafka 预留的页缓存越大越好,最小值至少要容纳一个日志段的大小,也就是 Broker 端参数 log.segment.bytes 的值。
该参数的默认值是 1GB。预留出一个日志段大小,至少能保证 Kafka 可以将整个日志段全部放入页缓存,
这样,消费者程序在消费时能直接命中页缓存,从而避免昂贵的物理磁盘 I/O 操作。
JVM 层调优
-
设置堆大小
如果使用的CMS GC算法,建议JVM Heap不要太大,堆大小设置成 6~8GB。在很多公司的实际环境中,这个大小已经被证明是非常合适的,你可以安心使用。
如果你想精确调整的话,我建议你可以查看 GC log,特别是关注 Full GC 之后堆上存活对象的总大小,然后把堆大小设置为该值的 1.5~2 倍。
如果你发现 Full GC 没有被执行过,手动运行 jmap -histo:live < pid > 就能人为触发 Full GC。
JVM太大,导致Major GC或者Full GC产生的“stop the world”时间过长,导致broker和zk之间的session超时,比如重新选举controller节点和提升follow replica为leader replica。
JVM也不能过小,否则会导致频繁地触发gc操作,也影响Kafka的吞吐量。
-
GC 收集器的选择
我强烈建议你使用 G1 收集器,主要原因是方便省事,至少比 CMS 收集器的优化难度小得多。另外,你一定要尽力避免 Full GC 的出现。
其实,不论使用哪种收集器,都要竭力避免 Full GC。在 G1 中,Full GC 是单线程运行的,它真的非常慢。
如果你的 Kafka 环境中经常出现 Full GC,你可以配置 JVM 参数 -XX:+PrintAdaptiveSizePolicy,来探查一下到底是谁导致的 Full GC。
-
设置方法
修改启动脚本bin/kafka-server-start.sh 中的变量值:
export KAFKA_HEAP_OPTS="-Xms6G -Xmx6G -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true"
打开JMX端口
主要是为了通过JMX端口监控Kafka Broker信息。可以在bin/kafka-server-start.sh中打开JMX端口变量。
export JMX_PORT=9999