You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mapreduce-issues@hadoop.apache.org by "Scott Chen (JIRA)" <ji...@apache.org> on 2010/08/21 05:41:16 UTC
[jira] Created: (MAPREDUCE-2026) JobTracker.getJobCounters() should
not hold JobTracker lock while calling JobInProgress.getCounters()
JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
-----------------------------------------------------------------------------------------------------
Key: MAPREDUCE-2026
URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
Project: Hadoop Map/Reduce
Issue Type: Improvement
Reporter: Scott Chen
Assignee: Scott Chen
Fix For: 0.22.0
JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2026) JobTracker.getJobCounters()
should not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "Kang Xiao (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920440#action_12920440 ]
Kang Xiao commented on MAPREDUCE-2026:
--------------------------------------
+1 even JIP lock is removed for aggregating tips counters
> From our cluster, abount 26% of jobtracker's lock taken by the jsp access.
In fact, we decrease lock time by cache getCounters() result. During job is running getCounters are only 1min fresh while it will be completely accurate when job is finished. However this just decrease the invokation for aggregating tips counters and JIP is still in lock when getCounters() is called if the cache is out of 1min.
Maybe we can combine getCounters() cache and no-lock for aggregating tips counters, than both CPU and lock consumptioncan be decreased. Is that OK?
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Joydeep Sen Sarma
> Fix For: 0.22.0
>
> Attachments: 2026.1.patch, MAPREDUCE-2026.txt
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2026) JobTracker.getJobCounters()
should not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "dhruba borthakur (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920117#action_12920117 ]
dhruba borthakur commented on MAPREDUCE-2026:
---------------------------------------------
> From our cluster, abount 26% of jobtracker's lock taken by the jsp access.
This is a really good observation. we should measure this for our cluster too. If this is the case, do you think a reader/writer lock (instead of a synchronized section) might help performance?
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Joydeep Sen Sarma
> Fix For: 0.22.0
>
> Attachments: MAPREDUCE-2026.txt
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2026) JobTracker.getJobCounters()
should not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "Joydeep Sen Sarma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920580#action_12920580 ]
Joydeep Sen Sarma commented on MAPREDUCE-2026:
----------------------------------------------
if the client doesn't want updated getCounters - they can reduce the polling interval (for updating the counters). this can be a change made in the jsp code (if that is generating most of the calls in your case).
for this reason - we didn't put any caching in the jobtracker. (in our case - most of the calls come from the hive clients and the poll interval is already configurable for hive).
might be worth following up on a new jira?
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Joydeep Sen Sarma
> Fix For: 0.22.0
>
> Attachments: 2026.1.patch, MAPREDUCE-2026.txt
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2026) JobTracker.getJobCounters()
should not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "Joydeep Sen Sarma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921139#action_12921139 ]
Joydeep Sen Sarma commented on MAPREDUCE-2026:
----------------------------------------------
hadoopQA output below. this has been running on a production cluster for a week or so:
[exec] BUILD SUCCESSFUL
[exec] Total time: 1 minute 17 seconds
[exec]
[exec]
[exec]
[exec]
[exec] -1 overall.
[exec]
[exec] +1 @author. The patch does not contain any @author tags.
[exec]
[exec] -1 tests included. The patch doesn't appear to include any new or modified tests.
[exec] Please justify why no new tests are needed for this patch.
[exec] Also please list what manual steps were performed to verify this patch.
[exec]
[exec] +1 javadoc. The javadoc tool did not generate any warning messages.
[exec]
[exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings.
[exec]
[exec] +1 findbugs. The patch does not introduce any new Findbugs warnings.
[exec]
[exec] +1 release audit. The applied patch does not increase the total number of release audit warnings.
[exec]
[exec] +1 system tests framework. The patch passed system tests framework compile.
[exec]
[exec]
[exec]
[exec]
[exec] ======================================================================
[exec] ======================================================================
[exec] Finished build.
[exec] ======================================================================
[exec] ======================================================================
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Joydeep Sen Sarma
> Fix For: 0.22.0
>
> Attachments: 2026.1.patch, MAPREDUCE-2026.txt
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2026) JobTracker.getJobCounters() should
not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "Scott Chen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Chen updated MAPREDUCE-2026:
----------------------------------
Attachment: MAPREDUCE-2026.txt
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Scott Chen
> Fix For: 0.22.0
>
> Attachments: MAPREDUCE-2026.txt
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2026) JobTracker.getJobCounters()
should not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "luoli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920442#action_12920442 ]
luoli commented on MAPREDUCE-2026:
----------------------------------
hi Scott and Joydeep, what the patch does is really what we have thought, moreover, the getCounters method will still consume some cpu time and it will still synchronized the JIP, what if we add a call time interval of getCounters? For example, call of getCounters return the result that got like ten seconds ago, and if the call time from the last call exceed ten seconds we recompute the counters? Or what if we launch a separate thread to do counters compute? These are XiaoKang and I have discussed, what do you think?
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Joydeep Sen Sarma
> Fix For: 0.22.0
>
> Attachments: 2026.1.patch, MAPREDUCE-2026.txt
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2026) JobTracker.getJobCounters()
should not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "luoli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920107#action_12920107 ]
luoli commented on MAPREDUCE-2026:
----------------------------------
We use our own hadoop release and we found the same problem because our cluster is using by lots of application developers and most of them like to refresh the jobtracker webui to get the real-time situation of their jobs,specially the jobdetail.jsp. This page want to getCounters of a JIP and will lock the JIP object, the more jobdetail page accessed by people , jobtracker get more inefficient. From our cluster, abount 26% of jobtracker's lock taken by the jsp access.
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Joydeep Sen Sarma
> Fix For: 0.22.0
>
> Attachments: MAPREDUCE-2026.txt
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2026) JobTracker.getJobCounters()
should not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "Scott Chen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12900970#action_12900970 ]
Scott Chen commented on MAPREDUCE-2026:
---------------------------------------
In the jstacks we have taken on our cluster, 20% of the jobtracker lock is taken by getJobCounters().
So this should improve the performance a lot.
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Scott Chen
> Fix For: 0.22.0
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2026) JobTracker.getJobCounters() should
not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "Scott Chen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Chen updated MAPREDUCE-2026:
----------------------------------
Status: Patch Available (was: Open)
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Scott Chen
> Fix For: 0.22.0
>
> Attachments: MAPREDUCE-2026.txt
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MAPREDUCE-2026) JobTracker.getJobCounters()
should not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "Scott Chen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920654#action_12920654 ]
Scott Chen commented on MAPREDUCE-2026:
---------------------------------------
bq. Or what if we launch a separate thread to do counters compute?
We also thought about this idea of updating counters in a background thread.
I just created MAPREDUCE-2131 for it.
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Joydeep Sen Sarma
> Fix For: 0.22.0
>
> Attachments: 2026.1.patch, MAPREDUCE-2026.txt
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2026) JobTracker.getJobCounters() should
not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "Joydeep Sen Sarma (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joydeep Sen Sarma updated MAPREDUCE-2026:
-----------------------------------------
Attachment: 2026.1.patch
combines a couple patches Scott and I had worked on for higher getCounters concurrency.
This trades off concurrency for consistency. The value of getCounters for a job is not a point in time summary across all TIP counters. This seemed reasonable because when a job is running - tip counters are constantly changing and the values held in JT/JIP may themselves be outofdate (wrt the actual status of the task running on a different machine).
However - if a job is finished - then getCounters will be completely accurate. (Intuitively - this would seem to be the consistency clients care about).
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Joydeep Sen Sarma
> Fix For: 0.22.0
>
> Attachments: 2026.1.patch, MAPREDUCE-2026.txt
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (MAPREDUCE-2026) JobTracker.getJobCounters()
should not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "Scott Chen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Chen reassigned MAPREDUCE-2026:
-------------------------------------
Assignee: Joydeep Sen Sarma (was: Scott Chen)
Actually, Joydeep has a better fix for this. Let me assign this to him.
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Joydeep Sen Sarma
> Fix For: 0.22.0
>
> Attachments: MAPREDUCE-2026.txt
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2026) JobTracker.getJobCounters() should
not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "Scott Chen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Chen updated MAPREDUCE-2026:
----------------------------------
Attachment: MAPREDUCE-2026.txt
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Scott Chen
> Fix For: 0.22.0
>
> Attachments: MAPREDUCE-2026.txt
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MAPREDUCE-2026) JobTracker.getJobCounters() should
not hold JobTracker lock while calling JobInProgress.getCounters()
Posted by "Scott Chen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MAPREDUCE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott Chen updated MAPREDUCE-2026:
----------------------------------
Attachment: (was: MAPREDUCE-2026.txt)
> JobTracker.getJobCounters() should not hold JobTracker lock while calling JobInProgress.getCounters()
> -----------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2026
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2026
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Reporter: Scott Chen
> Assignee: Scott Chen
> Fix For: 0.22.0
>
>
> JobTracker.getJobCounter() will lock JobTracker and call JobInProgress.getCounters().
> JobInProgress.getCounters() can be very expensive because it aggregates all the task counters.
> We found that from the JobTracker jstacks that this method is one of the bottleneck of the JobTracker performance.
> JobInProgress.getCounters() should be able to be called out side the JobTracker lock because it already has JobInProgress lock.
> For example, it is used by jobdetails.jsp without a JobTracker lock.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.