unsubscribe
unsubscribe
che_provider = 'SerializingCacheProvider'
and compaction_strategy =
'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
and compression_options = {'chunk_length_kb' : '64',
'sstable_compression' :
'org.apache.cassandra.io.compress.SnappyCompressor'};
best regards,
Zhu Han
On Mon, May 14, 2012 at 10:34 AM, zhangcheng wrote:
> thanks, Edward.
>
> In my test, when I changed to leveled strategy, the compaction can't
> finish for the reason that we have 700G new data every day!
>
> what can I do if I want to save the comapction space?
>
>
>
For so big dataset, you may
On Mon, May 14, 2012 at 10:34 AM, zhangcheng wrote:
> thanks, Edward.
>
> In my test, when I changed to leveled strategy, the compaction can't
> finish for the reason that we have 700G new data every day!
>
> what can I do if I want to save the comapction space?
>
For so big dataset, you may tri
On Sat, Mar 24, 2012 at 7:55 AM, Peter Schuller wrote:
> > No I don't think you did, in fact, depending on the size of your SSTable
> a
> > contiguous range (or the entire SSTable) may or may not be affected by a
> > cleanup/move or any type of topology change. There is lots of room for
> > optim
On Fri, Mar 23, 2012 at 6:54 AM, Peter Schuller wrote:
> > You would have to iterate through all sstables on the system to repair
> one
> > vnode, yes: but building the tree for just one range of the data means
> that
> > huge portions of the sstables files can be skipped. It should scale down
>
On Thu, Mar 22, 2012 at 6:20 PM, Richard Low wrote:
> On 22 March 2012 05:48, Zhu Han wrote:
>
> > I second it.
> >
> > Is there some goals we missed which can not be achieved by assigning
> > multiple tokens to a single node?
>
> This is exactly the propose
On Tue, Mar 20, 2012 at 11:24 PM, Jeremiah Jordan <
jeremiah.jor...@morningstar.com> wrote:
> So taking a step back, if we want "vnodes" why can't we just give every
> node 100 tokens instead of only one? Seems to me this would have less
> impact on the rest of the code. It would just look like
On Sat, Mar 17, 2012 at 7:38 AM, Sam Overton wrote:
> Hello cassandra-dev,
>
> This is a long email. It concerns a significant change to Cassandra, so
> deserves a thorough introduction.
>
> *The summary is*: we believe virtual nodes are the way forward. We would
> like to add virtual nodes to Ca
On Wed, Nov 16, 2011 at 3:03 PM, Norman Maurer wrote:
> 2011/11/16 Jonathan Ellis :
> > I started a "users survey" thread over on the users list (replies are
> > still trickling in), but as useful as that is, I'd like to get
> > feedback that is more quantitative and with a broader base. This wi
Thank you all for this work.
Is there any plan for Cassandra-1546[1]? Will it be merged as an
alternative? Or the current patch embraces 1546?
[1] https://issues.apache.org/jira/browse/CASSANDRA-1546
best regards,
hanzhu
On Wed, Dec 22, 2010 at 10:12 AM, Jonathan Ellis wrote:
> Thanks to Ke
Can anybody recommend a stable enough JDK environment for 0.6.x branch on
ubuntu server?
Thank you!
best regards,
hanzhu
On Sun, Dec 19, 2010 at 10:29 AM, Zhu Han wrote:
> The problem seems still like the C-heap of JVM, which leaks 70MB every day.
> Here is the summary:
>
&
Here is a typo, sorry...
best regards,
hanzhu
On Sun, Dec 19, 2010 at 10:29 AM, Zhu Han wrote:
> The problem seems still like the C-heap of JVM, which leaks 70MB every day.
> Here is the summary:
>
> on 12/19: 010c3000 178548K rw---[ anon ]
> on 12/18: 010c
ble:0 kB
Bounce: 0 kB
CommitLimit: 0 kB
Committed_AS:0 kB
VmallocTotal:0 kB
VmallocUsed: 0 kB
VmallocChunk:0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
Hugepagesize: 2048 kB
> thanks,
> Sri
>
> On Fr
?
best regards,
hanzhu
On Thu, Dec 16, 2010 at 9:28 PM, Zhu Han wrote:
> I've tried it. But it does not work for me this afternoon.
>
> Thank you!
>
> best regards,
> hanzhu
>
>
>
> On Thu, Dec 16, 2010 at 8:59 PM, Matthew Conway wrote:
>
>> Thanks fo
over ssh:
> http://simplygenius.com/2010/08/jconsole-via-socks-ssh-tunnel.html
>
> Matt
>
>
> On Dec 16, 2010, at Thu Dec 16, 2:39 AM, Zhu Han wrote:
>
> > Sorry for spam again. :-)
> >
> > I think I find the root cause. Here is a bug report[1] on memory leak of
&
/bugdatabase/view_bug.do?bug_id=6824570
[2] http://blog.fuseyism.com/index.php/2010/09/10/icedtea6-19-released/
best regards,
hanzhu
On Thu, Dec 16, 2010 at 3:10 PM, Zhu Han wrote:
> The test node is behind a firewall. So I took some time to find a way to
> get JMX diagnostic informatio
estart the instance.
best regards,
hanzhu
On Thu, Dec 16, 2010 at 1:00 PM, Zhu Han wrote:
> After investigating it deeper, I suspect it's native memory leak of JVM.
> The large anonymous map on lower address space should be the native heap of
> JVM, but not java object heap. H
2010 at 10:50 AM, Zhu Han wrote:
> Hi,
>
> I have a test node with apache-cassandra-0.6.8 on ubuntu 10.4. The
> hardware environment is an OpenVZ container. JVM settings is
> # java -Xmx128m -version
> java version "1.6.0_18"
> OpenJDK Runtime Environment (IcedTea6
Is the link to CHANGES.txt broken?
best regards,
hanzhu
On Fri, Nov 5, 2010 at 2:39 AM, Eric Evans wrote:
>
> The list of changes[1] since 0.6.6 is fairly small, but there's been
> some interest in getting CASSANDRA-1656[2] (a HH bug) out to people. I
> propose the following for release as 0.
> They have however at least one advantage:
> - your super columns are indexed, you don't have to deserialize them
>entirely each time.
>
The size of counter super column is limited to how many replicas propagated
values as the lead replica. It's size is upper bounded by the number of
repli
data to the value field. it's no
> longer simply a matter of reversing 1070.
>
> On Sat, Sep 25, 2010 at 11:50 PM, Zhu Han wrote:
> > Jonathan,
> >
> > This is a personnel email.
> >
> > On Sun, Sep 26, 2010 at 1:27 PM, Jonathan Ellis
> wrote:
>
>
>
> On the other hand, if the patch authors never bring it up to the
> standards of the rest of the project, well, then it's a good thing we
> didn't commit it under a "commit now, fix later" process.
>
> > Maybe this fork could be prevented if committers could give the guidance?
>
> While it's t
> Reasons to not use the row cache with large rows include:
>
> * In general it's a waste of memory better given to the OS page cache,
> unless possibly you're continually reading entire rows rather than
> subsets of rows.
>
> * For truly large rows you may have immediate issues with the size of
>
tion strategy... Only
the nearest node should receive the requests.
BTW, which version of cassandra was the randomly repair feature firstly
implemented? 0.7 beta?
> On Sat, Sep 18, 2010 at 9:39 AM, Zhu Han wrote:
> > Hi,
> >
> > I notice below code snippet in StorageProxy#
Hi,
I notice below code snippet in StorageProxy#strongRead(). Why the read
repair is still trigged randomly if digest is mis-matched for CL.Quorum
and CL.ALL. IMHO, the client wants the result to be returned is the
consistent one on those two CL. Read repair should be triggered
definitively her
did in my project.
best regards,
hanzhu
On Sun, Sep 5, 2010 at 5:24 PM, Zhu Han wrote:
> + 1 for Jonathan Ellis.
>
> I might not be on the same page as you active community members. But I'm
> wondering why not put this feature to a popular client library or as a
> contrib pa
+ 1 for Jonathan Ellis.
I might not be on the same page as you active community members. But I'm
wondering why not put this feature to a popular client library or as a
contrib package?
In CASSANDRA-1072 + CASSANDRA-1397, the increment of counter is not
idempotent, so it's difficult to align with
Good catch! it's the major drawback of JE that it is lack of on disk
locality, if the internal node cannot put in RAM. BDB can provide such on
disk locality. Seems like BDB JE can be an alternative of memtable + tablet
log, BDB can be an alternative of SSTable.
This is just general discussion.
Log structural database has the append-only characteristics, e.g. BDB-JE.
Is it an alternative for SSTable? Those matured database product might have
done a lot for cache management. Not sure whether it can improve the
performance of read or not.
Support of compression on those product is another
31 matches
Mail list logo
