Aaron,
Thanks for your email. The test kinda resembles how the actual application
will be.
It is going to be a simple key-value store with 500 million keys per node.
The traffic will be read heavy in steady state, and there will be some keys
that will have a lot more traffic than others. The
You may also consider disabling key/row cache at all.
1mm rows * 400 bytes = 400MB of data, can easily be in fs cache, and you
will access your hot keys with thousands of qps without hitting disk at all.
Enabling compression can make situation even better.
On Thu, May 31, 2012 at 12:01 PM,
But I think it's bad idea, since hot data will be evenly distributed
between multiple sstables and filesystem pages.
On Thu, May 31, 2012 at 1:08 PM, crypto five cryptof...@gmail.com wrote:
You may also consider disabling key/row cache at all.
1mm rows * 400 bytes = 400MB of data, can easily
80 ms per request
sounds high.
I'm doing some guessing here, i am guessing memory usage is the problem..
* I assume you are not longer seeing excessive GC activity.
* The key cache will not get used when you hit the row cache. I would disable
the row cache if you have a random workload,
Hi Aaron,
Here is the latest on this..
i switched to a node with 6 disks and running some read tests, and i am
seeing something weird.
setup:
1 node, cassandra 1.0.9, 8 cpu, 16 gig RAM, 6 7200 rpm SATA data disks
striped 512 kb, commitlog mirrored.
1 keyspace with just 1 column family
random
With
heap size = 4 gigs
I would check for GC activity in the logs and consider setting it to 8 given
you have 16 GB. You can also check if the IO system is saturated
(http://spyced.blogspot.co.nz/2010/01/linux-performance-basics.html) Also take
a look at nodetool cfhistogram perhaps to see
Dne 19.5.2012 0:09, Gurpreet Singh napsal(a):
Thanks Radim.
Radim, actually 100 reads per second is achievable even with 2 disks.
it will become worse as rows will get fragmented.
But achieving them with a really low avg latency per key is the issue.
I am wondering if anyone has played with
Sent: Thursday, May 17, 2012 20:24
To: user@cassandra.apache.org
Subject: Re: cassandra read latency help
Thanks Viktor for the advice.
Right now, i just have 1 node that i am
]
*Sent:* Thursday, May 17, 2012 20:24
*To:* user@cassandra.apache.org
*Subject:* Re: cassandra read latency help
** **
Thanks Viktor for the advice.
Right now, i just have 1 node that i am testing against and i am using CL
one.
Are you suggesting that the page cache might
to get 100 random reads per second on large dataset (100 GB) you need
more disks in raid 0 then 2.
Better is to add more nodes then stick too much disks into node. You
need also adjust io scheduler in OS.
Thanks Radim.
Radim, actually 100 reads per second is achievable even with 2 disks.
But achieving them with a really low avg latency per key is the issue.
I am wondering if anyone has played with index_interval, and how much of a
difference would it make to reads on reducing the index_interval. I
Gurpreet Singh wrote:
Any ideas on what could help here bring down the read latency even more ?
Avoid Cassandra forwarding request to other nodes:
- Use consistency level ONE;
- Create data model to do single request with single key, since different keys
may belong to different nodes and
Thanks Viktor for the advice.
Right now, i just have 1 node that i am testing against and i am using CL
one.
Are you suggesting that the page cache might be doing better than the row
cache?
I am getting row cache hit of 0.66 right now.
/G
On Thu, May 17, 2012 at 12:26 AM, Viktor Jevdokimov
, please contact the sender immediately and irrevocably delete
this message and any copies.
From: Gurpreet Singh [mailto:gurpreet.si...@gmail.com]
Sent: Thursday, May 17, 2012 20:24
To: user@cassandra.apache.org
Subject: Re: cassandra read latency help
Thanks Viktor for the advice.
Right now, i just
14 matches
Mail list logo
