compaction behaviour

2011-04-02 Thread Anurag Gujral
Hi All, I have loaded data into cassandra using batch processing the response times for reads are in the range of 0.8 ms but I am using SSDs. so I expect the read times to be even faster. Every time I run compaction the latency numbers reduce to 0.3 to 0.4ms , is there a way I can run

Phantom node keeps coming back

2011-04-02 Thread Jason Harvey
Greetings all, I removetoken'd a node a few weeks back and completely shut down the node which owned that token. Every few days, it shows back up in the ring as "Down" and I have to removetoken it again. Thinking it was an issue with gossip, I shut the ring completely down, deleted all of the hint

Re: Bizarre side-effect of increasing read concurrency

2011-04-02 Thread Jason Harvey
My Xmx and Xms are both 7.5GB. However, I never see the heap usage reach past 5.5. Think it is still a good idea to increase the heap? Thanks, Jason On Apr 2, 2:45 am, Peter Schuller wrote: > > Previously, mark-and-sweep would run around 5.5GB, and would cut heap > > usage to 4GB. Now, it still

AW: too many open files - maybe a fd leak in indexslicequeries

2011-04-02 Thread Roland Gude
Hi, The open file limit is 1024 Sstable count is somewhere around 20 or so thread count is in the same order of magnitude I guess But lsof shows that deleted sstables still have open file handles. This seems to be the issue as this number keeps growing. Any ideas? Roland. -Ursprüngliche N

Re: Bizarre side-effect of increasing read concurrency

2011-04-02 Thread Peter Schuller
> Previously, mark-and-sweep would run around 5.5GB, and would cut heap > usage to 4GB. Now, it still runs at 5.5GB, but it shrinks all the way > down to 2GB used. This behavior was consistent in every machine I > increased read-concurrent on. So each full CMS cycles brings it down to 4 on a maxim

Re: Bizarre side-effect of increasing read concurrency

2011-04-02 Thread Peter Schuller
> Java also enjoys using all the memory your allocate and the Garbage > collection does not give it back unless it needs to. This only explains why it never shrinks in top, not increased heap usage (which is presumably the memtables/key/row caches already mentioned). -- / Peter Schuller