Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@accumulo.apache.org
Received-SPF: error (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <739FC10C-78D9-46F1-B2F5-EA6D666899A4@argyledata.com>
References: <739FC10C-78D9-46F1-B2F5-EA6D666899A4@argyledata.com>
Date: Sat, 3 Jan 2015 11:28:16 -0500
Message-ID: 
 <CAGUtCHqani8Uo20UAY-Y8Wi+5G9=FBLiEksJ1Kt62mY3v+j7ug@mail.gmail.com>
Subject: Re: AccumuloFileOutputFormat tuning
From: Keith Turner <keith@deenlo.com>
To: user@accumulo.apache.org
Content-Type: multipart/alternative; boundary=047d7b5d51f0c768d7050bc1f12f

--047d7b5d51f0c768d7050bc1f12f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

You can try sampling using jstack as a simple and quick way to profile.
Jstack a process writing rfiles ~10 times, with some pause he tween.  Then
look at a particular thread writing data across the jstack saves, do you
see the same code being executed in multiple jstacks?  If so what code is
that?

Sent from phone. Please excuse typos and brevity.
On Jan 3, 2015 12:46 AM, "Ara Ebrahimi" <ara.ebrahimi@argyledata.com> wrote=
:

> Hi,
>
> I=E2=80=99m trying to optimize our map/reduce job which generates RFiles =
using
> AccumuloFileOutputFormat. We have a specific time window and within that
> time window we need to generate a predefined amount of simulation data an=
d
> in terms of number of core we also have an upper bound we can use. Disks
> are also fixed at 4 per node and they are all SSDs. So I can=E2=80=99t em=
ploy more
> machines or more disks or cores to achieve higher write/s numbers.
>
> So far we=E2=80=99ve managed to utilize 100% of all available cores and t=
he SSD
> disks are also highly utilized. I=E2=80=99m trying to reduce processing t=
ime and we
> are willing to waste more disk space to achieve higher data generation
> speed. The data itself is 10s of columns of floating numbers, all
> serialized to fixed 9-byte values which doesn=E2=80=99t lend well to comp=
ression.
> With no compression and replication set to 1 we can generate the same
> amount of data in almost half the time. With snappy it=E2=80=99s almost 1=
0% more
> data generation time compared to no compression and almost twice more siz=
e
> on disk for the all the generated RFiles.
>
> dataBlockSize doesn=E2=80=99t seem to change anything for non-compressed =
data.
> indexBlockSize also didn't change anything (tried 64K vs the default 128K=
).
>
> Any other tricks I could employ to achieve higher write/s numbers?
>
> Ara.
>
>
>
> ________________________________
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise confidential information. If you ha=
ve
> received it in error, please notify the sender immediately and delete the
> original. Any other use of the e-mail by you is prohibited. Thank you in
> advance for your cooperation.
>
> ________________________________
>

--047d7b5d51f0c768d7050bc1f12f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">You can try sampling using jstack as a simple and quick way =
to profile.=C2=A0 Jstack a process writing rfiles ~10 times, with some paus=
e he tween.=C2=A0 Then look at a particular thread writing data across the =
jstack saves, do you see the same code being executed in multiple jstacks?=
=C2=A0 If so what code is that?</p>
<p dir=3D"ltr">Sent from phone. Please excuse typos and brevity.</p>
<div class=3D"gmail_quote">On Jan 3, 2015 12:46 AM, &quot;Ara Ebrahimi&quot=
; &lt;<a href=3D"mailto:ara.ebrahimi@argyledata.com">ara.ebrahimi@argyledat=
a.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>Hi,<br>
<br>
I=E2=80=99m trying to optimize our map/reduce job which generates RFiles us=
ing AccumuloFileOutputFormat. We have a specific time window and within tha=
t time window we need to generate a predefined amount of simulation data an=
d in terms of number of core we also have an upper bound we can use. Disks =
are also fixed at 4 per node and they are all SSDs. So I can=E2=80=99t empl=
oy more machines or more disks or cores to achieve higher write/s numbers.<=
br>
<br>
So far we=E2=80=99ve managed to utilize 100% of all available cores and the=
 SSD disks are also highly utilized. I=E2=80=99m trying to reduce processin=
g time and we are willing to waste more disk space to achieve higher data g=
eneration speed. The data itself is 10s of columns of floating numbers, all=
 serialized to fixed 9-byte values which doesn=E2=80=99t lend well to compr=
ession. With no compression and replication set to 1 we can generate the sa=
me amount of data in almost half the time. With snappy it=E2=80=99s almost =
10% more data generation time compared to no compression and almost twice m=
ore size on disk for the all the generated RFiles.<br>
<br>
dataBlockSize doesn=E2=80=99t seem to change anything for non-compressed da=
ta. indexBlockSize also didn&#39;t change anything (tried 64K vs the defaul=
t 128K).<br>
<br>
Any other tricks I could employ to achieve higher write/s numbers?<br>
<br>
Ara.<br>
<br>
<br>
<br>
________________________________<br>
<br>
This message is for the designated recipient only and may contain privilege=
d, proprietary, or otherwise confidential information. If you have received=
 it in error, please notify the sender immediately and delete the original.=
 Any other use of the e-mail by you is prohibited. Thank you in advance for=
 your cooperation.<br>
<br>
________________________________<br>
</blockquote></div>

--047d7b5d51f0c768d7050bc1f12f--