Re: Cassandra OOM on joining existing ring

2015-07-12 Thread Kunal Gangakhedkar
Hi,

Looks like that is my primary problem - the sstable count for the
daily_challenges column family is 5k. Azure had scheduled maintenance
window on Sat. All the VMs got rebooted one by one - including the current
cassandra one - and it's taking forever to bring cassandra back up online.

Is there any way I can re-organize my existing data? so that I can bring
down that count?
I don't want to lose that data.
If possible, can I do that while cassandra is down? As I mentioned, it's
taking forever to get the service up - it's stuck in reading those 5k
sstable (+ another 5k of corresponding secondary index) files. :(
Oh, did I mention I'm new to cassandra?

Thanks,
Kunal

Kunal

On 11 July 2015 at 03:29, Sebastian Estevez sebastian.este...@datastax.com
wrote:

 #1

 There is one table - daily_challenges - which shows compacted partition
 max bytes as ~460M and another one - daily_guest_logins - which shows
 compacted partition max bytes as ~36M.


 460 is high, I like to keep my partitions under 100mb when possible. I've
 seen worse though. The fix is to add something else (maybe month or week or
 something) into your partition key:

  PRIMARY KEY ((segment_type, something_else), date, user_id, sess_id)

 #2 looks like your jam version is 3 per your env.sh so you're probably
 okay to copy the env.sh over from the C* 3.0 link I shared once you
 uncomment and tweak the MAX_HEAP. If there's something wrong your node
 won't come up. tail your logs.



 All the best,


 [image: datastax_logo.png] http://www.datastax.com/

 Sebastián Estévez

 Solutions Architect | 954 905 8615 | sebastian.este...@datastax.com

 [image: linkedin.png] https://www.linkedin.com/company/datastax [image:
 facebook.png] https://www.facebook.com/datastax [image: twitter.png]
 https://twitter.com/datastax [image: g+.png]
 https://plus.google.com/+Datastax/about
 http://feeds.feedburner.com/datastax

 http://cassandrasummit-datastax.com/

 DataStax is the fastest, most scalable distributed database technology,
 delivering Apache Cassandra to the world’s most innovative enterprises.
 Datastax is built to be agile, always-on, and predictably scalable to any
 size. With more than 500 customers in 45 countries, DataStax is the
 database technology and transactional backbone of choice for the worlds
 most innovative companies such as Netflix, Adobe, Intuit, and eBay.

 On Fri, Jul 10, 2015 at 2:44 PM, Kunal Gangakhedkar 
 kgangakhed...@gmail.com wrote:

 And here is my cassandra-env.sh
 https://gist.github.com/kunalg/2c092cb2450c62be9a20

 Kunal

 On 11 July 2015 at 00:04, Kunal Gangakhedkar kgangakhed...@gmail.com
 wrote:

 From jhat output, top 10 entries for Instance Count for All Classes
 (excluding platform) shows:

 2088223 instances of class org.apache.cassandra.db.BufferCell
 1983245 instances of class
 org.apache.cassandra.db.composites.CompoundSparseCellName
 1885974 instances of class
 org.apache.cassandra.db.composites.CompoundDenseCellName
 63 instances of class
 org.apache.cassandra.io.sstable.IndexHelper$IndexInfo
 503687 instances of class org.apache.cassandra.db.BufferDeletedCell
 378206 instances of class org.apache.cassandra.cql3.ColumnIdentifier
 101800 instances of class org.apache.cassandra.utils.concurrent.Ref
 101800 instances of class
 org.apache.cassandra.utils.concurrent.Ref$State
 90704 instances of class
 org.apache.cassandra.utils.concurrent.Ref$GlobalState
 71123 instances of class org.apache.cassandra.db.BufferDecoratedKey

 At the bottom of the page, it shows:
 Total of 8739510 instances occupying 193607512 bytes.
 JFYI.

 Kunal

 On 10 July 2015 at 23:49, Kunal Gangakhedkar kgangakhed...@gmail.com
 wrote:

 Thanks for quick reply.

 1. I don't know what are the thresholds that I should look for. So, to
 save this back-and-forth, I'm attaching the cfstats output for the 
 keyspace.

 There is one table - daily_challenges - which shows compacted partition
 max bytes as ~460M and another one - daily_guest_logins - which shows
 compacted partition max bytes as ~36M.

 Can that be a problem?
 Here is the CQL schema for the daily_challenges column family:

 CREATE TABLE app_10001.daily_challenges (
 segment_type text,
 date timestamp,
 user_id int,
 sess_id text,
 data text,
 deleted boolean,
 PRIMARY KEY (segment_type, date, user_id, sess_id)
 ) WITH CLUSTERING ORDER BY (date DESC, user_id ASC, sess_id ASC)
 AND bloom_filter_fp_chance = 0.01
 AND caching = '{keys:ALL, rows_per_partition:NONE}'
 AND comment = ''
 AND compaction = {'min_threshold': '4', 'class':
 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
 'max_threshold': '32'}
 AND compression = {'sstable_compression':
 'org.apache.cassandra.io.compress.LZ4Compressor'}
 AND dclocal_read_repair_chance = 0.1
 AND default_time_to_live = 0
 AND gc_grace_seconds = 864000
 AND max_index_interval = 2048
 AND memtable_flush_period_in_ms = 0
 AND min_index_interval = 128
 

Re: Overwhelming tombstones with LCS

2015-07-12 Thread Roman Tkachenko
Hi Dan,

Thanks for the reply. We're on 2.0.13. In fact, I already solved this
exactly the way you described - by changing compaction strategy to STCS via
JMX and letting compactions collect tombstones.

Roman


On Fri, Jul 10, 2015 at 8:57 PM, Dan Kinder dkin...@turnitin.com wrote:


 On Sun, Jul 5, 2015 at 1:40 PM, Roman Tkachenko ro...@mailgunhq.com
 wrote:

 Hey guys,

 I have a table with RF=3 and LCS. Data model makes use of wide rows. A
 certain query run against this table times out and tracing reveals the
 following error on two out of three nodes:

 *Scanned over 10 tombstones; query aborted (see
 tombstone_failure_threshold)*

 This basically means every request with CL higher than one fails.

 I have two questions:

 * How could it happen that only two out of three nodes have overwhelming
 tombstones? For the third node tracing shows sensible *Read 815 live
 and 837 tombstoned cells* traces.


 One theory: before 2.1.6 compactions on wide rows with lots of tombstones
 could take forever or potentially never finish. What version of Cassandra
 are you on? It may be that you got lucky with one node that has been able
 to keep up but the others haven't been able to.



 * Anything I can do to fix those two nodes? I have already set gc_grace
 to 1 day and tried to make compaction strategy more aggressive
 (unchecked_tombstone_compaction - true, tombstone_threshold - 0.01) to no
 avail - a couple of days have already passed and it still gives the same
 error.


 You probably want major compaction which is coming soon for LCS (
 https://issues.apache.org/jira/browse/CASSANDRA-7272) but not here yet.

 The alternative is, if you have enough time and headroom (this is going to
 do some pretty serious compaction so be careful), alter your table to STCS,
 let it compact into one SSTable, then convert back to LCS. It's pretty
 heavy-handed but as long as your gc_grace is low enough it'll do the job.
 Definitely do NOT do this if you have many tombstones in single wide rows
 and are not 2.1.6



 Thanks!

 Roman




 --
 Dan Kinder
 Senior Software Engineer
 Turnitin – www.turnitin.com
 dkin...@turnitin.com



Configuring the java client to retry on write failure.

2015-07-12 Thread Kevin Burton
I can’t seem to find a decent resource to really explain this…

Our app seems to fail some write requests, a VERY low percentage.  I’d like
to retry the write requests that fail due to number of replicas not being
correct.

http://docs.datastax.com/en/developer/java-driver/2.0/common/drivers/reference/tuningPolicies_c.html

This is the best resource I can find.

I think the best strategy is to look at DefaultRetryPolicy and then create
a custom one that keeps retrying on write failures up to say 1 minute.
Latency isn’t critical for us as this is a batch processing system.

The biggest issue is how to test it?  I could unit test that my methods
return on the correct inputs but not really in real world situations.

What’s the best way to unit test this?

-- 

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile
https://plus.google.com/102718274791889610666/posts