[
https://issues.apache.org/jira/browse/MAPREDUCE-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13671535#comment-13671535
]
Jason Lowe commented on MAPREDUCE-5268:
---------------------------------------
Thanks for updating so quickly, Karthik. Sorry, I should have been more clear
on my nit with the templates. I was surprised to see such a generic type, both
in name and template use, for a specific, private use-case. If the name is
something so generic as ConcurrentSkipListMapWithSize then I think it is
appropriate to use templates with that name since the name implies it is
generic. If we think the templates are overkill then I think it's better to
name it more specifically for its purpose, e.g.: JobHistoryInfoMap.
I do like the AtomicInteger change. And as far as the size inconsistency
concern, that's already an issue because of the very nature of concurrency
whether we synchronize the methods or not. As soon as we get/compute the size,
it could be wrong as someone else comes in and changes the map immediately
afterwards. In this case the size is only being used to loosely cap the size of
the job cache, and it's not critical if we're a few jobs over or a few jobs
under that limit.
So I think we're really close. I'd like to see either the
ConcurrentSkipListMapWithSize name changed to be more specific to its use case
or keep the name and have the templates restored. I don't care too much either
way.
> 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.patch, 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
