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