Is this Cassandra 1.1.1?
How often do you observe this? How many columns are in the row? Can
you reproduce when querying by column name, or only when slicing the
row?
On Thu, Jun 28, 2012 at 7:24 AM, Jason Tang ares.t...@gmail.com wrote:
Hi
First I delete one column, then I delete one
On Wed, Jun 27, 2012 at 5:11 PM, Aaron Turner synfina...@gmail.com wrote:
Honestly, I think using the same terms as a RDBMS does
makes users think they're exactly the same thing and have the same
properties... which is close enough in some cases, but dangerous in
others.
The point is that
They were removed because in 1.1 caches are global and not per-cf:
http://www.datastax.com/dev/blog/caching-in-cassandra-1-1
On Fri, Jun 29, 2012 at 5:45 AM, Bill b...@dehora.net wrote:
Were
Key cache capacity:
Key cache size:
Key cache hit rate:
Row cache:
removed from cfstats in 1.1.0?
More generally, don't just throw your old config file at a new version
of Cassandra; start with the new version's config, then apply any
customizations that are still relevant.
On Fri, Jun 29, 2012 at 8:40 AM, Romain HARDOUIN
romain.hardo...@urssaf.fr wrote:
commitlog_rotation_threshold_in_mb
Pending compactions is just an estimate of how many compactions
does Cassandra think it will take to get to fully-compacted state;
there are no actual tasks enqueued anywhere.
You could enable debug logging on org.apache.cassandra.db.compaction,
and force a compaction with nodetool to see why no
Sounds like http://wiki.apache.org/cassandra/FAQ#ubuntu_ec2_hangs to me.
On Fri, Jun 29, 2012 at 1:45 AM, Olivier Mallassi omalla...@octo.com wrote:
Hi all
We have a 12 servers clusters (8 cores by machines..).
OS is Ubuntu 10.04.2.
On one of the machine (only one) and without any load (no
On Thu, Jun 28, 2012 at 1:39 PM, Joost van de Wijgerd
jwijg...@gmail.com wrote:
the currentThoughput is increased even before the data is merged into the
memtable so it is actually measuring the throughput afaik.
You're right. I've attached a patch to
Thank you for the mail. Same here, but I restarted the affected server
before I noticed your mail.
It affected both OpenJDK Java 6 (packaged with Ubuntu 10.04) and Oracle
Java 7 processes. Ubuntu 32 bit servers had no issues, only a 64 bit
machine.
Likely it is related to the leap second
Hi Jonathan,
Looks good, any chance of porting this fix to the 1.0 branch?
Kind regards
Joost
Sent from my iPhone
On 1 jul. 2012, at 09:25, Jonathan Ellis jbel...@gmail.com wrote:
On Thu, Jun 28, 2012 at 1:39 PM, Joost van de Wijgerd
jwijg...@gmail.com wrote:
the currentThoughput is
More information for others that were affected.
Our installation of java:
[root@inv4 conf]# java -version
java version 1.6.0_30
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
[root@inv4 conf]# uname -a
Linux inv4
I'm running Cassandra on Raspberry Pi (for educational reason) and have been
successfully running 1.1.0 for some time. However there is no native build of
SnappyCompressor for the platform (I'm currently working n rectifying that if I
can) so that compression is unavailable. When I try and
Could someone please tell me where I should start looking at code to
understand how cassandra bootstrap process works? I am sure it is
complicated but I have time. Also is my understanding correct that the
new nodes that are added are not joining the ring till the bootstrap
process is complete i.e
For the create/update/deleteColumn/deleteRow test case, for Quorum
consistency level, 6 nodes, replicate factor 3, for one thread around 1/100
round, I can have this reproduced.
And if I have 20 client threads to run the test client, the ratio is bigger.
And the test group will be executed by
I have a three node cluster running 1.0.2, today there's a very strange
problem that suddenly two of cassandra node(let's say B and C) was costing
a lot of cpu, turned out for some reason the java binary just dont
run I am using OpenJDK1.6.0_18, so I switched to sun jdk, which works
okay.
adjust the timezone of java by -Duser.timezone and the timezone of
cassandra is the same with system(Debian 6.0).
after restart cassandra I found the following error message in the log file
of node B. after about 2 minutes later, node C stop responding
the error log of node B:
Thrift
This looks like the problem a bunch of us were having yesterday that
isn't cleared without a reboot or a date command. It seems to be
related to the leap second that was added between the 30th June and
the 1st of July.
See the mailing list thread with subject High CPU usage as of 8pm eastern time
huge great thanks it is the leap second problem!
finally I can go to bed
On Mon, Jul 2, 2012 at 12:11 AM, David Daeschler
david.daesch...@gmail.comwrote:
This looks like the problem a bunch of us were having yesterday that
isn't cleared without a reboot or a date command. It seems to
Hello
We was under ddos attack, and as result we got high ksoftirqd activity
- as result cassandra begin answer very slow. But when ddos was gone
high ksoftirqd activity still exists, and dissaper when i stop
cassandra daemon, and repeat again when i start cassadra daemon, the
fully resolution of
Hello,
it is not related to cassandra/ddos.
it is kernel problems due to leap second. See
http://serverfault.com/questions/403732/anyone-else-experiencing-high-rates-of-linux-server-crashes-during-a-leap-second
On Sun, Jul 1, 2012 at 1:05 PM, ruslan usifov ruslan.usi...@gmail.com wrote:
Hello
Good afternoon,
This again looks like it could be the leap second issue:
This looks like the problem a bunch of us were having yesterday that
isn't cleared without a reboot or a date command. It seems to be
related to the leap second that was added between the 30th June and
the 1st of July.
See
If you are reading at QUOURM there is no problem, this is how eventual
consistency works in Cassandra.
The coordinator will resolve the differences between and the column with the
higher timestamp will win.
If the delete was applied to less then CL nodes the client should have received
a
Like the exception says:
Bad Request: No indexed columns present in by-columns clause with equals
operator
Same with other relational operators(,=,=)
You must include an equality operator in the where clause:
That is why
SELECT * FROM STEST WHERE VALUE1 = 10;
Works but
SELECT * FROM
When the data is streamed into the cluster by the bulk loader it is compressed
on the receiving end (if the target CF has compression enabled).
If you are able to reproduce this can you create a ticket on
https://issues.apache.org/jira/browse/CASSANDRA ?
Cheers
-
Aaron
Can compression be changed or disabled on-the-fly with cassandra?
Yes. Disable it in the schema and then run nodetool upgradetables
As Tyler said, JDK7 is not officially supported yet and you may be running into
issues others have not found. Any chance you could downgrade one node to JDK6
and
Using Cassandra as a queue is generally thought of as a bas idea, owing to the
high delete workload. Levelled compaction handles it better but it is still no
the best approach.
Depending on your needs consider running http://incubator.apache.org/kafka/
could you share some details on this?
Sure, before I create a ticket, is there a way I can confirm that the
sstables are indeed not compressed other than running the rebuildsstables
nodetool command (and observing the live size go down)?
Thanks.
--
View this message in context:
2012/7/1 David Daeschler david.daesch...@gmail.com:
Good afternoon,
This again looks like it could be the leap second issue:
This looks like the problem a bunch of us were having yesterday that
isn't cleared without a reboot or a date command. It seems to be
related to the leap second that
Hey Aaron,
I am able to sort out the problem. Thanks anyways.
Regards,
Abhijit
28 matches
Mail list logo
