[jira] [Commented] (MAPREDUCE-3511) Counters occupy a good part of AM heap

["Robert Joseph Evans (Commented) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MAPREDUCE-3511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164493#comment-13164493 ] 

Robert Joseph Evans commented on MAPREDUCE-3511:
------------------------------------------------

I am not that familiar with the counter RPC call, but if we do keep them in the mrv1 format and do the conversion on demand, and the RPC call is asking for all of the counters, wouldn't we get at least the same amount of heap usage at that point?  Or if for some reason there are two calls to request the counters at the same time, then wouldn't we take up even more memory?  If the typical RPC is only requesting a subset of the counters, like ignoring the individual attempt counters and just looking at the aggregated job counters, then it should be fine, but if the call gets all of the counters I don't see this reducing the peak memory footprint.  It could also slow down those RPC calls because now there is another conversion involved. 
                
> Counters occupy a good part of AM heap
> --------------------------------------
>
>                 Key: MAPREDUCE-3511
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-3511
>             Project: Hadoop Map/Reduce
>          Issue Type: Bug
>          Components: mr-am, mrv2
>    Affects Versions: 0.23.0
>            Reporter: Siddharth Seth
>            Assignee: Devaraj K
>
> Per task counters seem to be occupying a good part of an AMs heap. Looks like more than 50% of what's used by a TaskAttemptImpl object.
> This could be optimized by interning strings or possibly using mrv1 counters which are optimized. Currently counters are converted from mrv1 to mrv2 format for in memory storage. The conversion could be delayed till it's actually required for RPC transfers.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira