[
https://issues.apache.org/jira/browse/YARN-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070770#comment-14070770
]
Eric Payne commented on YARN-415:
---------------------------------
{quote}
5. I think it's better to add a new method in SchedulerApplicationAttempt like
getMemoryUtilization, which will only return memory/cpu seconds. We do this to
prevent locking scheduling thread when showing application metrics on web UI.
getMemoryUtilization will be used by
RMAppAttemptMetrics#getFinishedMemory(VCore)Seconds to return completed+running
resource utilization. And used by
SchedulerApplicationAttempt#getResourceUsageReport as well.
The MemoryUtilization class may contain two fields:
runningContainerMemory(VCore)Seconds
{quote}
[~leftnoteasy], Thank you for your thorough analysis of this patch and for your
detailed suggestions.
I am working through them, and I think they are pretty clear, but this one is a
little confusing to me. If I understand correctly, suggestion number 5 is to
create SchedulerApplicationAttempt#getMemoryUtilization to be called from both
SchedulerApplicationAttempt#getResourceUsageReport as well as
RMAppAttemptMetrics#getFinishedMemory(VCore)Seconds.
Is that correct? If so, I have a couple of questions:
- RMAppAttempt can access the scheduler via the 'scheduler' variable, but that
is of type YarnScheduler, which does not have all of the interfaces available
that AbstractYarnScheduler has. Are you suggesting that I add the
getMemoryUtilization method to the YarnScheduler interface? Or, are you
suggesting that the RMAppAttempt#scheduler variable be cast-ed to
AbstractYarnScheduler? Or, am I missing the point?
- When you say that a new class should be added called MemoryUtilization to be
passed back to SchedulerApplicationAttempt#getResourceUsageReport, are you
suggesting that that same structure should be added to
ApplicationResourceUsageReport as a class variable in place of the current
'long memorySeconds' and 'long vcoreSeconds'? If so, I am a little reluctant to
do that, since that structure would have to be passed across the protobuf
interface to the client. It's possible, but seems riskier than just adding 2
longs to the API.
Thank you very much.
Eric Payne
> Capture memory utilization at the app-level for chargeback
> ----------------------------------------------------------
>
> Key: YARN-415
> URL: https://issues.apache.org/jira/browse/YARN-415
> Project: Hadoop YARN
> Issue Type: New Feature
> Components: resourcemanager
> Affects Versions: 0.23.6
> Reporter: Kendall Thrapp
> Assignee: Andrey Klochkov
> Attachments: YARN-415--n10.patch, YARN-415--n2.patch,
> YARN-415--n3.patch, YARN-415--n4.patch, YARN-415--n5.patch,
> YARN-415--n6.patch, YARN-415--n7.patch, YARN-415--n8.patch,
> YARN-415--n9.patch, YARN-415.201405311749.txt, YARN-415.201406031616.txt,
> YARN-415.201406262136.txt, YARN-415.201407042037.txt,
> YARN-415.201407071542.txt, YARN-415.201407171553.txt,
> YARN-415.201407172144.txt, YARN-415.patch
>
>
> For the purpose of chargeback, I'd like to be able to compute the cost of an
> application in terms of cluster resource usage. To start out, I'd like to
> get the memory utilization of an application. The unit should be MB-seconds
> or something similar and, from a chargeback perspective, the memory amount
> should be the memory reserved for the application, as even if the app didn't
> use all that memory, no one else was able to use it.
> (reserved ram for container 1 * lifetime of container 1) + (reserved ram for
> container 2 * lifetime of container 2) + ... + (reserved ram for container n
> * lifetime of container n)
> It'd be nice to have this at the app level instead of the job level because:
> 1. We'd still be able to get memory usage for jobs that crashed (and wouldn't
> appear on the job history server).
> 2. We'd be able to get memory usage for future non-MR jobs (e.g. Storm).
> This new metric should be available both through the RM UI and RM Web
> Services REST API.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
