[HADOOP-7016] Optimize locking codepath in LocalDirAllocator.getLocalPathToRead() and reduce creating many Path objects

• Type: Improvement
• Status: Patch Available
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: 0.20.2
• Component/s: fs
• Assignee: Rajesh Balamohan
• Reporter: Rajesh Balamohan
• Created: 03/Nov/10 07:06
• Updated: 03/Mar/17 21:58

Description

LocalDirAllocator.getLocalPathToRead() is called from TaskTracker to retrieve temporary map output location. This method is synchronized and amount of time spent on this method directly affects the performance of TaskTracker's ability to serve faster. This JIRA is created to reduce the additional fat in getLocalPathToRead() and reduce creating the number of Path obejcts which are expensive.

1. getLocalPathToRead() internally calls RawLocalFileSystem.exists() in order to check the existence of a local file. RawLocalFileSystem.exists() internally creates a FileStatus object which needs to be populated with lastModified, length, directory details etc. This might not be necessary for just checking file existence.

2. Creating a Path object out of a string requires fair amount of processing. It might be worth to store "localDirsPath" in LocalDirAllocator instead of storing "localDirs". This would avoid the number of times Path() object is created in LocalDirAllocator.

Any other codepath using LocalDirAllocator would also benefit from the above 2 optimizations.

The attached patch addresses the above 2 issues.

Issue Links

• is related to: HADOOP-10048 LocalDirAllocator should avoid holding locks while accessing the filesystem