至于flink-1.1.5上的实时流数据平台，我遇到了一个问题 .

phenomenal description: flink job的业务逻辑是一个通用的ETL过程，源操作符和接收操作符都基于kafka，而变换操作符是一些相关的etl逻辑 . 但来自源操作员读取的kafka主题的数据大小不同，例如一个数据在非高峰时段只有不到100 KB，而其他数据在高峰时段接近600KB . 在非峰值会话中，flink工作的性能很好，但是在峰值会话中表现不尽如人意，性能急剧下降并维持低状态直到峰值会话过去且性能恢复 . 作为结果 . 我没有在任务管理器上看到任何完整的GC案例，并且在此期间每个任务管理员的系统负载都减少了 . 此外，日志中没有异常和额外错误 . 我可以看到当时所有线程都通过JMX在请求缓冲区阻塞 .

Related configuration and metircs:

  • flink独立集群在1.1.5上有1个jobmanager和5个taskmanagers（每个有18个插槽，小于CPU内核） .

  • jdk版本为1.8，GC类型为G1 .

  • source和sink都是kafka

  • 作业一致性类型：恰好一次

  • 因为kafka主题的源分区量小于变换操作符量，每个运算符的并行性不完全相同，并且任务不能成为一个任务链作为优化 .

enter image description here

enter image description here

Based on what I describe above, we have tried some approaches:

  • 修改内存段大小，32KB和64KB

  • 强化网络缓冲池容量，

  • 修改kafka consumer API参数

  • 增强flink集群，添加更多taskmanager节点并添加更多进程线程 .

  • 减少变换操作符线程并保持源操作符的数量，所有变换操作符和接收操作符相同，任务可以成为一个任务链 .

我们尝试了超过＃1，＃2，＃3，＃4的方法，但它们不起作用，只是＃5是有效的，但＃5方法对我们来说不是一个很好的方式，因为它的性能在下降 .

你以前遇到过这个问题吗？有没有更好的方法来避免这个问题？

apache-flink flink-streaming