From user-return-33170-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Thu Apr 4 00:43:01 2013 Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-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 9ED85F97D for ; Thu, 4 Apr 2013 00:43:01 +0000 (UTC) Received: (qmail 35175 invoked by uid 500); 4 Apr 2013 00:42:59 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 35127 invoked by uid 500); 4 Apr 2013 00:42:59 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 35119 invoked by uid 99); 4 Apr 2013 00:42:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Apr 2013 00:42:59 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [208.113.200.5] (HELO homiemail-a50.g.dreamhost.com) (208.113.200.5) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Apr 2013 00:42:54 +0000 Received: from homiemail-a50.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a50.g.dreamhost.com (Postfix) with ESMTP id 8F80B6F8062 for ; Wed, 3 Apr 2013 17:42:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thelastpickle.com; h=from :content-type:message-id:mime-version:subject:date:references:to :in-reply-to; s=thelastpickle.com; bh=KbsHYyy5ThGgfBYN/ZWVR6pHSO A=; b=iZ6RZfBuhhRbF3GkhIBIVWDhoX28iIBfk1ALnoEuDugn2D4Ft6zW2k3ANv 9cKVLqt7x6OFD4AUQmtWCX1xY0FrCxK3m6b/5HoKwiMnPdJrQdUvfDy6FjCAFZXt QVBMlPevtPyBtaZhfTxC+n+AUNvaZEzQXtvM00r6tQ9UhOFpc= Received: from [172.20.2.191] (unknown [115.112.62.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aaron@thelastpickle.com) by homiemail-a50.g.dreamhost.com (Postfix) with ESMTPSA id 6C50D6F8055 for ; Wed, 3 Apr 2013 17:42:33 -0700 (PDT) From: aaron morton Content-Type: multipart/alternative; boundary="Apple-Mail=_E023324B-96C2-43A3-916C-8C8EBA1418FD" Message-Id: <4A39C5E9-1902-4251-9B77-1566C1A0556A@thelastpickle.com> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: how to test our transfer speeds Date: Thu, 4 Apr 2013 06:12:29 +0530 References: To: user@cassandra.apache.org In-Reply-To: X-Mailer: Apple Mail (2.1499) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_E023324B-96C2-43A3-916C-8C8EBA1418FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 JBOD as talked about here = http://www.datastax.com/wp-content/uploads/2012/08/C2012-StateofCassandra-= JonathanEllis.pdf and defined by disk_failure_policy So that when you have very large nodes disk failed does not require a = full replacement. But if you are using a high level raid guess that's = not necessary.=20 Cheers ----------------- Aaron Morton Freelance Cassandra Consultant New Zealand @aaronmorton http://www.thelastpickle.com On 2/04/2013, at 6:35 PM, "Hiller, Dean" wrote: > Oh, JBOD, not JBOB. >=20 > no, we were using RAID 5 and RAID 6 from what I understand. I am = trying to get a test run with just one disk to make sure the test is = correct as one disk should have much less performance than 20 in the = case of random access. In sequential, I think performance would be the = same(ie. Both would be 250MB/sec in throughput is my guess) > Thanks, > Dean >=20 > From: , Nrel = > > Date: Tuesday, April 2, 2013 6:40 AM > To: "user@cassandra.apache.org" = > > Subject: Re: how to test our transfer speeds >=20 > Is 1.2 JBOB and april fools joke? Heh, seriously though, I have no = idea what you are talking about there. I am trying to get raw disk = performance with no cassandra involved before involving = cassandra=85..which is the next step. >=20 > Thanks, > Dean >=20 > From: aaron morton = > > Reply-To: = "user@cassandra.apache.org" = > > Date: Monday, April 1, 2013 11:01 PM > To: "user@cassandra.apache.org" = > > Subject: Re: how to test our transfer speeds >=20 > If not, maybe I just generate the same 1,000,000 files on each = machine, then randomly delete 1/2 the files and stream them from the = other machine as writing those files would all be in random locations = again forcing a much worse measurement of MB/sec I would think. > Not sure I understand the question. But you could just scrub the data = off a node and rebuild it. >=20 > Note that streaming is throttled, and it will also generate = compaction. >=20 > He has twenty 1T drives on each machine and I think he also tried with = one 1T drive seeing the same performance which makes sense if writing = sequentially > Are you using the 1.2 JBOB configuration? >=20 > Cheers >=20 > ----------------- > Aaron Morton > Freelance Cassandra Consultant > New Zealand >=20 > @aaronmorton > http://www.thelastpickle.com >=20 > On 1/04/2013, at 11:01 PM, "Hiller, Dean" = > wrote: >=20 > (we plan on running similar performance tests on cassandra but wanted = to understand the raw foot print first)=85.. >=20 > Someone in ops was doing a test transferring 1T of data from one node = to another. I had a huge concern I emailed him that this could end up = being a completely sequential write not testing random access speeds. = He has twenty 1T drives on each machine and I think he also tried with = one 1T drive seeing the same performance which makes sense if writing = sequentially. Does anyone know of something that could generate a = random access pattern such that we could time that? =10Right now, he = was measuring 253MB / second from the time it took and the 1T of data. = I would like to find the much worse case of course. >=20 > If not, maybe I just generate the same 1,000,000 files on each = machine, then randomly delete 1/2 the files and stream them from the = other machine as writing those files would all be in random locations = again forcing a much worse measurement of MB/sec I would think. >=20 > Thoughts? >=20 > Thanks, > Dean >=20 --Apple-Mail=_E023324B-96C2-43A3-916C-8C8EBA1418FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 JBOD = as talked about here http://www.datastax.com/wp-content/uploads/2012= /08/C2012-StateofCassandra-JonathanEllis.pdf and defined = by disk_failure_policy

So that when you have = very large nodes disk failed does not require a full replacement. But if = you are using a high level raid guess that's not = necessary. 

Cheers

http://www.thelastpickle.com

On 2/04/2013, at 6:35 PM, "Hiller, Dean" <Dean.Hiller@nrel.gov> = wrote:

Oh, JBOD, not JBOB.

no, we were using RAID 5 and = RAID 6 from what I understand.  I am trying to get a test run with = just one disk to make sure the test is correct as one disk should have = much less performance than 20 in the case of random access.  In = sequential, I think performance would be the same(ie. Both would be = 250MB/sec in throughput is my guess)
Thanks,
Dean

From: = <Hiller>, Nrel <Dean.Hiller@nrel.gov<mailto:Dean.Hiller@nrel.gov>&g= t;
Date: Tuesday, April 2, 2013 6:40 AM
To: "user@cassandra.apache.org<= ;mailto:user@cassandra.apache.org= >" <user@cassandra.apache.org<= ;mailto:user@cassandra.apache.org= >>
Subject: Re: how to test our transfer speeds

Is = 1.2 JBOB and april fools joke?  Heh, seriously though, I have no = idea what you are talking about there.  I am trying to get raw disk = performance with no cassandra involved before involving = cassandra=85..which is the next = step.

Thanks,
Dean

From: aaron morton <aaron@thelastpickle.com<mailto:aaron@thelastpickle.com= >>
Reply-To: "user@cassandra.apache.org<= ;mailto:user@cassandra.apache.org= >" <user@cassandra.apache.org<= ;mailto:user@cassandra.apache.org= >>
Date: Monday, April 1, 2013 11:01 PM
To: "user@cassandra.apache.org<= ;mailto:user@cassandra.apache.org= >" <user@cassandra.apache.org<= ;mailto:user@cassandra.apache.org= >>
Subject: Re: how to test our transfer speeds

If = not, maybe I just generate the same 1,000,000 files on each machine, = then randomly delete 1/2 the files and stream them from the other = machine as writing those files would all be in random locations again = forcing a much worse measurement of MB/sec I would think.
Not sure I = understand the question. But you could just scrub the data off a node = and rebuild it.

Note that streaming is throttled, and it will = also generate compaction.

He has twenty 1T drives on each machine = and I think he also tried with one 1T drive seeing the same performance = which makes sense if writing sequentially
Are you using the 1.2 JBOB = configuration?

Cheers

-----------------
Aaron = Morton
Freelance Cassandra Consultant
New = Zealand

@aaronmorton
http://www.thelastpickle.com
=
On 1/04/2013, at 11:01 PM, "Hiller, Dean" = <Dean.Hiller@nrel.gov<mailto:Dean.Hiller@nrel.gov>> = wrote:

(we plan on running similar performance tests on cassandra = but wanted to understand the raw foot print first)=85..

Someone = in ops was doing a test transferring 1T of data from one node to = another.  I had a huge concern I emailed him that this could end up = being a completely sequential write not testing random access speeds. =  He has twenty 1T drives on each machine and I think he also tried = with one 1T drive seeing the same performance which makes sense if = writing sequentially.  Does anyone know of something that could = generate a random access pattern such that we could time that? =  =10Right now, he was measuring 253MB / second from the time it = took and the 1T of data.  I would like to find the much worse case = of course.

If not, maybe I just generate the same 1,000,000 files = on each machine, then randomly delete 1/2 the files and stream them from = the other machine as writing those files would all be in random = locations again forcing a much worse measurement of MB/sec I would = think.

Thoughts?

Thanks,
Dean

<= br>
= --Apple-Mail=_E023324B-96C2-43A3-916C-8C8EBA1418FD--