cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jimmy Lin <y2klyf+w...@gmail.com>
Subject Re: tuning concurrent_reads param
Date Thu, 06 Nov 2014 07:00:26 GMT
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 happen if we increase it to a too high value? (maybe affecting
other read or write operation as it eat up all disk IO resource?)


thanks


# For workloads with more daa than can fit in memory, Cassandra's
# bottleneck will be reads that need to fetch data from
# disk. "concurrent_reads" shuld be set to (16 * number_of_drives) in
# order to allow the operations to enqueue low enough in the stack
# that the OS and drives can reorder them.

On Wed, Oct 29, 2014 at 8:47 PM, Chris Lohfink <chris.lohfink@datastax.com>
wrote:

> 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 thread pool (nodetool tpstats) you can see if they are actually all
> busy or not.  If its near 32 (or whatever you set it at) all the time it
> may be a bottleneck.
>
> ---
> Chris Lohfink
>
> On Wed, Oct 29, 2014 at 10:41 PM, Jimmy Lin <y2klyf+work@gmail.com> wrote:
>
>> 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 different if I
>> have SSDs?
>>
>> I am attempting to increase it because I have a few tables have wide rows
>> that app will fetch them, the pure size of data may already eating up the
>> thread time, which can cause  other read threads need to wait and essential
>> slow.
>>
>> thanks
>>
>>
>>
>>
>

Mime
View raw message