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. (?)
On Wed, Nov 5, 2014 at 11:00 PM, Jimmy Lin 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 can reorder t
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
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 threa
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 dif
