Ed,
Tuning io.sort.mb will be certainly worthwhile if you have enough RAM to allow
for a higher Java heap per map task without risking swapping.
Similarly, you can decrease spills on the reduce side using fs.inmemorysize.mb.
You can use the following thumb rules for tuning those two:
- Set th
Greetings,
I'm running into a brain-numbing problem on Elastic MapReduce. I'm
running a decent-size task (22,000 mappers, a ton of GZipped input
blocks, ~1TB of data) on 40 c1.xlarge nodes (7 gb RAM, ~8 "cores").
I get failures randomly --- sometimes at the end of my 6-step process,
sometimes at
I'm going to try running it on high-RAM boxes with -Xmx4096m or so,
see if that helps.
On Sun, Sep 26, 2010 at 12:55 AM, Bradford Stephens
wrote:
> Greetings,
>
> I'm running into a brain-numbing problem on Elastic MapReduce. I'm
> running a decent-size task (22,000 mappers, a ton of GZipped inpu
Nope, that didn't seem to help.
On Sun, Sep 26, 2010 at 1:00 AM, Bradford Stephens
wrote:
> I'm going to try running it on high-RAM boxes with -Xmx4096m or so,
> see if that helps.
>
> On Sun, Sep 26, 2010 at 12:55 AM, Bradford Stephens
> wrote:
>> Greetings,
>>
>> I'm running into a brain-numbi
The problem is every datanode may be listed in the error report. That means
all my datanodes are bad?
One thing I forgot to mention. I can not use start-all.sh and stop-all.sh to
start and stop all dfs and mapred processes on my clusters. But the
jobtracker and namenode web interface still work.
Hello everyone.
i'm a freshman on hadoop.During running the demo programmer Wordcount, it
stop at “INFO mapred.JobClient: map 0% reduce 0%".
The log printed is as follow:
10/09/26 19:40:40 WARN mapred.JobClient: Use GenericOptionsParser for
parsing the arguments. Applications should implement To
Have you tried lowering mapred.job.reuse.jvm.num.tasks ?
On Sun, Sep 26, 2010 at 3:30 AM, Bradford Stephens <
bradfordsteph...@gmail.com> wrote:
> Nope, that didn't seem to help.
>
> On Sun, Sep 26, 2010 at 1:00 AM, Bradford Stephens
> wrote:
> > I'm going to try running it on high-RAM boxes wit
fwiw
I run m2.xlarge slaves, using the default mappers/reducers (4/2 i think).
with swap
--bootstrap-action
s3://elasticmapreduce/bootstrap-actions/create-swap-file.rb --args
"-E,/mnt/swap,1000"
historically i'v run this property with no issues, but should probably
re-research the gc setti
The old GC routinely gives me lower performance than modern GC. The default
is now quite good for batch programs.
On Sun, Sep 26, 2010 at 8:10 AM, Chris K Wensel wrote:
> historically i'v run this property with no issues, but should probably
> re-research the gc setting (comments please)
> "ma
My feeling is that you have some kind of leak going on in your mappers or
reducers and that reducing the number of times the jvm is re-used would
improve matters.
GC overhead limit indicates that your (tiny) heap is full and collection is
not reducing that.
On Sun, Sep 26, 2010 at 12:55 AM, Bradf
Have you ever check the log file in the directory?
I always find some important information there,
I suggest you to recompile hadoop with ant since mapred daemons also don't
work
Nan
On Sun, Sep 26, 2010 at 7:29 PM, He Chen wrote:
> The problem is every datanode may be listed in the error rep
Hrm no. I've lowered it to -1, but I can try 1 again.
On Sun, Sep 26, 2010 at 6:47 AM, Ted Yu wrote:
> Have you tried lowering mapred.job.reuse.jvm.num.tasks ?
>
> On Sun, Sep 26, 2010 at 3:30 AM, Bradford Stephens <
> bradfordsteph...@gmail.com> wrote:
>
>> Nope, that didn't seem to help.
>>
-1 means there is no limit to reusing.
At the same time, you can generate heap dump from OOME and analyze with
YourKit, etc.
Cheers
On Sun, Sep 26, 2010 at 1:19 PM, Bradford Stephens <
bradfordsteph...@gmail.com> wrote:
> Hrm no. I've lowered it to -1, but I can try 1 again.
>
> On Sun, Sep
Sadly, making Chris's changes didn't help.
Here's the Cascading code, it's pretty simple but uses the new
"combiner"-like functionality:
http://pastebin.com/ccvDmLSX
On Sun, Sep 26, 2010 at 9:37 AM, Ted Dunning wrote:
> My feeling is that you have some kind of leak going on in your mappers or
Try using a lower threshold value (the num of values in the LRU to cache). this
is the tradeoff of this approach.
ckw
On Sep 26, 2010, at 4:46 PM, Bradford Stephens wrote:
> Sadly, making Chris's changes didn't help.
>
> Here's the Cascading code, it's pretty simple but uses the new
> "combine
Yup, I've turned it down to 1,000. Let's see if that helps!
On Sun, Sep 26, 2010 at 5:09 PM, Chris K Wensel wrote:
> Try using a lower threshold value (the num of values in the LRU to cache).
> this is the tradeoff of this approach.
>
> ckw
>
> On Sep 26, 2010, at 4:46 PM, Bradford Stephens wrot
Hi Bradford,
Sometimes the reducers do not handle merging large chunks of data too well:
How many reducers do you have? Try to increase the # of reducers (you can
always merge the data later if you are worried about too many output files).
--
Alex Kozlov
Solutions Architect
Cloudera, Inc
twitte
One of the problems with this data set is that I'm grouping by a
category that has only, say, 20 different values. Then I'm doing a
unique count of Facebook user IDs per group. I imagine that's not
pleasant for the reducers.
On Sun, Sep 26, 2010 at 5:41 PM, Alex Kozlov wrote:
> Hi Bradford,
>
> S
If there are combiners, the reducers shouldn't get any lists longer than a
small multiple of the number of maps.
On Sun, Sep 26, 2010 at 6:01 PM, Bradford Stephens <
bradfordsteph...@gmail.com> wrote:
> One of the problems with this data set is that I'm grouping by a
> category that has only, say
Hi, all
I'm not sure which mail list I should send my question to, sorry for any
inconvenience I brought
I'm interested in that how hadoop handles the lost of intermediate data
generated by map tasks currently, as some papers suggest, for the situation
that the data needed by reducers are lost
20 matches
Mail list logo
