[
https://issues.apache.org/jira/browse/FLINK-18646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161853#comment-17161853
]
Andrey Zagrebin commented on FLINK-18646:
-----------------------------------------
GC gaps are not always so not clear how much it slows things down. I agree the
best is to try w/o always calling GC.
It makes sense to continue calling GC if tryRunPendingCleaners is false
(edited)
The original idea was to retry GC only after a lot of waiting
{{RETRIGGER_GC_AFTER_SLEEPS}} (edited)
[|https://dataartisans.slack.com/archives/D0182EQBDUG/p1595319018026200]
It was a further optimisation comparing to the Java code for direct memory
allocation.
> Managed memory released check can block RPC thread
> --------------------------------------------------
>
> Key: FLINK-18646
> URL: https://issues.apache.org/jira/browse/FLINK-18646
> Project: Flink
> Issue Type: Bug
> Components: Runtime / Task
> Affects Versions: 1.11.0
> Reporter: Andrey Zagrebin
> Priority: Major
> Attachments: log1.png, log2.png
>
>
> UnsafeMemoryBudget#verifyEmpty, called on slot freeing, needs time to wait on
> GC of all allocated/released managed memory. If there are a lot of segments
> to GC then it can take time to finish the check. If slot freeing happens in
> RPC thread, the GC waiting can block it and TM risks to miss its heartbeat.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
