was none – I calculated my
throughputs pre-maturely.
Thanks,
Ralph
From: Gabriel Reid [mailto:gabriel.r...@gmail.com]
Sent: Friday, April 03, 2015 7:05 AM
To: user@phoenix.apache.org
Subject: Re: bulk loader MR counters
About the record count differences: the output values of the mapper are
0 MB rather than the default 100 MB
>
> b) *mapreduce.task.io.sort.factor* to have higher number of streams to
> merge at once during sorting map output .
>
> Regards
>
> Ravi
>
>
>
>
>
> *From:* Perko, Ralph J
> *Sent:* Thursday, April 02, 2015 2:36 PM
>
02, 2015 2:35 PM
> To: user@phoenix.apache.org
> Subject: Re: bulk loader MR counters
>
>
>
> Hi Ralph.
>
> I assume when you are running the MR for the main table, you have a
> larger number of columns to load than the MR for the index table due to
> which you s
Thanks - I will try your suggestion. Do you know why there are so some many
more output than input records on the main table (39x more).
From: Ravi Kiran [mailto:maghamraviki...@gmail.com]
Sent: Thursday, April 02, 2015 2:35 PM
To: user@phoenix.apache.org
Subject: Re: bulk loader MR counters
My apologies, the formatting did not come out as planned. Here is another go:
Hi, we recently upgraded our cluster (Phoenix 4.3 - HDP 2.2) and I'm seeing a
significant degradation in performance. I am going through the MR counters for
a Phoenix CsvBulkLoad job and I am hoping you can help me u
Hi Ralph.
I assume when you are running the MR for the main table, you have a
larger number of columns to load than the MR for the index table due to
which you see more spilled records.
To tune the MR for the Main table, I would do the following first and then
measure the counters to see for
Hi, we recently upgraded our cluster (Phoenix 4.3 – HDP 2.2) and I’m seeing a
significant degradation in performance. I am going through the MR counters for
a Phoenix CsvBulkLoad job and I am hoping you can help me understand some
things.
There is a base table with 4 index tables, so a total o
