FusionInsight HD集群kafka性能维度标准及常见场景（草稿）

kafka性能维度标准：

6.5.1版本之后kafka生产者的性能基线标准

如何判断一个kafka集群是否已经处于性能瓶颈，通常的判断条件有如下几点：

维度1：磁盘IO

读写磁盘性能是kafka重要的参数指标，如果磁盘IO到达性能瓶颈会直接导致业务故障。Kafka读写性能跟磁盘IO之间的关系计算如下：

举例：假设磁盘IO的上限为100M/s，数据大小为8k，假设在topic仅设置为单副本的情况下，理论上一块盘能写入的数据量为100*1024/8=12800条。如果一个节点挂载4块盘，那么理论性能为4*12800条。如果kafka集群有4个节点，那么整个集群的性能为4*4*12800条。

维度2：网络IO

    现网的网卡设置一般为万兆网卡，一张万兆网卡的理论极限性能为1250MB/s，在多kafka集群场景下，如果每个节点的数据流量不超过这个值，网卡一般不会出现性能瓶颈。

维度3：CPU使用率

     Kafka使用CPU的地方主要在请求的处理、数据落盘等，如果CPU使用率频繁出现95%以上的情况表示kafka集群性能已经到达瓶颈。通常影响kafka集群CPU使用率的几个参数主要有以下几个：

num.recovery.threads.per.data.dir，background.threads，num.replica.fetchers，num.network.threads，num.io.threads。具体参数含义见上表。在磁盘和网卡未达到瓶颈的前提下，如果CPU使用率未达到上限，可以适当调大num.io.threads和num.network.threads，以提升kafka的集群处理能力。

以上三个性能指标哪个先达到瓶颈就是kafka集群的瓶颈。

①.kafka的请求处理线程：num.io.thread，num.network.thread，如果这两个线程配置的非常大（num.io.thread+ num.network.thread数量超过了节点的cpu逻辑核数）那么此时CPU使用率会变得非常大。

②若存在异常请求的客户端在频繁请求，如果存在可以通知IP对应的业务侧进行调整。如果不能调整，可以用后台命令对该IP或者用户进行限制（仅限X的版本，651的版本不能动态实现）

实现方式如下：限制用户flinkuser与每个节点最多建立10个链接

./kafka-configs.sh --bootstrap-server kafkaip:21007  --alter --add-config max.connections.per.ip.overrides=flinkuser:10  --entity-type brokers --entity-default --command-config ../config/consumer.properties

③数据压缩是kafka解决空间问题和超大数据问题关键场景，例如：当kafka的磁盘空间不足时，可以使用数据压缩，来节省磁盘空间的使用。当生产端需要向kafka集群发送大量的超大数据（大于1M的数据）时可以通过开启压缩模式来减少传输过程中带来的网络消耗。

Kafka服务端使用的topic最终压缩模式（由compression.type决定）为producer。

• 建议客户升级客户端，保持和服务端一致
• 使用低版本客户端时，禁用压缩

④FI从651版本开始已经不在JVM参数中添加MaxDirectMemorySize⑤

Kafka使用直接内存作为了网络缓存使用，如果限制了直接内存并且在单条数据比较大（kafka单条消息大于1M）会出现直接内存溢出，如下server.log中的日志打印。

⑤旧版本的鉴权使用了kafka.security.auth.SimpleAclAuthorizer 的鉴权方式。鉴权的顺序是按照: 用户-用户组-角色的顺序进行鉴权，假设在鉴权过程中，用户和用户组没有权限但是角色有权限，那么在kafka的鉴权过程中会出现“用户鉴权失败-用户组鉴权失败-角色鉴权成功”这样的流程。

• 建议使用后台用户鉴权，使用kafka-acl.sh 命令直接为用户名赋权。
• 业务整改，使用“单业务，单用户”，删除无用的用户的数量。

⑥ldap所在节点的CPU使用率高，导致节点的鉴权性能下降（旧版本鉴权）

• 如果ldap压力大可以扩容ldap实例，均衡id –Gn带来的压力
• 增加group.cache.timeout.sec 的超时时间，可以让跟多的用户在缓存中保留更长时间，防止频繁的id –Gn。注意：这个参数有弊端，在更新鉴权信息后可能会导致响应有延迟。