On Wed, Nov 5, 2014 at 11:00 PM, Jimmy Lin y2klyf+w...@gmail.com wrote:
Sorry I have late follow up question
In the Cassandra.yaml file the concurrent_read section has the following
comment:
What does it mean by the operations to enqueue low enough in the stack
that the OS and drives
I see, thanks for explaining what that means.
If we are using SSD, then reordering/merging has less impact than
traditional mechanical hard disk, so using SSD drive probably can deal
with increased concurrent_read better. (?)
Sorry I have late follow up question
In the Cassandra.yaml file the concurrent_read section has the following
comment:
What does it mean by the operations to enqueue low enough in the stack
that the OS and drives can reorder them. ? how does it help making the
system healthy?
What really
Hi,
looking at the docs, the default value for concurrent_reads is 32, which
seems bit small to me (comparing to say http server)? because if my node is
receiving slight traffic, any more than 32 concurrent read query will have
to wait.(?)
Recommend rule is, 16* number of drives. Would that be
Theres a bit to it, sometimes it can use tweaking though. Its a good
default for most systems so I wouldn't increase right off the bat. When
using ssds or something with a lot of horsepower it could be higher though
(ie i2.xlarge+ on ec2). If you monitor the number of active threads in
read
