[
https://issues.apache.org/jira/browse/MAPREDUCE-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13669406#comment-13669406
]
Karthik Kambatla commented on MAPREDUCE-5268:
---------------------------------------------
bq. I think we'd have to use a weighted cache with the weight being an
increasing sequence number so it removes entries based on cache size but in
insertion order rather than LRU.
Also, we will have to set the concurrency level to 1 to ensure the weighted
cache follows the order.
bq. I'm OK with the current approach with one suggestion: I'd prefer the
size/collection pair implementation detail abstracted into a local utility
class.
Makes total sense. Will do.
> Improve history server startup performance
> ------------------------------------------
>
> Key: MAPREDUCE-5268
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5268
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: jobhistoryserver
> Affects Versions: 0.23.7, 2.0.4-alpha
> Reporter: Jason Lowe
> Assignee: Karthik Kambatla
> Attachments: mr-5268.patch, mr-5268-prelim.patch
>
>
> The history server can easily take many minutes to startup when there are a
> significant number of jobs to scan in the done directory. However the
> scanning of files is not the bottleneck, rather it's the heavy use of
> ConcurrentSkipListMap.size in HistoryFileManager.
> ConcurrentSkipListMap.size is a very expensive operation, especially on maps
> with many entries, as it has to scan every entry to compute the size. We
> should avoid calling this method or at least minimize its use.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
