Reads are mostly limited by IO so I’d set concurrent_read to something
related to your disks, we have set it to 64 (yet we have SSDs)
Writes are mostly limited by CPU, so the number of cores matter, we set
concurrent_read to 48 and 128 (depending on the CPU on the nodes)
Careful with LCS it is
sorry i take that back we will modify different keys across threads not the
same key, our storm topology is going to use field grouping to get updates
for same keys to same set of bolts.
On Tue, Apr 21, 2015 at 6:17 PM, Anishek Agarwal anis...@gmail.com wrote:
@Bruice : I dont think so as i am
@Bruice : I dont think so as i am giving each thread a specific key range
with no overlaps this does not seem to be the case now. However we will
have to test where we have to modify the same key across threads -- do u
think that will cause a problem ? As far as i have read LCS is recommended
for
I’m not sure I get everything about storm stuff, but my understanding of
LCS is that compaction count may increase the more one update data (that’s
why I was wondering about duplicate primary keys).
Another option is that the code is sending too much write request/s to the
cassandra cluster. I
Are you on version 2.1.x?
Regards,
Carlos Juzarte Rolo
Cassandra Consultant
Pythian - Love your data
rolo@pythian | Twitter: cjrolo | Linkedin: *linkedin.com/in/carlosjuzarterolo
http://linkedin.com/in/carlosjuzarterolo*
Mobile: +31 6 159 61 814 | Tel: +1 613 565 8696 x1649
www.pythian.com
On
Could it that the app is inserting _duplicate_ keys ?
-- Brice
On Tue, Apr 21, 2015 at 1:52 PM, Marcus Eriksson krum...@gmail.com wrote:
nope, but you can correlate I guess, tools/bin/sstablemetadata gives you
sstable level information
and, it is also likely that since you get so many L0
I want to draw a distinction between a) multithreaded compaction (the jira
I just pointed to) and b) concurrent_compactors. I'm not clear on which one
you are recommending at this stage.
a) Multithreaded compaction is what I warned against in my last note. b)
Concurrent compactors is the number
Do not enable multithreaded compaction. Overhead usually outweighs any
benefit. It's removed in 2.1 because it harms more than helps:
https://issues.apache.org/jira/browse/CASSANDRA-6142
All the best,
[image: datastax_logo.png] http://www.datastax.com/
Sebastián Estévez
Solutions Architect |
Thanks Brice for the input,
I am confused as to how to calculate the value of concurrent_read,
following is what i found recommended on sites and in configuration docs.
concurrent_read : some places its 16 X number of drives or 4 X number of
cores
which of the above should i pick ? i have 40
Yes I was referring referring to multithreaded_compaction, but just because
we didn’t get bitten by this setting just doesn’t mean it’s right, and the
jira is a clear indication of that ;)
@Anishek that reminds me of these settings to look at as well:
- concurrent_write and concurrent_read
@Marcus I did look and that is where i got the above but it doesnt show any
detail about moving from L0 -L1 any specific arguments i should try with ?
On Tue, Apr 21, 2015 at 4:52 PM, Marcus Eriksson krum...@gmail.com wrote:
you need to look at nodetool compactionstats - there is probably a big
nope, but you can correlate I guess, tools/bin/sstablemetadata gives you
sstable level information
and, it is also likely that since you get so many L0 sstables, you will be
doing size tiered compaction in L0 for a while.
On Tue, Apr 21, 2015 at 1:40 PM, Anishek Agarwal anis...@gmail.com wrote:
the some_bits column has about 14-15 bytes of data per key.
On Tue, Apr 21, 2015 at 4:34 PM, Anishek Agarwal anis...@gmail.com wrote:
Hello,
I am inserting about 100 million entries via datastax-java driver to a
cassandra cluster of 3 nodes.
Table structure is as
create keyspace test
you need to look at nodetool compactionstats - there is probably a big L0
- L1 compaction going on that blocks other compactions from starting
On Tue, Apr 21, 2015 at 1:06 PM, Anishek Agarwal anis...@gmail.com wrote:
the some_bits column has about 14-15 bytes of data per key.
On Tue, Apr 21,
I am on version 2.0.14, will update once i get the stats up for the writes
again
On Tue, Apr 21, 2015 at 4:46 PM, Carlos Rolo r...@pythian.com wrote:
Are you on version 2.1.x?
Regards,
Carlos Juzarte Rolo
Cassandra Consultant
Pythian - Love your data
rolo@pythian | Twitter: cjrolo |
Oh, thank you Sebastian for this input and the ticket reference !
We did notice an increase in CPU usage, but kept the concurrent compaction
low enough for our usage, by default it takes the number of cores. We did
use a number up to 30% of our available cores. But under heavy load clearly
CPU is
16 matches
Mail list logo
