[jira] [Commented] (MAPREDUCE-6197) Cache MapOutputLocations in ShuffleHandler
[
https://issues.apache.org/jira/browse/MAPREDUCE-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15342828#comment-15342828
]
Hudson commented on MAPREDUCE-6197:
---
SUCCESS: Integrated in Hadoop-trunk-Commit #9997 (See
[https://builds.apache.org/job/Hadoop-trunk-Commit/9997/])
MAPREDUCE-6197. Cache MapOutputLocations in ShuffleHandler. Contributed
(jianhe: rev d8107fcd1c93c202925f2946d0cd4072fe0aef1e)
*
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-shuffle/src/main/java/org/apache/hadoop/mapred/ShuffleHandler.java
*
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-shuffle/src/test/java/org/apache/hadoop/mapred/TestShuffleHandler.java
> Cache MapOutputLocations in ShuffleHandler
> --
>
> Key: MAPREDUCE-6197
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6197
> Project: Hadoop Map/Reduce
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Siddharth Seth
>Assignee: Junping Du
> Fix For: 2.9.0
>
> Attachments: MAPREDUCE-6197.patch
>
>
> ShuffleHandler currently seems to create a map of mapId - mapInfo (file.out /
> index information) when it receives a message.
> This should be caching map info across requests, so that the a scan of all
> directories is not required for each reducer fetching from the same map.
> Also, the scan for each map output / index file is performed twice per mapId
> within a request. In populateHeaders - once in the call to getMapOutputInfo,
> and then directly in the method.
> For an invocation where we do end up with more than 1000 (default) mapIds in
> a single call, and don't cache them in the map - the path constructed for
> such entries will be invalid. This is highly unlikely to be the case though,
> until there's proper caching.
> {code}
> MapOutputInfo info = mapOutputInfoMap.get(mapId);
> if (info == null) {
> info = getMapOutputInfo(outputBasePathStr, mapId, reduceId, user);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Commented] (MAPREDUCE-6197) Cache MapOutputLocations in ShuffleHandler
[
https://issues.apache.org/jira/browse/MAPREDUCE-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15342783#comment-15342783
]
Junping Du commented on MAPREDUCE-6197:
---
Thanks [~jianhe] for review and commit!
> Cache MapOutputLocations in ShuffleHandler
> --
>
> Key: MAPREDUCE-6197
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6197
> Project: Hadoop Map/Reduce
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Siddharth Seth
>Assignee: Junping Du
> Fix For: 2.9.0
>
> Attachments: MAPREDUCE-6197.patch
>
>
> ShuffleHandler currently seems to create a map of mapId - mapInfo (file.out /
> index information) when it receives a message.
> This should be caching map info across requests, so that the a scan of all
> directories is not required for each reducer fetching from the same map.
> Also, the scan for each map output / index file is performed twice per mapId
> within a request. In populateHeaders - once in the call to getMapOutputInfo,
> and then directly in the method.
> For an invocation where we do end up with more than 1000 (default) mapIds in
> a single call, and don't cache them in the map - the path constructed for
> such entries will be invalid. This is highly unlikely to be the case though,
> until there's proper caching.
> {code}
> MapOutputInfo info = mapOutputInfoMap.get(mapId);
> if (info == null) {
> info = getMapOutputInfo(outputBasePathStr, mapId, reduceId, user);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Commented] (MAPREDUCE-6197) Cache MapOutputLocations in ShuffleHandler
[
https://issues.apache.org/jira/browse/MAPREDUCE-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15333791#comment-15333791
]
Junping Du commented on MAPREDUCE-6197:
---
Thanks [~jianhe] for review and comments.
bq. one question is how/why do you choose such policy for determining the
weight?
That's good question. To control cache size of a LoadingCache, we can either to
use maximumSize directly or maximumWeight. The reason to choose maximumWeight
instead of maximumSize is each cache item here is a flexible size which depends
on {{key size + value size}}. It means if we use a fixed maximumSize, we still
not sure how much memory it could end up with. The another reason is to keep
consistent with what we have in HIVE-9912. If we found any issue with current
settings/policy in large production deployment in future, we can change both
side together.
> Cache MapOutputLocations in ShuffleHandler
> --
>
> Key: MAPREDUCE-6197
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6197
> Project: Hadoop Map/Reduce
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Siddharth Seth
>Assignee: Junping Du
> Attachments: MAPREDUCE-6197.patch
>
>
> ShuffleHandler currently seems to create a map of mapId - mapInfo (file.out /
> index information) when it receives a message.
> This should be caching map info across requests, so that the a scan of all
> directories is not required for each reducer fetching from the same map.
> Also, the scan for each map output / index file is performed twice per mapId
> within a request. In populateHeaders - once in the call to getMapOutputInfo,
> and then directly in the method.
> For an invocation where we do end up with more than 1000 (default) mapIds in
> a single call, and don't cache them in the map - the path constructed for
> such entries will be invalid. This is highly unlikely to be the case though,
> until there's proper caching.
> {code}
> MapOutputInfo info = mapOutputInfoMap.get(mapId);
> if (info == null) {
> info = getMapOutputInfo(outputBasePathStr, mapId, reduceId, user);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Commented] (MAPREDUCE-6197) Cache MapOutputLocations in ShuffleHandler
[
https://issues.apache.org/jira/browse/MAPREDUCE-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15333020#comment-15333020
]
Jian He commented on MAPREDUCE-6197:
lgtm,
one question is how/why do you choose such policy for determining the weight ?
{code}
maximumWeight(MAX_WEIGHT).weigher(
new Weigher() {
@Override
public int weigh(AttemptPathIdentifier key,
AttemptPathInfo value) {
return key.jobId.length() + key.user.length() +
key.attemptId.length()+
value.indexPath.toString().length() +
value.dataPath.toString().length();
}
}
)
{code}
> Cache MapOutputLocations in ShuffleHandler
> --
>
> Key: MAPREDUCE-6197
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6197
> Project: Hadoop Map/Reduce
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Siddharth Seth
>Assignee: Junping Du
> Attachments: MAPREDUCE-6197.patch
>
>
> ShuffleHandler currently seems to create a map of mapId - mapInfo (file.out /
> index information) when it receives a message.
> This should be caching map info across requests, so that the a scan of all
> directories is not required for each reducer fetching from the same map.
> Also, the scan for each map output / index file is performed twice per mapId
> within a request. In populateHeaders - once in the call to getMapOutputInfo,
> and then directly in the method.
> For an invocation where we do end up with more than 1000 (default) mapIds in
> a single call, and don't cache them in the map - the path constructed for
> such entries will be invalid. This is highly unlikely to be the case though,
> until there's proper caching.
> {code}
> MapOutputInfo info = mapOutputInfoMap.get(mapId);
> if (info == null) {
> info = getMapOutputInfo(outputBasePathStr, mapId, reduceId, user);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
[jira] [Commented] (MAPREDUCE-6197) Cache MapOutputLocations in ShuffleHandler
[
https://issues.apache.org/jira/browse/MAPREDUCE-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328477#comment-15328477
]
Hadoop QA commented on MAPREDUCE-6197:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 12s
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s {color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
44s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 15s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
12s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 18s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
13s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
23s {color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 12s
{color} | {color:green} trunk passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 12s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 12s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 10s
{color} | {color:red}
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-shuffle:
The patch generated 8 new + 90 unchanged - 1 fixed = 98 total (was 91) {color}
|
| {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 0m 15s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
12s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 21 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 10s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 16s
{color} | {color:green} hadoop-mapreduce-client-shuffle in the patch passed.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
16s {color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 11m 17s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Image:yetus/hadoop:2c91fd8 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12810092/MAPREDUCE-6197.patch |
| JIRA Issue | MAPREDUCE-6197 |
| Optional Tests | asflicense compile javac javadoc mvninstall mvnsite
unit findbugs checkstyle |
| uname | Linux a46ee62cc804 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | /testptch/hadoop/patchprocess/precommit/personality/provided.sh
|
| git revision | trunk / 709a814 |
| Default Java | 1.8.0_91 |
| findbugs | v3.0.0 |
| checkstyle |
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/6552/artifact/patchprocess/diff-checkstyle-hadoop-mapreduce-project_hadoop-mapreduce-client_hadoop-mapreduce-client-shuffle.txt
|
| whitespace |
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/6552/artifact/patchprocess/whitespace-eol.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/6552/testReport/ |
| modules | C:
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-shuffle
U:
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-shuffle
|
| Console output |
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/6552/console |
| Powered by | Apache Yetus 0.3.0 http://yetus.apache.org |
This message was automatically generated.
> Cache
[jira] [Commented] (MAPREDUCE-6197) Cache MapOutputLocations in ShuffleHandler
[
https://issues.apache.org/jira/browse/MAPREDUCE-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328449#comment-15328449
]
Junping Du commented on MAPREDUCE-6197:
---
The similar issue get fixed for Hive in HIVE-9912. Attache a patch refer most
of the original patch but remove the dirWatcher.
> Cache MapOutputLocations in ShuffleHandler
> --
>
> Key: MAPREDUCE-6197
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6197
> Project: Hadoop Map/Reduce
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Siddharth Seth
>Assignee: Junping Du
> Attachments: MAPREDUCE-6197.patch
>
>
> ShuffleHandler currently seems to create a map of mapId - mapInfo (file.out /
> index information) when it receives a message.
> This should be caching map info across requests, so that the a scan of all
> directories is not required for each reducer fetching from the same map.
> Also, the scan for each map output / index file is performed twice per mapId
> within a request. In populateHeaders - once in the call to getMapOutputInfo,
> and then directly in the method.
> For an invocation where we do end up with more than 1000 (default) mapIds in
> a single call, and don't cache them in the map - the path constructed for
> such entries will be invalid. This is highly unlikely to be the case though,
> until there's proper caching.
> {code}
> MapOutputInfo info = mapOutputInfoMap.get(mapId);
> if (info == null) {
> info = getMapOutputInfo(outputBasePathStr, mapId, reduceId, user);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: mapreduce-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: mapreduce-issues-h...@hadoop.apache.org
