Eric Payne commented on YARN-415:

Thanks for clarifying [~jianhe].
is this {{currentAttempt.getAppAttemptId().equals(attemptId)}} still necessary 
? since the return value of {{scheduler#getAppResourceUsageReport}} for 
non-active attempt is anyways empty/null.
I believe that the check is necessary. Here are a couple of points.
- First, {{RMAppAttemptMetrics#getAggregateAppResourceUsage}} is called from 
multiple places, including {{RMAppImpl#getRMAppMetrics}}, which loops through 
all attempts for any given app. If the app is running and has multiple 
attempts, we want to charge the current attempt for both the running container 
stats and those that finished for that attempt. But, in this scenario, when 
{{RMAppImpl#getRMAppMetrics}} loops through and calls 
{{RMAppAttemptMetrics#getAggregateAppResourceUsage}} for the finished attempts, 
{{RMAppAttemptMetrics#getAggregateAppResourceUsage}} needs to know that the 
attempt ID is not the current attempt so that it doesn't count the running 
container stats again.
- Second, from my tests and my reading of the code, I'm pretty sure that 
{{scheduler#getAppResourceUsageReport}} always returns the 
{{ApplicationResourceUsageReport}} for the current attempt, even if you give it 
a finished attempt. It uses the attemptId to get the app object, and then uses 
that to get the current attempt. I've tested this, and by taking a look at 
{{AbstractYarnScheduler#getApplicationAttempt}} (which is called by 
{{getAppResourceUsageReport}} for both CapacityScheduler and FairScheduler), we 
can see that it only uses the attemptId to get the app, and then calls 

I hope that helps to clarify this.
Thank you

> Capture aggregate memory allocation 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: 2.5.0
>            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.201407232237.txt, 
> YARN-415.201407242148.txt, YARN-415.201407281816.txt, 
> YARN-415.201408062232.txt, YARN-415.201408080204.txt, 
> YARN-415.201408092006.txt, YARN-415.201408132109.txt, 
> YARN-415.201408150030.txt, YARN-415.201408181938.txt, 
> YARN-415.201408181938.txt, YARN-415.201408212033.txt, 
> YARN-415.201409040036.txt, YARN-415.201409092204.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

Reply via email to