我在ui里面可以看到任务也在正常运行,只是每秒输入700条左右,每秒输出1700,所以对比总量来说十分缓慢。
目前不太清楚性能的瓶颈点和优化的方向: 1 网络传输太慢,导致两表不能及时join?这里不知道如何排查,Metrics里面有个netty的相关指标,看不出什么;其他的指标除了hashjoin in和out缓慢变化,其他的都没有什么变化。 2 并行度过低,导致单点slot需要执行两个千万级表的关联?可否动态修改或者配置probe表的并行度? 3 JVM内存问题?详情见附件,观察内存还是很充足的,貌似垃圾回收有点频繁,是否有必要修改jvm配置? 4 taskmanager的日志不太理解….到build phase就停住了,是日志卡主了 还是 此时正在进行build的网络传输? | 2020-03-21 09:23:14,732 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments 2020-03-21 09:23:14,738 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments 2020-03-21 09:23:14,744 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments 2020-03-21 09:23:14,750 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments 2020-03-21 09:23:14,756 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments 2020-03-21 09:23:14,762 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments 2020-03-21 09:23:14,772 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments 2020-03-21 09:23:14,779 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 4 ms for 32768 segments 2020-03-21 09:23:16,357 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 14 ms for 65536 segments 2020-03-21 09:23:16,453 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 10 ms for 65536 segments 2020-03-21 09:23:16,478 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 9 ms for 65536 segments 2020-03-21 09:23:16,494 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 9 ms for 65536 segments 2020-03-21 09:23:16,509 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 10 ms for 65536 segments 2020-03-21 09:23:16,522 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 9 ms for 65536 segments 2020-03-21 09:23:16,539 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 9 ms for 65536 segments 2020-03-21 09:23:16,554 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 10 ms for 65536 segments 2020-03-21 09:23:16,574 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 9 ms for 65536 segments 2020-03-21 09:23:16,598 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 9 ms for 65536 segments 2020-03-21 09:23:16,611 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 10 ms for 65536 segments 2020-03-21 09:23:20,157 INFO org.apache.flink.table.runtime.hashtable.BinaryHashBucketArea - The rehash take 213 ms for 131072 segments 2020-03-21 09:23:21,579 INFO org.apache.flink.table.runtime.operators.join.HashJoinOperator - Finish build phase. |*来自志愿者整理的flink邮件归档
看了下源代码,了解了下Hybrid hash join。大致了解了瓶颈点: Hybrid hash join,会把build表(也就是我的右表)通过hash映射成map,并按照某种规则进行分区存储(有的在内存,超过的放入磁盘)。 目前看磁盘上的那部分join应该是整个任务的瓶颈。 具体调优方法,还在探索中...也许有什么配置可以控制build表内存存储的大小.*来自志愿者整理的FLINK邮件归档
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。