Return-Path: X-Original-To: apmail-accumulo-user-archive@www.apache.org Delivered-To: apmail-accumulo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4E587E52E for ; Tue, 4 Dec 2012 18:06:40 +0000 (UTC) Received: (qmail 3180 invoked by uid 500); 4 Dec 2012 18:06:40 -0000 Delivered-To: apmail-accumulo-user-archive@accumulo.apache.org Received: (qmail 3148 invoked by uid 500); 4 Dec 2012 18:06:40 -0000 Mailing-List: contact user-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@accumulo.apache.org Delivered-To: mailing list user@accumulo.apache.org Received: (qmail 3135 invoked by uid 99); 4 Dec 2012 18:06:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Dec 2012 18:06:40 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of christopher.burrell@gmail.com designates 209.85.210.180 as permitted sender) Received: from [209.85.210.180] (HELO mail-ia0-f180.google.com) (209.85.210.180) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 Dec 2012 18:06:34 +0000 Received: by mail-ia0-f180.google.com with SMTP id t4so4128414iag.39 for ; Tue, 04 Dec 2012 10:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=I4L4/JpiuFtr0yoclryzq6d29iEhRkS3/bfM5hg7XW8=; b=emjkyVBhss2tCaEq/Eg2xWjfOnJwQj3zb7XY5gpy4tsoSZ9pCXo/MF8ypuSZ1H6J9G 4olwWq5vPGj5DGx1PiN65MzWAFGTMHf2MQTGjCa7nR0AZhgWrsOPFO8QBE9IQBceWpUJ nyctGKP6kz36+RnfmCSRCykIn5LtTe/kkRLXNPkOw8tLUx4Wa5glCHYUR9dl0aFeLyuX hePnu1gACICQKU++BtwSvvTFrq4Z7cT9SbP1X8FPH/ZLYqcLncjDO461UXuAT9krd3Mt fGDmHTglKErwM2L3yzdzm/0OOuNg8nh1q5VKvLRuLr9d5wk34Ix+AX6Z1K2PXXAmLtyQ fbbA== MIME-Version: 1.0 Received: by 10.50.220.166 with SMTP id px6mr3682563igc.8.1354644374147; Tue, 04 Dec 2012 10:06:14 -0800 (PST) Reply-To: chris@burrell.me.uk Sender: christopher.burrell@gmail.com Received: by 10.64.14.166 with HTTP; Tue, 4 Dec 2012 10:06:14 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Dec 2012 18:06:14 +0000 X-Google-Sender-Auth: tHbIirJaBh02k6yUhALb6ixmkFE Message-ID: Subject: Re: Tuning & Compactions From: Chris Burrell To: Eric Newton Cc: user@accumulo.apache.org Content-Type: multipart/alternative; boundary=f46d04389415b7d40e04d00ab831 X-Virus-Checked: Checked by ClamAV on apache.org --f46d04389415b7d40e04d00ab831 Content-Type: text/plain; charset=ISO-8859-1 Thanks for all the comments below. Very helpful! On the last point, around "small indexes", do you mean if your set of keys is small, but having many column-families and column qualifiers? What order of magnitude would you consider to be small? A few million keys/billion keys? Or in another way, keys with 10s/100s of column families/qualifiers. I have another question around the use of column families and qualifiers. Would it be good or bad practice to have many column families/qualifiers per row. I was just wondering if there would be any point in using these almost as extensions to the keys, i.e. the column family/qualifier would end up being the last part of the key. I understand column families can also be used to control how the data gets stored to maximize scanning too. I was just wondering if there would be drawbacks on having many of these. Chris On 28 November 2012 20:31, Eric Newton wrote: > Some comments inlined below: > > On Wed, Nov 28, 2012 at 2:49 PM, Chris Burrell wrote: > >> Hi >> >> I am trialling Accumulo on a small (tiny) cluster and wondering how the >> best way to tune it would be. I have 1 master + 2 tservers. The master has >> 8Gb of RAM and the tservers have each 16Gb each. >> >> I have set the walogs size to be 2Gb with an external memory map of 9G. >> The ratio is still the defaulted to 3. I've also upped the heap sizes of >> each tserver to 2Gb heaps. >> >> I'm trying to achieve high-speed ingest via batch writers held on several >> other servers. I'm loading two separate tables. >> >> Here are some questions I have: >> - Does the config above sound sensible? or overkill? >> > > Looks good to me, assuming you aren't doing other things (like map/reduce) > on the machines. > > >> - Is it preferable to have more servers with lower specs? >> > Yes. Mostly to get more drives. > > >> - Is this the best way to maximise use of the memory? >> > It's not bad. You may want to have larger block caches and a smaller > in-memory map. But if you want to write-mostly, read-little, this is good. > > >> - Does the fact I have 3x2Gb walogs, means that the remaining 3Gb in the >> external memory map can be used while compactions occur? >> > > Yes. You will want to increase the size or number of logs. With that > many servers, failures will hopefully be very rare. I would go with > changing 3 to 8. Having lots of logs on a tablet is no big deal if you > have disk space, and don't expect many failures. > > >> - When minor compactions occur, does this halt ingest on that particular >> tablet? or tablet server? >> > Only if memory fills before the compactions finish. The monitor page will > indicate this by displaying "hold time." When this happens the tserver > will self-tune and start minor compactions earlier with future ingest. > > >> - I have pre-split the tables six-ways, but not entirely sure if that's >> preferable if I only have 2 servers while trying it out? Perhaps 2 ways >> might be better? >> > Not for that reason, but to be able to use more cores concurrently. Aim > for 50-100 tablets/node. > > >> - Does the batch upload through the shell client give significantly >> better performance stats? >> > > Using map/reduce to create RFiles is more efficient. But it also increases > latency: you only can see the data when the whole file is loaded. > > When a file is batch-loaded, its index is read, and the file is assigned > to matching tablets. With small indexes, you can batch-load terabytes in > minutes. > > -Eric > > --f46d04389415b7d40e04d00ab831 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for all = the comments below. Very helpful!=A0

On the last point, around "small indexes", do you mean if your se= t of keys is small, but having many column-families and column qualifiers? = What order of magnitude would you consider to be small? A few million keys/= billion keys? Or in another way, keys with 10s/100s of column families/qual= ifiers.

I have another questio= n around the use of column families and qualifiers. Would it be good or bad= practice to have many column families/qualifiers per row. =A0I was just wo= ndering if there would be any point in using these almost as extensions to = the keys, i.e. the column family/qualifier would end up being the last part= of the key. I understand column families can also be used to control how t= he data gets stored to maximize scanning too. I was just wondering if there= would be drawbacks on having many of these.

Chris



On 28 November 2012 20:31, Eric Newton <= span dir=3D"ltr"><eric.newton@gmail.com> wrote:
Some comments inlined below:

On Wed, Nov 28, 2012 at 2:49 PM, Chris B= urrell <chris@burrell.me.uk> wrote:
Hi

I am trialling Accumulo on a small (= tiny) cluster and wondering how the best way to tune it would be. I have 1 = master + 2 tservers. The master has 8Gb of RAM and the tservers have each 1= 6Gb each.

I have set the walogs size to be 2Gb with an external m= emory map of 9G. The ratio is still the defaulted to 3. I've also upped= the heap sizes of each tserver to 2Gb heaps.=A0

I'm trying to achieve high-speed ingest via batch writers held on sever= al other servers. I'm loading two separate tables.=A0

Here are some questions I have:
- Does the config above s= ound sensible? or overkill?
=A0
Looks good to me, assuming you aren&#= 39;t doing other things (like map/reduce) on the machines.
=A0
-=A0Is it preferable to have more servers with lower specs?
Yes. =A0Mostly to get more drives.
=A0
-=A0Is this the best way to maximise use of the memory?
It's not bad. =A0You may want to have larger block cache= s and a smaller in-memory map. =A0But if you want to write-mostly, read-lit= tle, this is good.
=A0
-=A0Does the fact I have 3x2Gb walogs, = means that the remaining 3Gb in the external memory map can be used while c= ompactions occur?

Yes. =A0You will want to increase th= e size or number of logs. =A0With that many servers, failures will hopefull= y be very rare. =A0I would go with changing 3 to 8. =A0Having lots of logs = on a tablet is no big deal if you have disk space, and don't expect man= y failures.
=A0
-=A0When minor compactions occur, does this halt ingest on that partic= ular tablet? or tablet server?
Only if memory = fills before the compactions finish. The monitor page will indicate this by= displaying "hold time." =A0When this happens the tserver will se= lf-tune and start minor compactions earlier with future ingest. =A0
=A0
-=A0I have pre-split the tables six-way= s, but not entirely sure if that's preferable if I only have 2 servers = while trying it out? Perhaps 2 ways might be better?
Not for that reason, but to be able to use more cor= es concurrently. =A0Aim for 50-100 tablets/node.
=A0
-=A0Does the batch upload through the shell client give significantly = better performance stats?
=A0
Using = map/reduce to create RFiles is more efficient. But it also increases latenc= y: you only can see the data when the whole file is loaded.

When a file is batch-loaded, its index is read, and the= file is assigned to matching tablets. =A0With small indexes, you can batch= -load terabytes in minutes.=A0
=A0
-Eric


--f46d04389415b7d40e04d00ab831--