You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@flink.apache.org by Vinay Patil <vi...@gmail.com> on 2020/07/29 13:25:02 UTC
Memory reclaim problem on Flink Kubernetes pods
Hi Team,
We are facing an issue where the memory is not reclaimed after the job is
cancelled on the K8 session cluster, the pods were entirely used by a
single job only. So, after re-submitting the same job it fails immediately.
We are using RocksDb state backend where the state size is fairly small
ranging from 800MB to 1GB.
Cluster Configurations: Flink 1.10.1 version
8 TM pods with 4 slots each and 16Gb per pod.
Memory Fraction ratio : 0.6
Few Observations/Concerns:
1.I have observed a weird issue where the memory usage goes beyond 16Gb for
the pod , attaching a screenshot in-line.
[image: Screenshot 2020-07-29 at 6.38.46 PM.png]
2. Plotted a graph for `flink_taskmanager_Status_JVM_Memory_NonHeap_Used`
and it is under 300MB per pod
[image: Screenshot 2020-07-29 at 6.46.59 PM.png]
3. We thought if there is any memory leak that is causing this to happen
but there is normal GC activity going on and TM heap usage is under control
[image: Screenshot 2020-07-29 at 6.51.46 PM.png]
Am I missing any obvious configuration to be set ?
Regards,
Vinay Patil
Re: Memory reclaim problem on Flink Kubernetes pods
Posted by Vijay Bhaskar <bh...@gmail.com>.
Also to eliminate RocksDB issue, can you please try switching to
FsSystemBackend and run your tests?
If you still see memory growth then it's not because of RocksDB.
Regards
Bhaskar
On Tue, Aug 4, 2020 at 6:23 AM Vijay Bhaskar <bh...@gmail.com>
wrote:
> I suspect it's RocksDB memory growth. We also observed same issue with
> RocksDB but couple of things should limit the growth:
>
> 1. Reducing the frequency of state update over a period of time equal to
> checkpoint interval
> 2. By adding couple of intermediate RocksDB internal tuning params:
> state.backend.rocksdb.compaction.level.use-dynamic-size: truestate.backend.rocksdb.thread.num:
> 3
> Increasing the compaction thread count
>
> 3. No matter how we do, there will be memory growth with RocksDB
> because of its consistent File IO and increasing page cache size. That's
> why in the documentation they clearly mentioned very large states and
> obviously once we have very large states, we don't write the state very
> frequently.
> 4. I feel if we are using RocksDB then we should spend significant amount
> of time tuning ROcksDB state, otherwise it's not easy.
> 5. Excellent performance is seen using FsSystemBackend for our same
> workloads in our benchmarking tests
>
> Regards
> Bhaskar
>
>
> On Tue, Aug 4, 2020 at 2:21 AM Roman Grebennikov <gr...@dfdx.me> wrote:
>
>> Hi,
>>
>> From my own experience running state-heavy flinks jobs, it's nice to keep
>> an eye on these memory-related things:
>> * metaspace usage. When the job is stopped/cancelled, flink closes the
>> job classloader, which should, in theory, GC all the classes it loaded. But
>> in practice It's quite easy to accidentally leak something to the TM JVM:
>> for example, a thread or metahandle, which will not allow the JVM to unload
>> the classloader. You can make a heap dump and check how many
>> ChildFirstClassLoaders are there and what references are stopping them from
>> being GCed.
>> * rocksdb block cache, which is allocated outside of JVM. There are quite
>> a lot of rocksdb-related metrics exposed by flink (which are AFAIK disabled
>> by default)
>>
>> I suggest enabling a -XX:NativeMemoryTracking=summary for the jvm and
>> monitoring non-heap memory usage. If you see always growing metaspace, then
>> it's a classloader leak. If metaspace is constant, check the difference
>> between process RSS usage and allocated memory reported by NMT: if the
>> difference is too huge, then the leak is happening outside of the JVM, most
>> probably in RocksDB.
>>
>> Roman Grebennikov | grv@dfdx.me
>>
>>
>> On Thu, Jul 30, 2020, at 12:53, Vinay Patil wrote:
>>
>> Hi Till,
>>
>> Sure, I will share the logs with you once I run in preprod env. In prod,
>> we are able to reproduce it always.
>>
>> For now we have shifted to FSStateBackend as the state size is under 1GB.
>>
>> > Have you tried whether the same problem occurs with Flink 1.11.1 as well
>> No, will give it a try in preprod env.
>>
>> Regards,
>> Vinay Patil
>>
>>
>> On Thu, Jul 30, 2020 at 3:10 PM Till Rohrmann <tr...@apache.org>
>> wrote:
>>
>> Hi Vinay and Akshay,
>>
>> could you share the logs of the cluster with us? Ideally on DEBUG level
>> if possible. This would help to debug the problem. Have you tried whether
>> the same problem occurs with Flink 1.11.1 as well?
>>
>> Cheers,
>> Till
>>
>> On Thu, Jul 30, 2020 at 11:30 AM Akshay Aggarwal <
>> akshay.aggarwal@flipkart.com> wrote:
>>
>> Hi, We are facing a similar issue in Yarn even with Flink 1.10, the only
>> workaround we have figured is to kill the YARN session before restarting
>> the job.
>>
>> ~Akshay
>>
>> On Thu, Jul 30, 2020 at 2:55 PM Vinay Patil <vi...@gmail.com>
>> wrote:
>>
>> Hi,
>>
>> Can someone please help here , is it expected that the memory will not go
>> down even after the job is killed. We always have to restart the pods
>> because of this issue.
>>
>> Since the state size is under 1Gb , I will try with FSStatebackend. But I
>> want to understand why this is the case - I had faced the same issue
>> earlier on YARN - https://issues.apache.org/jira/browse/FLINK-7289
>> which is fixed in version 1.10
>>
>> Regards,
>> Vinay Patil
>>
>>
>> On Wed, Jul 29, 2020 at 6:55 PM Vinay Patil <vi...@gmail.com>
>> wrote:
>>
>> Hi Team,
>>
>> We are facing an issue where the memory is not reclaimed after the job is
>> cancelled on the K8 session cluster, the pods were entirely used by a
>> single job only. So, after re-submitting the same job it fails immediately.
>> We are using RocksDb state backend where the state size is fairly small
>> ranging from 800MB to 1GB.
>>
>> Cluster Configurations: Flink 1.10.1 version
>> 8 TM pods with 4 slots each and 16Gb per pod.
>> Memory Fraction ratio : 0.6
>>
>> Few Observations/Concerns:
>> 1.I have observed a weird issue where the memory usage goes beyond 16Gb
>> for the pod , attaching a screenshot in-line.
>>
>> [image: Screenshot 2020-07-29 at 6.38.46 PM.png]
>>
>> 2. Plotted a graph for `flink_taskmanager_Status_JVM_Memory_NonHeap_Used`
>> and it is under 300MB per pod
>>
>> [image: Screenshot 2020-07-29 at 6.46.59 PM.png]
>>
>> 3. We thought if there is any memory leak that is causing this to happen
>> but there is normal GC activity going on and TM heap usage is under control
>>
>> [image: Screenshot 2020-07-29 at 6.51.46 PM.png]
>>
>> Am I missing any obvious configuration to be set ?
>>
>> Regards,
>> Vinay Patil
>>
>>
>>
>> *-----------------------------------------------------------------------------------------*
>>
>> *This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this email in error, please notify the
>> system manager. This message contains confidential information and is
>> intended only for the individual named. If you are not the named addressee,
>> you should not disseminate, distribute or copy this email. Please notify
>> the sender immediately by email if you have received this email by mistake
>> and delete this email from your system. If you are not the intended
>> recipient, you are notified that disclosing, copying, distributing or
>> taking any action in reliance on the contents of this information is
>> strictly prohibited.*
>>
>>
>>
>> *Any views or opinions presented in this email are solely those of the
>> author and do not necessarily represent those of the organization. Any
>> information on shares, debentures or similar instruments, recommended
>> product pricing, valuations and the like are for information purposes only.
>> It is not meant to be an instruction or recommendation, as the case may be,
>> to buy or to sell securities, products, services nor an offer to buy or
>> sell securities, products or services unless specifically stated to be so
>> on behalf of the Flipkart group. Employees of the Flipkart group of
>> companies are expressly required not to make defamatory statements and not
>> to infringe or authorise any infringement of copyright or any other legal
>> right by email communications. Any such communication is contrary to
>> organizational policy and outside the scope of the employment of the
>> individual concerned. The organization will not accept any liability in
>> respect of such communication, and the employee responsible will be
>> personally liable for any damages or other liability arising.*
>>
>>
>>
>> *Our organization accepts no liability for the content of this email, or
>> for the consequences of any actions taken on the basis of the information *
>> provided,* unless that information is subsequently confirmed in writing.
>> If you are not the intended recipient, you are notified that disclosing,
>> copying, distributing or taking any action in reliance on the contents of
>> this information is strictly prohibited.*
>>
>>
>> *-----------------------------------------------------------------------------------------*
>>
>>
>> *Attachments:*
>>
>> - Screenshot 2020-07-29 at 6.38.46 PM.png
>> - Screenshot 2020-07-29 at 6.46.59 PM.png
>> - Screenshot 2020-07-29 at 6.51.46 PM.png
>>
>>
>>
Re: Memory reclaim problem on Flink Kubernetes pods
Posted by Vijay Bhaskar <bh...@gmail.com>.
I suspect it's RocksDB memory growth. We also observed same issue with
RocksDB but couple of things should limit the growth:
1. Reducing the frequency of state update over a period of time equal to
checkpoint interval
2. By adding couple of intermediate RocksDB internal tuning params:
state.backend.rocksdb.compaction.level.use-dynamic-size:
truestate.backend.rocksdb.thread.num:
3
Increasing the compaction thread count
3. No matter how we do, there will be memory growth with RocksDB because of
its consistent File IO and increasing page cache size. That's why in the
documentation they clearly mentioned very large states and obviously once
we have very large states, we don't write the state very frequently.
4. I feel if we are using RocksDB then we should spend significant amount
of time tuning ROcksDB state, otherwise it's not easy.
5. Excellent performance is seen using FsSystemBackend for our same
workloads in our benchmarking tests
Regards
Bhaskar
On Tue, Aug 4, 2020 at 2:21 AM Roman Grebennikov <gr...@dfdx.me> wrote:
> Hi,
>
> From my own experience running state-heavy flinks jobs, it's nice to keep
> an eye on these memory-related things:
> * metaspace usage. When the job is stopped/cancelled, flink closes the job
> classloader, which should, in theory, GC all the classes it loaded. But in
> practice It's quite easy to accidentally leak something to the TM JVM: for
> example, a thread or metahandle, which will not allow the JVM to unload the
> classloader. You can make a heap dump and check how many
> ChildFirstClassLoaders are there and what references are stopping them from
> being GCed.
> * rocksdb block cache, which is allocated outside of JVM. There are quite
> a lot of rocksdb-related metrics exposed by flink (which are AFAIK disabled
> by default)
>
> I suggest enabling a -XX:NativeMemoryTracking=summary for the jvm and
> monitoring non-heap memory usage. If you see always growing metaspace, then
> it's a classloader leak. If metaspace is constant, check the difference
> between process RSS usage and allocated memory reported by NMT: if the
> difference is too huge, then the leak is happening outside of the JVM, most
> probably in RocksDB.
>
> Roman Grebennikov | grv@dfdx.me
>
>
> On Thu, Jul 30, 2020, at 12:53, Vinay Patil wrote:
>
> Hi Till,
>
> Sure, I will share the logs with you once I run in preprod env. In prod,
> we are able to reproduce it always.
>
> For now we have shifted to FSStateBackend as the state size is under 1GB.
>
> > Have you tried whether the same problem occurs with Flink 1.11.1 as well
> No, will give it a try in preprod env.
>
> Regards,
> Vinay Patil
>
>
> On Thu, Jul 30, 2020 at 3:10 PM Till Rohrmann <tr...@apache.org>
> wrote:
>
> Hi Vinay and Akshay,
>
> could you share the logs of the cluster with us? Ideally on DEBUG level if
> possible. This would help to debug the problem. Have you tried whether the
> same problem occurs with Flink 1.11.1 as well?
>
> Cheers,
> Till
>
> On Thu, Jul 30, 2020 at 11:30 AM Akshay Aggarwal <
> akshay.aggarwal@flipkart.com> wrote:
>
> Hi, We are facing a similar issue in Yarn even with Flink 1.10, the only
> workaround we have figured is to kill the YARN session before restarting
> the job.
>
> ~Akshay
>
> On Thu, Jul 30, 2020 at 2:55 PM Vinay Patil <vi...@gmail.com>
> wrote:
>
> Hi,
>
> Can someone please help here , is it expected that the memory will not go
> down even after the job is killed. We always have to restart the pods
> because of this issue.
>
> Since the state size is under 1Gb , I will try with FSStatebackend. But I
> want to understand why this is the case - I had faced the same issue
> earlier on YARN - https://issues.apache.org/jira/browse/FLINK-7289 which
> is fixed in version 1.10
>
> Regards,
> Vinay Patil
>
>
> On Wed, Jul 29, 2020 at 6:55 PM Vinay Patil <vi...@gmail.com>
> wrote:
>
> Hi Team,
>
> We are facing an issue where the memory is not reclaimed after the job is
> cancelled on the K8 session cluster, the pods were entirely used by a
> single job only. So, after re-submitting the same job it fails immediately.
> We are using RocksDb state backend where the state size is fairly small
> ranging from 800MB to 1GB.
>
> Cluster Configurations: Flink 1.10.1 version
> 8 TM pods with 4 slots each and 16Gb per pod.
> Memory Fraction ratio : 0.6
>
> Few Observations/Concerns:
> 1.I have observed a weird issue where the memory usage goes beyond 16Gb
> for the pod , attaching a screenshot in-line.
>
> [image: Screenshot 2020-07-29 at 6.38.46 PM.png]
>
> 2. Plotted a graph for `flink_taskmanager_Status_JVM_Memory_NonHeap_Used`
> and it is under 300MB per pod
>
> [image: Screenshot 2020-07-29 at 6.46.59 PM.png]
>
> 3. We thought if there is any memory leak that is causing this to happen
> but there is normal GC activity going on and TM heap usage is under control
>
> [image: Screenshot 2020-07-29 at 6.51.46 PM.png]
>
> Am I missing any obvious configuration to be set ?
>
> Regards,
> Vinay Patil
>
>
>
> *-----------------------------------------------------------------------------------------*
>
> *This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this email in error, please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named addressee,
> you should not disseminate, distribute or copy this email. Please notify
> the sender immediately by email if you have received this email by mistake
> and delete this email from your system. If you are not the intended
> recipient, you are notified that disclosing, copying, distributing or
> taking any action in reliance on the contents of this information is
> strictly prohibited.*
>
>
>
> *Any views or opinions presented in this email are solely those of the
> author and do not necessarily represent those of the organization. Any
> information on shares, debentures or similar instruments, recommended
> product pricing, valuations and the like are for information purposes only.
> It is not meant to be an instruction or recommendation, as the case may be,
> to buy or to sell securities, products, services nor an offer to buy or
> sell securities, products or services unless specifically stated to be so
> on behalf of the Flipkart group. Employees of the Flipkart group of
> companies are expressly required not to make defamatory statements and not
> to infringe or authorise any infringement of copyright or any other legal
> right by email communications. Any such communication is contrary to
> organizational policy and outside the scope of the employment of the
> individual concerned. The organization will not accept any liability in
> respect of such communication, and the employee responsible will be
> personally liable for any damages or other liability arising.*
>
>
>
> *Our organization accepts no liability for the content of this email, or
> for the consequences of any actions taken on the basis of the information *
> provided,* unless that information is subsequently confirmed in writing.
> If you are not the intended recipient, you are notified that disclosing,
> copying, distributing or taking any action in reliance on the contents of
> this information is strictly prohibited.*
>
>
> *-----------------------------------------------------------------------------------------*
>
>
> *Attachments:*
>
> - Screenshot 2020-07-29 at 6.38.46 PM.png
> - Screenshot 2020-07-29 at 6.46.59 PM.png
> - Screenshot 2020-07-29 at 6.51.46 PM.png
>
>
>
Re: Memory reclaim problem on Flink Kubernetes pods
Posted by Roman Grebennikov <gr...@dfdx.me>.
Hi,
From my own experience running state-heavy flinks jobs, it's nice to keep an eye on these memory-related things:
* metaspace usage. When the job is stopped/cancelled, flink closes the job classloader, which should, in theory, GC all the classes it loaded. But in practice It's quite easy to accidentally leak something to the TM JVM: for example, a thread or metahandle, which will not allow the JVM to unload the classloader. You can make a heap dump and check how many ChildFirstClassLoaders are there and what references are stopping them from being GCed.
* rocksdb block cache, which is allocated outside of JVM. There are quite a lot of rocksdb-related metrics exposed by flink (which are AFAIK disabled by default)
I suggest enabling a -XX:NativeMemoryTracking=summary for the jvm and monitoring non-heap memory usage. If you see always growing metaspace, then it's a classloader leak. If metaspace is constant, check the difference between process RSS usage and allocated memory reported by NMT: if the difference is too huge, then the leak is happening outside of the JVM, most probably in RocksDB.
Roman Grebennikov | grv@dfdx.me
On Thu, Jul 30, 2020, at 12:53, Vinay Patil wrote:
> Hi Till,
>
> Sure, I will share the logs with you once I run in preprod env. In prod, we are able to reproduce it always.
>
> For now we have shifted to FSStateBackend as the state size is under 1GB.
>
> > Have you tried whether the same problem occurs with Flink 1.11.1 as well
> No, will give it a try in preprod env.
>
> Regards,
> Vinay Patil
>
>
> On Thu, Jul 30, 2020 at 3:10 PM Till Rohrmann <tr...@apache.org> wrote:
>> Hi Vinay and Akshay,
>>
>> could you share the logs of the cluster with us? Ideally on DEBUG level if possible. This would help to debug the problem. Have you tried whether the same problem occurs with Flink 1.11.1 as well?
>>
>> Cheers,
>> Till
>>
>> On Thu, Jul 30, 2020 at 11:30 AM Akshay Aggarwal <ak...@flipkart.com> wrote:
>>> Hi, We are facing a similar issue in Yarn even with Flink 1.10, the only workaround we have figured is to kill the YARN session before restarting the job.
>>>
>>> ~Akshay
>>>
>>> On Thu, Jul 30, 2020 at 2:55 PM Vinay Patil <vi...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Can someone please help here , is it expected that the memory will not go down even after the job is killed. We always have to restart the pods because of this issue.
>>>>
>>>> Since the state size is under 1Gb , I will try with FSStatebackend. But I want to understand why this is the case - I had faced the same issue earlier on YARN - https://issues.apache.org/jira/browse/FLINK-7289 which is fixed in version 1.10
>>>>
>>>> Regards,
>>>> Vinay Patil
>>>>
>>>>
>>>> On Wed, Jul 29, 2020 at 6:55 PM Vinay Patil <vi...@gmail.com> wrote:
>>>>> Hi Team,
>>>>>
>>>>> We are facing an issue where the memory is not reclaimed after the job is cancelled on the K8 session cluster, the pods were entirely used by a single job only. So, after re-submitting the same job it fails immediately. We are using RocksDb state backend where the state size is fairly small ranging from 800MB to 1GB.
>>>>>
>>>>> Cluster Configurations: Flink 1.10.1 version
>>>>> 8 TM pods with 4 slots each and 16Gb per pod.
>>>>> Memory Fraction ratio : 0.6
>>>>>
>>>>> Few Observations/Concerns:
>>>>> 1.I have observed a weird issue where the memory usage goes beyond 16Gb for the pod , attaching a screenshot in-line.
>>>>>
>>>>> Screenshot 2020-07-29 at 6.38.46 PM.png
>>>>>
>>>>> 2. Plotted a graph for `flink_taskmanager_Status_JVM_Memory_NonHeap_Used` and it is under 300MB per pod
>>>>>
>>>>> Screenshot 2020-07-29 at 6.46.59 PM.png
>>>>>
>>>>> 3. We thought if there is any memory leak that is causing this to happen but there is normal GC activity going on and TM heap usage is under control
>>>>>
>>>>> Screenshot 2020-07-29 at 6.51.46 PM.png
>>>>>
>>>>> Am I missing any obvious configuration to be set ?
>>>>>
>>>>> Regards,
>>>>> Vinay Patil
>>>
>>>> *-----------------------------------------------------------------------------------------*
>>>> *This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this email. Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.*____
>>>> ____
>>>> *Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the organization. Any information on shares, debentures or similar instruments, recommended product pricing, valuations and the like are for information purposes only. It is not meant to be an instruction or recommendation, as the case may be, to buy or to sell securities, products, services nor an offer to buy or sell securities, products or services unless specifically stated to be so on behalf of the Flipkart group. Employees of the Flipkart group of companies are expressly required not to make defamatory statements and not to infringe or authorise any infringement of copyright or any other legal right by email communications. Any such communication is contrary to organizational policy and outside the scope of the employment of the individual concerned. The organization will not accept any liability in respect of such communication, and the employee responsible will be personally liable for any damages or other liability arising.*____
>>>> ____
>>>> *Our organization accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information *provided,* unless that information is subsequently confirmed in writing. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.*
>>>> *-----------------------------------------------------------------------------------------*
>
> *Attachments:*
> * Screenshot 2020-07-29 at 6.38.46 PM.png
> * Screenshot 2020-07-29 at 6.46.59 PM.png
> * Screenshot 2020-07-29 at 6.51.46 PM.png
Re: Memory reclaim problem on Flink Kubernetes pods
Posted by Vinay Patil <vi...@gmail.com>.
Hi Till,
Sure, I will share the logs with you once I run in preprod env. In prod, we
are able to reproduce it always.
For now we have shifted to FSStateBackend as the state size is under 1GB.
> Have you tried whether the same problem occurs with Flink 1.11.1 as well
No, will give it a try in preprod env.
Regards,
Vinay Patil
On Thu, Jul 30, 2020 at 3:10 PM Till Rohrmann <tr...@apache.org> wrote:
> Hi Vinay and Akshay,
>
> could you share the logs of the cluster with us? Ideally on DEBUG level if
> possible. This would help to debug the problem. Have you tried whether the
> same problem occurs with Flink 1.11.1 as well?
>
> Cheers,
> Till
>
> On Thu, Jul 30, 2020 at 11:30 AM Akshay Aggarwal <
> akshay.aggarwal@flipkart.com> wrote:
>
>> Hi, We are facing a similar issue in Yarn even with Flink 1.10, the only
>> workaround we have figured is to kill the YARN session before restarting
>> the job.
>>
>> ~Akshay
>>
>> On Thu, Jul 30, 2020 at 2:55 PM Vinay Patil <vi...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Can someone please help here , is it expected that the memory will not
>>> go down even after the job is killed. We always have to restart the pods
>>> because of this issue.
>>>
>>> Since the state size is under 1Gb , I will try with FSStatebackend. But
>>> I want to understand why this is the case - I had faced the same issue
>>> earlier on YARN - https://issues.apache.org/jira/browse/FLINK-7289
>>> which is fixed in version 1.10
>>>
>>> Regards,
>>> Vinay Patil
>>>
>>>
>>> On Wed, Jul 29, 2020 at 6:55 PM Vinay Patil <vi...@gmail.com>
>>> wrote:
>>>
>>>> Hi Team,
>>>>
>>>> We are facing an issue where the memory is not reclaimed after the job
>>>> is cancelled on the K8 session cluster, the pods were entirely used by a
>>>> single job only. So, after re-submitting the same job it fails immediately.
>>>> We are using RocksDb state backend where the state size is fairly small
>>>> ranging from 800MB to 1GB.
>>>>
>>>> Cluster Configurations: Flink 1.10.1 version
>>>> 8 TM pods with 4 slots each and 16Gb per pod.
>>>> Memory Fraction ratio : 0.6
>>>>
>>>> Few Observations/Concerns:
>>>>
>>>> 1.I have observed a weird issue where the memory usage goes beyond 16Gb
>>>> for the pod , attaching a screenshot in-line.
>>>>
>>>> [image: Screenshot 2020-07-29 at 6.38.46 PM.png]
>>>>
>>>> 2. Plotted a graph for
>>>> `flink_taskmanager_Status_JVM_Memory_NonHeap_Used` and it is under 300MB
>>>> per pod
>>>>
>>>> [image: Screenshot 2020-07-29 at 6.46.59 PM.png]
>>>>
>>>> 3. We thought if there is any memory leak that is causing this to
>>>> happen but there is normal GC activity going on and TM heap usage is under
>>>> control
>>>>
>>>> [image: Screenshot 2020-07-29 at 6.51.46 PM.png]
>>>>
>>>> Am I missing any obvious configuration to be set ?
>>>>
>>>> Regards,
>>>> Vinay Patil
>>>>
>>>
>>
>> *-----------------------------------------------------------------------------------------*
>>
>> *This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this email in error, please notify the
>> system manager. This message contains confidential information and is
>> intended only for the individual named. If you are not the named addressee,
>> you should not disseminate, distribute or copy this email. Please notify
>> the sender immediately by email if you have received this email by mistake
>> and delete this email from your system. If you are not the intended
>> recipient, you are notified that disclosing, copying, distributing or
>> taking any action in reliance on the contents of this information is
>> strictly prohibited.*
>>
>>
>>
>> *Any views or opinions presented in this email are solely those of the
>> author and do not necessarily represent those of the organization. Any
>> information on shares, debentures or similar instruments, recommended
>> product pricing, valuations and the like are for information purposes only.
>> It is not meant to be an instruction or recommendation, as the case may be,
>> to buy or to sell securities, products, services nor an offer to buy or
>> sell securities, products or services unless specifically stated to be so
>> on behalf of the Flipkart group. Employees of the Flipkart group of
>> companies are expressly required not to make defamatory statements and not
>> to infringe or authorise any infringement of copyright or any other legal
>> right by email communications. Any such communication is contrary to
>> organizational policy and outside the scope of the employment of the
>> individual concerned. The organization will not accept any liability in
>> respect of such communication, and the employee responsible will be
>> personally liable for any damages or other liability arising.*
>>
>>
>>
>> *Our organization accepts no liability for the content of this email, or
>> for the consequences of any actions taken on the basis of the information *
>> provided,* unless that information is subsequently confirmed in writing.
>> If you are not the intended recipient, you are notified that disclosing,
>> copying, distributing or taking any action in reliance on the contents of
>> this information is strictly prohibited.*
>>
>>
>> *-----------------------------------------------------------------------------------------*
>>
>>
Re: Memory reclaim problem on Flink Kubernetes pods
Posted by Till Rohrmann <tr...@apache.org>.
Hi Vinay and Akshay,
could you share the logs of the cluster with us? Ideally on DEBUG level if
possible. This would help to debug the problem. Have you tried whether the
same problem occurs with Flink 1.11.1 as well?
Cheers,
Till
On Thu, Jul 30, 2020 at 11:30 AM Akshay Aggarwal <
akshay.aggarwal@flipkart.com> wrote:
> Hi, We are facing a similar issue in Yarn even with Flink 1.10, the only
> workaround we have figured is to kill the YARN session before restarting
> the job.
>
> ~Akshay
>
> On Thu, Jul 30, 2020 at 2:55 PM Vinay Patil <vi...@gmail.com>
> wrote:
>
>> Hi,
>>
>> Can someone please help here , is it expected that the memory will not go
>> down even after the job is killed. We always have to restart the pods
>> because of this issue.
>>
>> Since the state size is under 1Gb , I will try with FSStatebackend. But I
>> want to understand why this is the case - I had faced the same issue
>> earlier on YARN - https://issues.apache.org/jira/browse/FLINK-7289
>> which is fixed in version 1.10
>>
>> Regards,
>> Vinay Patil
>>
>>
>> On Wed, Jul 29, 2020 at 6:55 PM Vinay Patil <vi...@gmail.com>
>> wrote:
>>
>>> Hi Team,
>>>
>>> We are facing an issue where the memory is not reclaimed after the job
>>> is cancelled on the K8 session cluster, the pods were entirely used by a
>>> single job only. So, after re-submitting the same job it fails immediately.
>>> We are using RocksDb state backend where the state size is fairly small
>>> ranging from 800MB to 1GB.
>>>
>>> Cluster Configurations: Flink 1.10.1 version
>>> 8 TM pods with 4 slots each and 16Gb per pod.
>>> Memory Fraction ratio : 0.6
>>>
>>> Few Observations/Concerns:
>>>
>>> 1.I have observed a weird issue where the memory usage goes beyond 16Gb
>>> for the pod , attaching a screenshot in-line.
>>>
>>> [image: Screenshot 2020-07-29 at 6.38.46 PM.png]
>>>
>>> 2. Plotted a graph for
>>> `flink_taskmanager_Status_JVM_Memory_NonHeap_Used` and it is under 300MB
>>> per pod
>>>
>>> [image: Screenshot 2020-07-29 at 6.46.59 PM.png]
>>>
>>> 3. We thought if there is any memory leak that is causing this to happen
>>> but there is normal GC activity going on and TM heap usage is under control
>>>
>>> [image: Screenshot 2020-07-29 at 6.51.46 PM.png]
>>>
>>> Am I missing any obvious configuration to be set ?
>>>
>>> Regards,
>>> Vinay Patil
>>>
>>
>
> *-----------------------------------------------------------------------------------------*
>
> *This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this email in error, please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named addressee,
> you should not disseminate, distribute or copy this email. Please notify
> the sender immediately by email if you have received this email by mistake
> and delete this email from your system. If you are not the intended
> recipient, you are notified that disclosing, copying, distributing or
> taking any action in reliance on the contents of this information is
> strictly prohibited.*
>
>
>
> *Any views or opinions presented in this email are solely those of the
> author and do not necessarily represent those of the organization. Any
> information on shares, debentures or similar instruments, recommended
> product pricing, valuations and the like are for information purposes only.
> It is not meant to be an instruction or recommendation, as the case may be,
> to buy or to sell securities, products, services nor an offer to buy or
> sell securities, products or services unless specifically stated to be so
> on behalf of the Flipkart group. Employees of the Flipkart group of
> companies are expressly required not to make defamatory statements and not
> to infringe or authorise any infringement of copyright or any other legal
> right by email communications. Any such communication is contrary to
> organizational policy and outside the scope of the employment of the
> individual concerned. The organization will not accept any liability in
> respect of such communication, and the employee responsible will be
> personally liable for any damages or other liability arising.*
>
>
>
> *Our organization accepts no liability for the content of this email, or
> for the consequences of any actions taken on the basis of the information *
> provided,* unless that information is subsequently confirmed in writing.
> If you are not the intended recipient, you are notified that disclosing,
> copying, distributing or taking any action in reliance on the contents of
> this information is strictly prohibited.*
>
>
> *-----------------------------------------------------------------------------------------*
>
>
Re: Memory reclaim problem on Flink Kubernetes pods
Posted by Akshay Aggarwal <ak...@flipkart.com>.
Hi, We are facing a similar issue in Yarn even with Flink 1.10, the only
workaround we have figured is to kill the YARN session before restarting
the job.
~Akshay
On Thu, Jul 30, 2020 at 2:55 PM Vinay Patil <vi...@gmail.com> wrote:
> Hi,
>
> Can someone please help here , is it expected that the memory will not go
> down even after the job is killed. We always have to restart the pods
> because of this issue.
>
> Since the state size is under 1Gb , I will try with FSStatebackend. But I
> want to understand why this is the case - I had faced the same issue
> earlier on YARN - https://issues.apache.org/jira/browse/FLINK-7289 which
> is fixed in version 1.10
>
> Regards,
> Vinay Patil
>
>
> On Wed, Jul 29, 2020 at 6:55 PM Vinay Patil <vi...@gmail.com>
> wrote:
>
>> Hi Team,
>>
>> We are facing an issue where the memory is not reclaimed after the job is
>> cancelled on the K8 session cluster, the pods were entirely used by a
>> single job only. So, after re-submitting the same job it fails immediately.
>> We are using RocksDb state backend where the state size is fairly small
>> ranging from 800MB to 1GB.
>>
>> Cluster Configurations: Flink 1.10.1 version
>> 8 TM pods with 4 slots each and 16Gb per pod.
>> Memory Fraction ratio : 0.6
>>
>> Few Observations/Concerns:
>>
>> 1.I have observed a weird issue where the memory usage goes beyond 16Gb
>> for the pod , attaching a screenshot in-line.
>>
>> [image: Screenshot 2020-07-29 at 6.38.46 PM.png]
>>
>> 2. Plotted a graph for `flink_taskmanager_Status_JVM_Memory_NonHeap_Used`
>> and it is under 300MB per pod
>>
>> [image: Screenshot 2020-07-29 at 6.46.59 PM.png]
>>
>> 3. We thought if there is any memory leak that is causing this to happen
>> but there is normal GC activity going on and TM heap usage is under control
>>
>> [image: Screenshot 2020-07-29 at 6.51.46 PM.png]
>>
>> Am I missing any obvious configuration to be set ?
>>
>> Regards,
>> Vinay Patil
>>
>
--
*-----------------------------------------------------------------------------------------*
*This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error, please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named addressee,
you should not disseminate, distribute or copy this email. Please notify
the sender immediately by email if you have received this email by mistake
and delete this email from your system. If you are not the intended
recipient, you are notified that disclosing, copying, distributing or
taking any action in reliance on the contents of this information is
strictly prohibited.*****
****
*Any views or opinions presented in this
email are solely those of the author and do not necessarily represent those
of the organization. Any information on shares, debentures or similar
instruments, recommended product pricing, valuations and the like are for
information purposes only. It is not meant to be an instruction or
recommendation, as the case may be, to buy or to sell securities, products,
services nor an offer to buy or sell securities, products or services
unless specifically stated to be so on behalf of the Flipkart group.
Employees of the Flipkart group of companies are expressly required not to
make defamatory statements and not to infringe or authorise any
infringement of copyright or any other legal right by email communications.
Any such communication is contrary to organizational policy and outside the
scope of the employment of the individual concerned. The organization will
not accept any liability in respect of such communication, and the employee
responsible will be personally liable for any damages or other liability
arising.*****
****
*Our organization accepts no liability for the
content of this email, or for the consequences of any actions taken on the
basis of the information *provided,* unless that information is
subsequently confirmed in writing. If you are not the intended recipient,
you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this information is strictly
prohibited.*
_-----------------------------------------------------------------------------------------_
Re: Memory reclaim problem on Flink Kubernetes pods
Posted by Vinay Patil <vi...@gmail.com>.
Hi,
Can someone please help here , is it expected that the memory will not go
down even after the job is killed. We always have to restart the pods
because of this issue.
Since the state size is under 1Gb , I will try with FSStatebackend. But I
want to understand why this is the case - I had faced the same issue
earlier on YARN - https://issues.apache.org/jira/browse/FLINK-7289 which
is fixed in version 1.10
Regards,
Vinay Patil
On Wed, Jul 29, 2020 at 6:55 PM Vinay Patil <vi...@gmail.com> wrote:
> Hi Team,
>
> We are facing an issue where the memory is not reclaimed after the job is
> cancelled on the K8 session cluster, the pods were entirely used by a
> single job only. So, after re-submitting the same job it fails immediately.
> We are using RocksDb state backend where the state size is fairly small
> ranging from 800MB to 1GB.
>
> Cluster Configurations: Flink 1.10.1 version
> 8 TM pods with 4 slots each and 16Gb per pod.
> Memory Fraction ratio : 0.6
>
> Few Observations/Concerns:
>
> 1.I have observed a weird issue where the memory usage goes beyond 16Gb
> for the pod , attaching a screenshot in-line.
>
> [image: Screenshot 2020-07-29 at 6.38.46 PM.png]
>
> 2. Plotted a graph for `flink_taskmanager_Status_JVM_Memory_NonHeap_Used`
> and it is under 300MB per pod
>
> [image: Screenshot 2020-07-29 at 6.46.59 PM.png]
>
> 3. We thought if there is any memory leak that is causing this to happen
> but there is normal GC activity going on and TM heap usage is under control
>
> [image: Screenshot 2020-07-29 at 6.51.46 PM.png]
>
> Am I missing any obvious configuration to be set ?
>
> Regards,
> Vinay Patil
>