Re: 0.7.2 slow memtables flushing

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 : > Hi, yes, you are absolutely right, i overlooked that. > I am sending directly as i

Re: 0.7.2 slow memtables flushing

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 wrote: > 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/cas

Re: 0.7.2 slow memtables flushing

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 mailto:yngw...@bk.ru>> That is strange. In 0.7.0 i see this for

Re: 0.7.2 slow memtables flushing

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 wrote: > > > 2011/2/21 Ivan Georgiev >> >> That is strange. In 0.7.0 i see this for seek: >> >> public void seek(long pos) throws IOException >> { >> t

Re: 0.7.2 slow memtables flushing

2011/2/21 Ivan Georgiev > 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))

Re: 0.7.2 slow memtables flushing

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 IOExceptio

Re: 0.7.2 slow memtables flushing

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 u

Re: 0.7.2 slow memtables flushing

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 org.apache.cassand

Re: 0.7.2 slow memtables flushing

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 wri

Re: 0.7.2 slow memtables flushing

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 wro

Re: 0.7.2 slow memtables flushing

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 wrote: > On 19.2.2011 г. 16:43 ч., Jonathan Ellis wrote: >> >> Flush code didn't change between 0.7.0 and 0.7.

Re: 0.7.2 slow memtables flushing

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 > wrote: On 19.2.2011 г. 16:43 ч., Jonathan Ellis wrote:

Re: 0.7.2 slow memtables flushing

Are you running with JNA enabled? If so could you try disabling it? On Sat, Feb 19, 2011 at 11:32 AM, Ivan Georgiev 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 maybe? >>

Re: 0.7.2 slow memtables flushing

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 test

Re: 0.7.2 slow memtables flushing

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 wrote: > 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

0.7.2 slow memtables flushing

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 i