So, you're doing about 20 ops/s where each op consists of "read 2
metadata columns, then read ~250 columns of ~2K each." Is that right?
Is your test client multithreaded? Is it on a separate machine from
the Cassandra server?
What is your bottleneck?
http://spyced.blogspot.com/2010/01/linux-per
Hi Aaron,
Thank you for guiding us by breaking down the issue. Please see my answers
embedded
> Is this a single client ?
Yes
> How many columns is it asking for ?
the client knows a list of all row keys, and it randomly picks 100, and
loops 100 times. It first reads a metadata column to fig
> The read rate that I have been seeing is about 3MB/sec, and that is reading
> the raw bytes... using string serializer the rate is even lower, about
> 2.2MB/sec.
Can we break this down a bit:
Is this a single client ?
How many columns is it asking for ?
What sort of query are you sending, s
Thanks Aaron. The reason I raised the question about memory requirements
is because we are seeing some very low performance on cassandra read.
We are using cassandra as the backend for an IR repository, and granted the
size of each column is very small (OCRed text). Each row represents a book
vo
The JVM will not swap out if you have JNA.jar in the path or you have disabled
swap on the machine (the simplest thing to do).
Cassandra uses memory mapped file access. If you have 16GB of ram, 8 will go to
the JVM and the rest can be used by the os to cache files. (Plus the off heap
stuff)
C
Thanks Tyler... so my understanding is, even if Cassandra doesn't do
off-heap caching, by having a large-enough memory, it minimize the chance
of swapping the java heap to a disk. Is that correct?
-- Y.
On Tue, May 15, 2012 at 6:26 PM, Tyler Hobbs wrote:
> On Tue, May 15, 2012 at 3:19 PM, Yimi
On Tue, May 15, 2012 at 3:19 PM, Yiming Sun wrote:
> Hello,
>
> I was reading the Apache Cassandra 1.0 Documentation PDF dated May 10,
> 2012, and had some questions on what the recommended memory size is.
>
> Below is the snippet from the PDF. Bullet 1 suggests to have 16-32GB of
> RAM, yet Bul
