[
https://issues.apache.org/jira/browse/YUNIKORN-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Bacsko updated YUNIKORN-2209:
-----------------------------------
Description:
{{QueueTracker.increaseTrackedResource()}} contains code that is no longer
relevant and is a good candidate for removal.
It verifies whether the increased resource is over certain limits. However,
this is not the responsibility of the tracker, at least not anymore. The method
returns a boolean which is no longer used by the application.
Worse, we ignore the increment calculation but perform the decrement part. This
results in a corrupted state. Even if we detect that limits are violated,
there's no reason to mess things up even further.
It also has performance impacts. Lot of intermediate Resource objects are
created, eg. "finalResourceUsage", {{resources.NewResource()}} is called
multiple times. These all results in heap allocations and they immediately
become garbage as soon as the method returns. Actually after performing
YUNIKORN-2201, {{Manager.IncreaseTrackedResource()}} is a 1.5-2% contributor to
the overall heap and cpu usage. Not a massive save, but if it's easy to gain a
quick improvement, let's go for it.
was:
{{QueueTracker.increaseTrackedResource()}} contains code that is no longer
relevant and is a good candidate for removal.
It verifies whether the increased resource is over certain limits. However,
this is not the responsibility of the tracker, at least not anymore. The method
returns a boolean which is no longer used by the application.
Worse, we ignore the increment calculation but perform the decrement part. This
results in a corrupted state. Even if we detect that limits are violated,
there's no reason to mess things up even further.
It has performance impacts. Lot of intermediate Resource objects are created,
eg. "finalResourceUsage", {{resources.NewResource()}} is called multiple times.
These all results in heap allocations and they immediately become garbage as
soon as the method returns. Actually after performing YUNIKORN-2201,
{{Manager.IncreaseTrackedResource()}} is a 1.5-2% contributor to the overall
heap and cpu usage. Not a massive save, but if it's easy to gain a quick
improvement, let's go for it.
> Remove limit checks in QueueTracker
> -----------------------------------
>
> Key: YUNIKORN-2209
> URL: https://issues.apache.org/jira/browse/YUNIKORN-2209
> Project: Apache YuniKorn
> Issue Type: Sub-task
> Components: core - common
> Reporter: Peter Bacsko
> Assignee: Peter Bacsko
> Priority: Major
>
> {{QueueTracker.increaseTrackedResource()}} contains code that is no longer
> relevant and is a good candidate for removal.
> It verifies whether the increased resource is over certain limits. However,
> this is not the responsibility of the tracker, at least not anymore. The
> method returns a boolean which is no longer used by the application.
> Worse, we ignore the increment calculation but perform the decrement part.
> This results in a corrupted state. Even if we detect that limits are
> violated, there's no reason to mess things up even further.
> It also has performance impacts. Lot of intermediate Resource objects are
> created, eg. "finalResourceUsage", {{resources.NewResource()}} is called
> multiple times. These all results in heap allocations and they immediately
> become garbage as soon as the method returns. Actually after performing
> YUNIKORN-2201, {{Manager.IncreaseTrackedResource()}} is a 1.5-2% contributor
> to the overall heap and cpu usage. Not a massive save, but if it's easy to
> gain a quick improvement, let's go for it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
