hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Payne (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (YARN-415) Capture memory utilization at the app-level for chargeback
Date Mon, 28 Jul 2014 18:26:39 GMT

     [ https://issues.apache.org/jira/browse/YARN-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Eric Payne updated YARN-415:
----------------------------

    Attachment: YARN-415.201407281816.txt

[~leftnoteasy]
Thanks for all of your help. 
How were you thinking an end-to-end test would work in the UT environment? In order to set
a baseline and test that the containers ran for some predetermined and expected amount of
time, wouldn't I need to somehow control the clock? Do you have any ideas on how to implement
that?

In the meantime, I have made the additional changes you suggested. Please see below:

{quote}
bq. I was able to remove the rmApps variable, but I had to leave the check for app != null
because if I try to take that out, several unit tests would fail with NullPointerException.
Even with removing the rmApps variable, I needed to change TestRMContainerImpl.java to mock
rmContext.getRMApps().

I would like to suggest to fix such UTs instead of inserting some kernel code to make UT pass.
I'm not sure about the effort of doing this, if the effort is still reasonable, we should
do it.
{quote}
After some spy and mock magic, I was able to fix the unit tests so that the checks for "if
!= null" were not necessary.

{quote}
{code}
 ApplicationCLI.java
+      appReportStr.print("\tResources used : ");
{code}
We need change it to Resource Utilization as well?
{quote}
Yes. I changed it to that.


> 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.201407232237.txt,
YARN-415.201407242148.txt, YARN-415.201407281816.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)

Mime
View raw message