[
https://issues.apache.org/jira/browse/MAPREDUCE-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karthik Kambatla updated MAPREDUCE-5268:
----------------------------------------
Attachment: mr-5268-prelim.patch
The least intrusive way seems to be to maintain the size of the
{{ConcurrentSkipListMap}} outside in {{JobListCache}}. Uploading a preliminary
patch with the changes:
# Add an AtomicInteger field size to JobListcache, incremented when we add an
entry and decremented when we remove
# Haven't used locks around cache#insert/delete and size update, as I think it
might be okay to not conform to the maximum size exactly. If we choose to
synchronize, we should probably use int for size instead of AtomicInteger.
# I am still working on tests for JobListCache, will try to update the patch
tomorrow.
IIUC, we are using {{ConcurrentSkipListMap}} now and {{TreeMap}} in one of the
previous versions to evict items in the order of {{JobId}}. Is the ordering a
requirement? If it is not, we could may be use something like GuavaCache?
Thoughts?
> 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-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
