不过也比较奇怪，Source 数据的 format的话，应该不会使得 CPU 降低，这期间 Iowait 高吗
也可以 jstack 采下堆栈看下，GC等看下。
至于 Source format 能力的话，可以自己测试下单个线程的QPS多少，然后乘以 Partition个数就是了。
Best,
Hailong Wang
在 2020-09-29 20:06:50，"Yang Peng" <yangpengklf...@gmail.com> 写道：
>感谢回复，我重启完任务之后消费恢复了，我查看了我们的监控（监控kafkamanager上groupid消费速度）发现消费速度并没有下降，目前分区是90
>flinkkafkaconsumer消费的并行度也是90 应该不是分区的问题，至于2这个source序列化耗时严重这个有什么方式可以查看吗？
>
>hailongwang <18868816...@163.com> 于2020年9月29日周二 下午8:59写道：
>
>>
>>
>>
>> Hi Yang Peng:
>> 根据你的描述，可以猜测瓶颈是在 Source 上，有可能以下情况：
>> 1. Kafka 集群和Flink 集群之间的带宽被其它打满了。
>> 2. Source 的序列化耗时严重，导致拉取变慢。
>> 可以尝试着扩kafka 分区，加大Source并发看下。
>> Best，
>> Hailong Wang
>>
>> 在 2020-09-29 19:44:44，"Yang Peng" <yangpengklf...@gmail.com> 写道：
>> >请教大家一个问题，flink实时任务消费kafka写入到kafka，Flink版本是1.9.1 线上kafka集群为1.1.1
>> >kafka集群为容器化集群部署在K8s上，任务运行了很久 今天突然发现任务的数据产出降低了很多，发现cp 没有问题
>> >kafka消费没有积压，也没有反压， 也没有任何异常日志，kafka集群也没有异常，flink集群也没有异常，但是发现监控上tm的cpu负载也降低了
>> >tm上网卡流量也降低了，除此之外没有其他异常信息，大家又遇到这种情况的吗、
>>
