Looks like problem in code:
public IndexSummary(long expectedKeys)
{
long expectedEntries = expectedKeys /
DatabaseDescriptor.getIndexInterval();
if (expectedEntries > Integer.MAX_VALUE)
// TODO: that's a _lot_ of keys, or a very low interval
throw n
I've been using flashcache for a while in production. It improves read
performance and latency was halved by a good chunk, though I don't
remember the exact numbers.
Problems: compactions will trash your cache, and so will memtable
flushes. Right now there's no way to avoid that.
If you want, I
Can't think of any.
On Sun, Jul 17, 2011 at 1:27 PM, Andrey Stepachev wrote:
> Looks like problem in code:
> public IndexSummary(long expectedKeys)
> {
> long expectedEntries = expectedKeys /
> DatabaseDescriptor.getIndexInterval();
> if (expectedEntries > Integer.MAX_VALU
You are probably seeing this http://wiki.apache.org/cassandra/FAQ#range_rp
Row keys are not ordered by their key, they are ordered by the token created by
the partitioner.
If you still think there is a problem provide an example of the data your are
seeing and what you expected to see.
Cheers
What RF are you using ?
On disk each column has 15 bytes of overhead, plus the column name and the
column value. So for an 8 byte long and a 8 byte double there will be 16 bytes
of data and 15 bytes of data.
The index file also contains the the row key, the MD5 token (for RP) and the
row off
On 7/17/2011 12:29 PM, Héctor Izquierdo Seliva wrote:
I've been using flashcache for a while in production. It improves read
performance and latency was halved by a good chunk, though I don't
remember the exact numbers.
Problems: compactions will trash your cache, and so will memtable
flushes. R
> Currently the only way for that would be iterating through the list of column
> families returned by the getCf_defs() method.
Yes.
BTW most people access cassandra via a higher level client, for the Java peeps
tend to use either Hector or Pelops. Aside from not having to code against
thrif
I have tested another case, not sure if this is a bug.
I created a few column families on 0.8.0 each has user_name column, in
addition, I also enabled secondary index on this column. Then, I upgraded
to 0.8.1, when I used cassandra-cli: show keyspaces, I saw index name
"user_name_idx" appears for
Dear all,
I use JMX to monitor Cassandra server.
Heap Memory Usage show:
Used : 600MB, Commit 2.1G, Max: 2.1G
But htop show Cassandra process consume 3.1G.
Could you tell me why Cassandra occupy memory very large than in used?
Thank a lot for support.
--
Best regards,
JKnight
http://wiki.apache.org/cassandra/FAQ#mmap
On Sun, Jul 17, 2011 at 11:54 PM, JKnight JKnight wrote:
> Dear all,
> I use JMX to monitor Cassandra server.
> Heap Memory Usage show:
> Used : 600MB, Commit 2.1G, Max: 2.1G
> But htop show Cassandra process consume 3.1G.
> Could you tell me why Cassandr
0.8.0 didn't check for name conflicts correctly. 0.8.1 does, but it
can't fix the ones 0.8.0 allowed, retroactively.
On Sun, Jul 17, 2011 at 11:52 PM, Boris Yen wrote:
> I have tested another case, not sure if this is a bug.
> I created a few column families on 0.8.0 each has user_name column, i
Will this have any side effect when doing a get_indexed_slices or when a
user wants to drop an index by any means?
Boris
On Mon, Jul 18, 2011 at 1:13 PM, Jonathan Ellis wrote:
> 0.8.0 didn't check for name conflicts correctly. 0.8.1 does, but it
> can't fix the ones 0.8.0 allowed, retroactivel
Aaron, thanks for the reply.
I think what I encounter is exactly this problem!
I'll try the suggestions, or switch away from the random partitioner.
Cordially,
Matthieu Nahoum
On Sun, Jul 17, 2011 at 5:50 PM, aaron morton wrote:
> You are probably seeing this http://wiki.apache.org/cassandra/
Thank for your response.
Do you talk about virtual memory (column VIRT show in top command)?
But I mention about column RES. In my case, VIRT is 61.8G, RES is 3.2G and
SHR is 1.2G.
JMX show Memory Usage:
Used : 600MB, Commit 2.1G, Max: 2.1G
On Mon, Jul 18, 2011 at 11:59 AM, Jonathan Ellis wrote:
14 matches
Mail list logo
