Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

Hi, Yes, it is only related to **batch** jobs, but not necessarily only to DataSet API jobs. If you are using for example Blink SQL/Table API to process some bounded data streams (tables), it could also be visible/affected there. If not, I would suggest to start a new user mailing list

Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

Hi, We encountered similar issues that the task manager kept being killed by yarn. - flink 1.9.1 - heap usage is low. But our job is a **streaming** job, so I want to ask if this issue is only related to **batch** job or not? Thanks! Best, Victor yingjie 于2019年11月28日周四 上午11:43写道： > Piotr

Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

Piotr is right, that depend on the data size you are reading and the memory pressure. Those memory occupied by mmapped region can be recycled and used by other processes if memory pressure is high, that is, other process or service on the same node won't be affected because the OS will recycle the

Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

> using mmap for data reading? > > > Best, > Jiayi Liao > > Original Message > Sender: yingjie > Recipient: user > Date: Tuesday, Nov 26, 2019 18:10 > Subject: Re: CoGroup SortMerger performance degradatio

Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

right about this. @yingjie Do you have any idea how much memory will be stolen from OS when using mmap for data reading? Best, Jiayi Liao Original Message Sender: yingjie Recipient: user Date: Tuesday, Nov 26, 2019 18:10 Subject: Re: CoGroup SortMerger performance degradation from 1.6.4

Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

Thanks for the confirmation, I’ve created Jira ticket to track this issue [1] https://issues.apache.org/jira/browse/FLINK-14952 Piotrek > On 26 Nov 2019, at 11:10, yingjie wrote: > > The new BlockingSubpartition implementation in 1.9 uses

Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

The new BlockingSubpartition implementation in 1.9 uses mmap for data reading by default which means it steals memory from OS. The mmaped region memory is managed by JVM, so there should be no OutOfMemory problem reported by JVM and the OS memory is also not exhausted, so there should be no kernal

Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

rs which fed into a CoGroup? > > // ah > > <>From: Zhijiang > Sent: Thursday, November 21, 2019 9:48 PM > To: Hailu, Andreas [Engineering] ; Piotr > Nowojski > Cc: user@flink.apache.org > Subject: Re: CoGroup SortMerger performance degradation from 1.6.4 -

RE: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

che.org> mailto:user@flink.apache.org>> Subject:RE: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1? Thanks, Piotr. We’ll rerun our apps today with this and get back to you. // ah From: Piotr Nowojski mailto:pi...@data-artisans.com>> On Behalf Of Piotr Nowojski Sen

Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

. -- From:Hailu, Andreas Send Time:2019 Nov. 21 (Thu.) 23:37 To:Piotr Nowojski Cc:Zhijiang ; user@flink.apache.org Subject:RE: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1? Thanks, Piotr. We’ll rerun our apps today with this and get back to you

RE: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

To: Hailu, Andreas [Engineering] mailto:andreas.ha...@ny.email.gs.com>>; user@flink.apache.org<mailto:user@flink.apache.org> Subject: Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1? Hi Andreas, You are running a batch job, so there should be no native memory used by rocke

Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

<>From: Zhijiang > Sent: Wednesday, November 20, 2019 11:32 PM > To: Hailu, Andreas [Engineering] ; > user@flink.apache.org > Subject: Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1? > > Hi Andreas, > > You are running a batch job, so the

RE: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

at 6.65GB, so it sounds like the problem lies somewhere in the changes around mapped memory. // ah From: Zhijiang Sent: Wednesday, November 20, 2019 11:32 PM To: Hailu, Andreas [Engineering] ; user@flink.apache.org Subject: Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1? Hi Andreas

Re: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

stack, especially it really spans several releases. Best, Zhijiang -- From:Hailu, Andreas Send Time:2019 Nov. 21 (Thu.) 01:03 To:user@flink.apache.org Subject:RE: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1

RE: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

, 2019 6:01 PM To: 'user@flink.apache.org' Subject: CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1? Hi, We're in the middle of testing the upgrade of our data processing flows from Flink 1.6.4 to 1.9.1. We're seeing that flows which were running just fine on 1.6.4 now fail on 1.9.1

CoGroup SortMerger performance degradation from 1.6.4 - 1.9.1?

Hi, We're in the middle of testing the upgrade of our data processing flows from Flink 1.6.4 to 1.9.1. We're seeing that flows which were running just fine on 1.6.4 now fail on 1.9.1 with the same application resources and input data size. It seems that there have been some changes around how