Absolutely right. (So, it's really a write-time slowdown, not read-time.)
Created https://issues.apache.org/jira/browse/CASSANDRA-2218 for the fix.
Thanks a lot for tracking that down!
2011/2/22 Ivan Georgiev yngw...@bk.ru:
Hi, yes, you are absolutely right, i overlooked that.
I am sending
I did some very rough measurements in a desperate attempt to see if I
can find the issue (if there is an issue).
Since I dont know the code base well enough i chose
BufferedRandomAccessFile as my suspect, since it was rewritten from
0.7.0 to 0.7.1
I did rough measurements on how many times
Some more digging. This is the code path causing the excessive
rebuffer() calls.
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Unknown Source)
at
org.apache.cassandra.io.util.BufferedRandomAccessFile.reBuffer(BufferedRandomAccessFile.java:204)
at
BRAF.seek has not changed since 0.7.0. Here is the implementation:
public void seek(long newPosition) throws IOException
{
current = newPosition;
if (newPosition = bufferEnd || newPosition bufferOffset)
{
reBuffer(); // this will set bufferEnd for us
That is strange. In 0.7.0 i see this for seek:
public void seek(long pos) throws IOException
{
this.curr_ = pos;
}
Ivan
On 21.2.2011 г. 21:20 ч., Jonathan Ellis wrote:
BRAF.seek has not changed since 0.7.0. Here is the implementation:
public void seek(long newPosition) throws
2011/2/21 Ivan Georgiev yngw...@bk.ru
That is strange. In 0.7.0 i see this for seek:
public void seek(long pos) throws IOException
{
this.curr_ = pos;
}
You doesn't see 0.7.0 version, you see version before
cassandra/branches/cassandra-0.7@1052531 (2010-12-24 16:57:07 + (8 weeks
ago))
And it's not like it didn't have to rebuffer then, just that the code
organization was different.
On Mon, Feb 21, 2011 at 2:12 PM, ruslan usifov ruslan.usi...@gmail.com wrote:
2011/2/21 Ivan Georgiev yngw...@bk.ru
That is strange. In 0.7.0 i see this for seek:
public void seek(long pos)
I meant what was tagged as 0.7.0, at least that is what i used in my
0.7.0 tests:
http://svn.apache.org/repos/asf/cassandra/tags/cassandra-0.7.0/
Ivan
On 21.2.2011 ?. 22:12 ?., ruslan usifov wrote:
2011/2/21 Ivan Georgiev yngw...@bk.ru mailto:yngw...@bk.ru
That is strange. In 0.7.0 i
If you look in that code, the bounds are checked on each write and
reBuffer is called from there instead of from seek
On Mon, Feb 21, 2011 at 2:21 PM, Ivan Georgiev yngw...@bk.ru wrote:
I meant what was tagged as 0.7.0, at least that is what i used in my 0.7.0
tests:
Hi,
I am testing 0.7.2 on a Windows 2003 x64 system(one node) and I am
having the following problem.
My insertion speed is relatively slow, so the memtables do not get full
and the actual flushing is triggered by memtable_flush_after_mins, this
happens on the hour mark. My problem with 0.7.2
Flush code didn't change between 0.7.0 and 0.7.2. There must be some
other variable here. Memory pressure maybe?
On Sat, Feb 19, 2011 at 8:16 AM, Ivan Georgiev yngw...@bk.ru wrote:
Hi,
I am testing 0.7.2 on a Windows 2003 x64 system(one node) and I am having
the following problem.
My
On 19.2.2011 г. 16:43 ч., Jonathan Ellis wrote:
Flush code didn't change between 0.7.0 and 0.7.2. There must be some
other variable here. Memory pressure maybe?
Cloud you please elaborate on that one ?
The conditions are exactly the same for the test with 0.7.0 and 0.7.2.
By the way, 0.7.1
Are you running with JNA enabled? If so could you try disabling it?
On Sat, Feb 19, 2011 at 11:32 AM, Ivan Georgiev yngw...@bk.ru wrote:
On 19.2.2011 г. 16:43 ч., Jonathan Ellis wrote:
Flush code didn't change between 0.7.0 and 0.7.2. There must be some
other variable here. Memory pressure
JNA is disabled and it is a windows box.
Ivan
On 19.2.2011 г. 19:23 ч., Jake Luciani wrote:
Are you running with JNA enabled? If so could you try disabling it?
On Sat, Feb 19, 2011 at 11:32 AM, Ivan Georgiev yngw...@bk.ru
mailto:yngw...@bk.ru wrote:
On 19.2.2011 г. 16:43 ч., Jonathan
I guess you'll need to binary search through the 0.7.1 changes to find
what made the difference. I can't think of any obvious candidates.
On Sat, Feb 19, 2011 at 10:32 AM, Ivan Georgiev yngw...@bk.ru wrote:
On 19.2.2011 г. 16:43 ч., Jonathan Ellis wrote:
Flush code didn't change between 0.7.0
Is it possible that the changes to the BufferedRandomAccessFile.java
could be causing the issue ?
I think the most notable change there is using ByteBuffer instead of a
byte[] for the buffer.
I will run more tests and see what comes out of it.
Ivan
On 20.2.2011 г. 05:03 ч., Jonathan Ellis
16 matches
Mail list logo
