Kafka调优

Swap机制

当物理内存使用达到一定的比例后，Linux就会使用进行swap，使用磁盘作为虚拟内存。
通过

cat /proc/sys/vm/swappiness

可以看到swap参数。

这个参数表示虚拟内存中swap磁盘占了多少百分比。
0表示最大限度的使用内存，100表示尽量使用swap磁盘。

调整vm.swappiness以避免不需要的磁盘I / O.

简单设置

$ sudo sysctl -w vm.swappiness = 0

持久设置

可以在/etc/sysctl.conf中设置它，方法是附加“vm.swappiness = 0”并运行“sudo sysctl -p”来重新加载值

推荐设置

系统默认的参数是60，当物理内存使用率达到40%，就会频繁进行swap，影响系统性能
推荐将vm.swappiness 设置为较低的值1。

脏文件

当大量的持续不断的数据写入cache内存中后，这些数据就被称为脏数据。需要尽快将这些脏数据flush到磁盘中，释放内存。

关于脏文件的两个参数

vm.dirty_background_ratio:这个参数指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如5%）就会触发pdflush/flush/kdmflush等后台回写进程运行，将一定缓存的脏页异步地刷入外存；

vm.dirty_ratio:这个参数则指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如10%），系统不得不开始处理缓存脏页（因为此时脏页数量已经比较多，为了避免数据丢失需要将一定脏页刷入外存）；在此过程中很多应用进程可能会因为系统转而处理文件IO而阻塞。

推荐设置

vm.dirty_background_ratio设置为5
vm.dirty_ratio默认

网络

kafka集群对网络的要求比较高，可以将socket的缓冲设置为原来的两倍。

net.core.wmem_default 设置为128K
net.core.rmem_default 设置为128K

网络和ios操作线程配置优化

    # broker处理消息的最大线程数
    num.network.threads=9
    # broker处理磁盘IO的线程数
    num.io.threads=16

推荐配置

num.network.threads主要处理网络io，读写缓冲区数据，基本没有io等待，配置线程数量为cpu核数加1。
num.io.threads主要进行磁盘io操作，高峰期可能有些io等待，因此配置需要大些。配置线程数量为cpu核数2倍，最大不超过3倍。

Kafka配置

log数据文件刷盘策略

# 每当producer写入10000条消息时，刷数据到磁盘
log.flush.interval.messages=10000
# 每间隔1秒钟时间，刷数据到磁盘
log.flush.interval.ms=1000

推荐配置

为了大幅度提高producer写入吞吐量，需要定期批量写文件。推荐配置分别message 10000，间隔1s。
一般无需改动，如果topic的数据量较小可以考虑减少log.flush.interval.ms和log.flush.interval.messages来强制刷写数据，减少可能由于缓存数据未写盘带来的不一致。

日志保留策略配置

# 日志保留时长
log.retention.hours=72
# 段文件配置
log.segment.bytes=1073741824

推荐配置

日志建议保留三天，也可以更短；段文件配置1GB，有利于快速回收磁盘空间，重启kafka加载也会加快（kafka启动时是单线程扫描目录(log.dir)下所有数据文件）。如果文件过小，则文件数量比较多。

replica复制配置

num.replica.fetchers=3
replica.fetch.min.bytes=1
replica.fetch.max.bytes=5242880

推荐配置

每个follow从leader拉取消息进行同步数据，follow同步性能由这几个参数决定，分别为:

拉取线程数(num.replica.fetchers):

fetcher配置多可以提高follower的I/O并发度，单位时间内leader持有更多请求，相应负载会增大，需要根据机器硬件资源做权衡，建议适当调大；

最小字节数(replica.fetch.min.bytes):

一般无需更改，默认值即可；

最大字节数(replica.fetch.max.bytes)：

默认为1MB，这个值太小，推荐5M，根据业务情况调整

最大等待时间(replica.fetch.wait.max.ms):

follow拉取频率，频率过高，leader会积压大量无效请求情况，无法进行数据同步，导致cpu飙升。配置时谨慎使用，建议默认值，无需配置。

分区数量配置

num.partitions=5

推荐配置

默认partition数量1，如果topic在创建时没有指定partition数量，默认使用此值。Partition的数量选取也会直接影响到Kafka集群的吞吐性能，配置过小会影响消费性能，建议改为5。

JVM虚拟机

GC调优

推荐使用1.7出来的G1垃圾回收机制代替CMS。

与CMS比较

G1在压缩空间方面有优势
G1通过将内存空间分成区域（Region）的方式避免内存碎片问题
Eden, Survivor, Old区不再固定、在内存使用效率上来说更灵活
G1可以通过设置预期停顿时间（Pause Time）来控制垃圾收集时间避免应用雪崩现象
G1在回收内存后会马上同时做合并空闲内存的工作、而CMS默认是在STW（stop the world）的时候做
G1会在Young GC中使用、而CMS只能在O区使用

G1适合的场景

服务端多核CPU、JVM内存占用较大的应用（至少大于4G）
应用在运行过程中会产生大量内存碎片、需要经常压缩空间
想要更可控、可预期的GC停顿周期；防止高并发下应用雪崩现象

我们的kafka的kafka-run-class.sh 中已经包含了

KAFKA_JVM_PERFORMANCE_OPTS="-server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+DisableExplicitGC -Djava.awt.headless=true"

所以只需要修改kafka-server-start.sh。这里面将内存设置为16G，因为当前kafka的堆内存使用了800多M，1个G的内存不够用。但是分配太多，也没什么用，还容易影响到pagecache，降低效率：

export KAFKA_HEAP_OPTS="-Xms16g -Xmx16g"

推荐配置

一般HEAP SIZE的大小不超过主机内存的50%。