cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Ellis <jbel...@gmail.com>
Subject Re: Cassandra hardware setup
Date Wed, 26 Aug 2009 16:37:43 GMT
On Tue, Aug 25, 2009 at 7:07 PM, Scott Chacon<schacon@gmail.com> wrote:
> We're playing with Cassandra and would like to get a test cluster
> setup for evaluation.  I've been playing with it on my laptop and EC2,
> which are the resources easily available to me, but not that close to
> what I would be using in a production environment.

Yeah, EC2 is io hell.

Jason at slicehost thinks their VMs and cloud servers' should post
better numbers, fwiw, but it's still going to be best to run on
non-virtualized hardware.

> What would be an ideal machine setup for a Cassandra node?  At least
> two separate physical disks, one for the commit log and another for
> the data, no RAID, 8-16G memory? (I think that's what Evan recommended
> in his blog post)

Right.  Right now you don't get a huge win on writes from going over
commitlog disk + 1 disk per heavily-written columnfamily, but if you
can get to 3 or 4 without much extra cost (e.g. staying in 1U) it will
help read seeks linearly, on average.  So more is better.

If you do have multiple data disks, I would expect JBOD to work better
than raid0-ing things.  (Mostly a wash on writes, but better read
performance.)  But I don't know if anyone has actually tested this.

Digg is running on 16GB machines with a 10 GB heap size, which you can
set in cassandra.in.sh.

Cassandra defaults are tuned so that you can test things out on a 1GB
heap without OOM-ing.  Look in the peformance section; the main ones
are

MemtableSizeInMB
MemtableObjectCountInMillions

If you are also using a 10GB heap then you can just multiply these by
10 as a first step.

If you are using 8 cores you probably want to double ConcurrentReads too.

-Jonathan

Mime
View raw message