Levelled Compaction is a wholly different beast when it comes to tombstones.
The tombstones are inserted, like any other write really, at the lower levels
in the leveldb hierarchy.
They are only removed after they have had the chance to "naturally" migrate
upwards in the leveldb hierarchy to t
There was mention of a similar crash on the mailing list. Does this apply to
your case ?
http://mail-archives.apache.org/mod_mbox/cassandra-user/201306.mbox/%3ccdecfcfa.11e95%25agundabatt...@threatmetrix.com%3E
--
Mina Naguib
AdGear Technologies Inc.
http://adgear.com/
On 2013-09-10, at 10
On 2013-08-27, at 6:04 AM, Aklin_81 wrote:
> For any website just starting out, the load initially is minimal & grows with
> a slow pace initially. People usually start with their MySQL based sites
> with a single server(***that too a VPS not a dedicated server) running as
> both app server
Hi Apostolis
I'm the author of libcassie, a C library for cassandra that wraps the C++
libcassandra library.
It's in use in production where I work, however it has not received much
traction elsewhere as far as I know. You can get it here:
https://github.com/minaguib/libcassandra/tree/kicks
On 2013-01-22, at 8:59 AM, Brian Tarbox wrote:
> The output of this command seems to make no sense unless I think of it as 5
> completely separate histograms that just happen to be displayed together.
>
> Using this example output should I read it as: my reads all took either 1 or
> 2 sstabl
On 2012-11-24, at 10:37 AM, Chuan-Heng Hsiao wrote:
> However, I continue seeing the following in /var/log/cassandra/system.log
>
> INFO [HintedHandoff:1] 2012-11-24 22:58:28,088
> HintedHandOffManager.java (line 296) Started hinted handoff for token:
> 27949589543905115548813332729343195104 w
On 2012-11-08, at 1:12 PM, B. Todd Burruss wrote:
> we are having the problem where we have huge SSTABLEs with tombstoned data in
> them that is not being compacted soon enough (because size tiered compaction
> requires, by default, 4 like sized SSTABLEs). this is using more disk space
> th
andra itself can't measure (network, thrift,
etc), across various different client softwares that talk to it. Within
graphite we have several dashboards defined (users make their own, some
infrastructure components have shared dashboards.)
--
Mina Naguib :: Director, Infrastructure
Hi Thomas
On a modern 64bit server, I recommend you pay little attention to the virtual
size. It's made up of almost everything within the process's address space,
including on-disk files mmap()ed in for zero-copy access. It's not
unreasonable for a machine with N amount RAM to have a proces
Hi folks
Our cassandra (and other java-based apps) started experiencing extremely high
CPU usage as of 8pm eastern time (midnight UTC).
The issue appears to be related to specific versions of java + linux + ntpd
There are many solutions floating around on IRC, twitter, stackexchange, LKML.
Th
On 2012-06-14, at 10:38 AM, Henrik Schröder wrote:
> Hi everyone,
>
> We have problem with our Cassandra cluster, and that is that sometimes it
> takes several seconds to open a new Thrift connection to the server. We've
> had this issue when we ran on windows, and we have this issue now that
Hi Wade
I don't know if your scenario matches mine, but I've been struggling with
memory pressure in 1.x as well. I made the jump from 0.7.9 to 1.1.0, along
with enabling compression and levelled compactions, so I don't know which
specifically is the main culprit.
Specifically, all my nodes
Hi Vlad
I'm the author of libcassie.
For what it's worth, it's in production where I work, consuming a heavily-used
cassandra 0.7.9 cluster.
We do have plans to upgrade the cluster to 1.x, to benefit from all the
improvements, CQL, etc... but that includes revising all our clients (across
se
checking.
>
> If cleanup / repair / compaction is all good and you are confident the tokens
> are right try poking around with nodetool getendpoints to see which nodes
> keys are sent to. Like you I cannot see anything obvious in NTS that would
> cause load to be imbalanced if they
Hi everyone
I'm observing a very peculiar type of imbalance and I'd appreciate any help or
ideas to try. This is on cassandra 0.7.8.
The original cluster was 3 machines in the DCMTL, equally balanced at 33.33%
each and each holding roughly 34G.
Then, I added to it 3 machines in the LA data ce
Did you run that verbatim ? Or you appropriately substituted "keyspace" and
"columnfamily1" ?
Also, anything in cassandra's log file (system.log) ? Compacting 150Gb over
2057 SSTables should take a reasonable bit of time...
On 2011-07-31, at 11:47 PM, myreasoner wrote:
> Thanks.
>
> I did
From experience with similar-sized data sets, 1.5GB may be too little.
Recently I bumped our java HEAP limit from 3GB to 4GB to get past an OOM doing
a major compaction.
Check "nodetool -h localhost info" while the compaction is running for a simple
view into the memory state.
If you can, al
e if
> it is triggered by repair.
>
> p
>
> On 22/07/11 16:08, Mina Naguib wrote:
>>
>> I'm trying to balance Load ( 41.98GB vs 59.4GB vs 74.65GB )
>>
>> Owns looks ok. They're all 33.33% which is what I want. It was calculated
>> simply by
anced.
>
> how did you calculate your tokens?
>
>
> On Fri, Jul 22, 2011 at 4:37 PM, Mina Naguib
> wrote:
>>
>> Address Status State LoadOwnsToken
>> xx.xx.x.105 Up Normal 41.98 GB33.33%
Hi everyone
I've been struggling trying to get the data volume ("load") to equalize across
a balanced cluster, and I'm not sure what else I can try.
Background: This was originally a 5-node cluster. We re-balanced the 3 faster
machines across the ring, and decommissioned the 2 older ones. We
20 matches
Mail list logo
