On 31.01.2012 19:32, Arun C Murthy wrote:
Anything in TaskTracker logs ?
Actually I've found something like this in jobs log. When running
wordcount I got it in a file:
${result_dir}/_logs/history/job_201201311241_0008_1328055139152_hdfs_word+count
MapAttempt TASK_TYPE="SETUP" TASKID="task_
Moving to mapreduce-user@, bcc common-user@. Please use project specific lists.
Your io.sort.mb is too high. You only have 1G of heap for the map. Reduce
parallel copies is too high too.
On Jan 30, 2012, at 4:50 AM, praveenesh kumar wrote:
> Hey guys,
>
> Just wanted to ask, are there any sort
If just changing the buffer to 4k makes a big difference could you at a minimum
file a JIRA to change that buffer size? I know that it is not a final fix but
it sure seems like a very nice Band-Aid to put on until we can get to the root
of the issues.
--Bobby Evans
On 1/27/12 9:23 PM, "Sven G
On our cluster, it usually happen when jvm crash with invalid jvm params or
jni crashing at init phase.
stderr/stdout files are created but log.index does not exist when this
happens.
We should fix this.
Koji
On 1/31/12 10:49 AM, "Markus Jelsma" wrote:
> Yes, the stacktrace in my previous m
Yes, the stacktrace in my previous message is from the task tracker. It seems
to happen when there is no data locality for the mapper and it needs to get it
from some other datanode. The number of failures is the same as the number of
rack-local mappers.
> Anything in TaskTracker logs ?
>
> On
Anything in TaskTracker logs ?
On Jan 31, 2012, at 10:18 AM, Markus Jelsma wrote:
> In our case, which seems to be the same problem, the web UI does not show
> anything useful except the first line of the stack trace:
>
> 2012-01-03 21:16:27,256 WARN org.apache.hadoop.mapred.TaskLog: Failed to
In our case, which seems to be the same problem, the web UI does not show
anything useful except the first line of the stack trace:
2012-01-03 21:16:27,256 WARN org.apache.hadoop.mapred.TaskLog: Failed to
retrieve stdout log for task: attempt_201201031651_0008_m_000233_0
Only the task tracker lo
Actually, all that is telling you is that the task failed and the job-client
couldn't display the logs.
Can you check the JT web-ui and see why the task failed ?
If you don't see anything there, you can try see the TaskTracker logs on the
node on which the task ran.
Arun
On Jan 31, 2012, at 3
Glad to know you fixed it! I reckon 1.0 changed much scripts and
tarball structure and its probably HADOOP_PREFIX instead now.
If you feel this may help others as well, please also file a JIRA at
https://issues.apache.org/jira/browse/HADOOP with a patch. Thanks!
On Tue, Jan 31, 2012 at 9:57 PM, M
HADOOP_HOME is deprecated in hadoop 1.0.
I solved my problem by changing the libexec/hadoop-config.sh:
this="${BASH_SOURCE-$0}"
#echo $this
-common_bin=$(cd -P -- "$(dirname -- "$this")" && pwd -P)
to
+common_bin=$(cd -L -- "$(dirname -- "$this")" && pwd -L)
Bests,
Trad Mohamed Riadh, M.Sc,
1 run locally ether problem is small and until you can run a small local
problem do not mover to the cluster.
2 make sure ether mapper writes something set a breakpoint at the write
call.
3 make sure the reducer reads something.
4 add write call s in the reducers setup and cleanup calls until somet
On 31/01/12 12:48, Markus Jelsma wrote:
I've seen that the number of related failures is almost always the same as the
number of rack-local mappers. Do you see this as well?
Yes, it seems that way.
Marcin
I've seen that the number of related failures is almost always the same as the
number of rack-local mappers. Do you see this as well?
On Tuesday 31 January 2012 12:21:44 Marcin Cylke wrote:
> Hi
>
> I've upgraded my hadoop cluster to version 1.0.0. The upgrade process
> went relatively smoothly
Ronald,
It is the directory where _SUCCESS and part-0 are generated, but they
are empty. In my Eclipse, I put in 'Run Configurations' the following, in
the tab Arguments:
input.small out.ivory.small (as the file where is words and the directory
where Hadoop should write results, respectively)
Hi
I've upgraded my hadoop cluster to version 1.0.0. The upgrade process
went relatively smoothly but it rendered the cluster inoperable due to
errors in jobtrackers operation:
# in job output
Error reading task
outputhttp://hadoop4:50060/tasklog?plaintext=true&attemptid=attempt_201201311241_000
16 matches
Mail list logo
