Kafka问题以及解决办法汇总

记录本人在日常工作中，所碰到的有关Kafka性能的问题。

Kafka各节点主机cpu飙升

利用top命令查看Kafka各节点，发现kafka的进程占用cpu资源超过200%，严重的达到300%。

原因

当数据发送到Kafka的topic之后，数据首先会存放在Kafka集群的leader中，然后每个follower会从leader中拉取消息以此来同步数据，如果follower同步消息的性能不好（比如follower的io并发很低，拉取字节数过小并且拉取频率过高），那么当单位时间内leader持有了更多请求时，相应的负载会增大（网络以及磁盘io产生瓶颈，cpu飙升），外加follower的拉取频率过高，同样也会导致follower的cpu飙升。
在为Kafka设置了replica之后，Kafka的replica之间会进行文件同步，如果Kafka Broker处理网络的的io线程数比较低且拉取字节数数过小，那么就会导致Broker将网络流量占满，从而导致服务器的网络io不正常，影响其他服务，也会导致topic备份失败，严重情况下会导致replica同步不成功而使broker掉线。

解决办法

解决follower同步性能的问题

修改Kafka 的 server.properties 中的如下参数:

num.replica.fetchers：拉取线程数
replica.fetch.min.bytes：拉取最小字节数
replica.fetch.min.bytes：拉取最大字节数
replica.fetch.wait.max.ms：最大等待时间

优化建议:

num.replica.fetchers

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

replica.fetch.min.bytes=1

默认配置为1字节，否则读取消息不及时

replica.fetch.max.bytes= 5 * 1024 * 1024

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

replica.fetch.wait.max.ms

follow拉取频率，频率过高，会导致cpu飙升，因为leader无数据同步，leader会积压大量无效请求情况

解决replica之间同步出现io占满的问题

修改Kafka 的 server.properties 中的如下参数:

num.network.threads：Broker处理消息的最大线程数
num.io.threads：Broker处理磁盘IO的线程数

优化建议：

num.network.threads

主要处理网络io，读写缓冲区数据，基本没有io等待，配置线程数量为cpu核数加1

num.io.threads

主要进行磁盘io操作，高峰期可能有些io等待，因此配置需要大些。配置线程数量为cpu核数2倍，最大不超过3倍.

除此之外，需要对日志文件的保留以及刷盘策略进行配置：

日志保留策略配置：

当kafka server被写入海量数据之后，会生成很多数据文件，且占用大量磁盘空间，如果不及时清理，会导致磁盘空间不够用，kafka默认是保留7天。

优化建议：

log.retention.hours=72

减少日志保留时间，建议三天或则更多时间。

log.segment.bytes=1073741824

段文件配置1GB，有利于快速回收磁盘空间，重启kafka加载也会加快(如果文件过小，则文件数量比较多，kafka启动时是单线程扫描目录(log.dir)下所有数据文件)，文件较多时性能会稍微降低。

日志文件刷盘策略：

为了大幅度提高producer写入吞吐量，需要定期的批量写文件

优化建议：

log.flush.interval.messages=10000

每当producer写入10000条消息时，刷数据到磁盘。

log.flush.interval.ms=1000

每间隔1秒钟时间，刷数据到磁盘。

Kafka频繁宕机

原因

存放日志文件的目录已经占满。
检查server日志，发现kafka server 抛出异常：open too many file.

解决办法

修改kafka server配置中log.dirs参数，最好赋予拥有磁盘空间足够大的目录。

针对kafka server抛出 open too many file的异常

修改系统中用户打开文件的最大进程数。

在 /etc/security/limits.conf 文件中添加

root - nofile 256000

Kafka性能调优（不定期更新）