一、Topic 参数
每个 Topic 都能设置自己的参数值，这就是所谓的 Topic 级别参数
1.retention.ms
规定了该 Topic 消息被保存的时长。默认是 7 天，即该 Topic 只保存最近 7 天的消息。一旦设置了这个值，它会覆盖掉 Broker 端的全局参数值。
2.retention.bytes
规定了要为该 Topic 预留多大的磁盘空间。和全局参数作用相似，这个值通常在多租户的 Kafka 集群中会有用武之地。当前默认值是 -1，表示可以无限使用磁盘空间。
3.max.message.bytes
能处理的消息大小;决定 Kafka Broker 能够正常接收该 Topic 的最大消息大小。
Topic 级别参数会覆盖全局 Broker 参数的值
二、设置Topic级别参数
1.创建 Topic 时进行设置
用以下命令来创建 Topic：
bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic transaction --partitions 1 --replication-factor 1 --config retention.ms=15552000000 --config max.message.bytes=5242880
--config:在 config 后面指定了想要设置的 Topic 级别参数。
2.修改 Topic 时设置
自带的命令kafka-configs来修改 Topic 级别参数:
bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name transaction --alter --add-config max.message.bytes=10485760
建议使用第二种方式来设置。
三、JVM 参数
先说说 Java 版本，有条件的话至少使用 Java 8 。
1.堆大小
JVM 堆大小设置成 6GB，这是目前业界比较公认的一个合理值。
2.垃圾回收器的设置
Java 7：
- 如果 Broker 所在机器的 CPU 资源非常充裕，建议使用 CMS 收集器。启用方法是指定
-XX:+UseCurrentMarkSweepGC。 - 否则，使用吞吐量收集器。开启方法是指定
-XX:+UseParallelGC。
Java 8:
可以手动设置使用 G1 收集器。在没有任何调优的情况下，G1 表现得要比 CMS 出色，主要体现在更少的 Full GC，需要调整的参数更少等，所以使用 G1 就好了。
四、设置JVM 参数
-
KAFKA_HEAP_OPTS：指定堆大小。 -
KAFKA_JVM_PERFORMANCE_OPTS：指定 GC 参数。
在启动 Kafka Broker 之前，先设置上这两个环境变量：
$> export KAFKA_HEAP_OPTS=--Xms6g --Xmx6g
$> export KAFKA_JVM_PERFORMANCE_OPTS= -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true
$> bin/kafka-server-start.sh config/server.properties
五、操作系统参数
1.文件描述符限制
通常情况下将它设置成一个超大的值是合理的做法，比如ulimit -n 1000000。
设置这个参数不重要，但不设置的话后果很严重，比如你会经常看到“Too many open files”的错误。
2.文件系统类型
文件系统指的是如 ext3、ext4 或 XFS 这样的日志型文件系统。
XFS 的性能要强于 ext4，所以生产环境最好还是使用 XFS。
3.Swappiness
1.设置成 0，当物理内存耗尽时，操作系统会触发 OOM killer 这个组件，它会随机挑选一个进程然后 kill 掉，即根本不给用户任何的预警。
2.设置成一个比较小的值，当开始使用 swap 空间时，至少能够观测到 Broker 性能开始出现急剧下降，从而给你进一步调优和诊断问题的时间。
建议：将 swappniess 配置成一个接近 0 但不为 0 的值，比如 1。
4.提交时间
Flush 落盘时间。
向 Kafka 发送数据并不是真要等数据被写入磁盘才会认为成功，而是只要数据被写入到操作系统的页缓存（Page Cache）上就可以了，随后操作系统根据 LRU 算法会定期将页缓存上的“脏”数据落盘到物理磁盘上。这个定期就是由提交时间来确定的，默认是 5 秒。一般情况下我们会认为这个时间太频繁了，可以适当地增加提交间隔来降低物理磁盘的写操作。
如果在页缓存中的数据在写入到磁盘前机器宕机了，数据就丢失了。但鉴于 Kafka 在软件层面已经提供了多副本的冗余机制，因此这里稍微拉大提交间隔去换取性能还是一个合理的做法。
极客时间《Kafka 核心技术与实战》学习笔记Day4 - http://gk.link/a/11UOV
网友评论