On Tue, Mar 9, 2010 at 2:52 PM, Jonathan Ellis <jbel...@gmail.com> wrote:
> By "reads" do you mean what stress.py counts (rows) or rows * columns?
>  If it is rows, then you are still actually reading more columns/s in
> case 2.

Well, unless I'm mistaking, that's the same in my example as I give in
both case
to stress.py the option '-c 1' which tells it to retrieve only one
column each time
even in the case where I have 100 columns by row.

>> And it don't go up significantly after
>> that. Turns out this seems to be a GC problem. Indeed, the info log (I'm
>> running trunk from today, but I first saw the problem on an older version of
>> trunk) show every few seconds lines like:
>>  GC for ConcurrentMarkSweep: 4599 ms, 57247304 reclaimed leaving
>> 1033481216 used; max is 1211498496
> First, use the 0.6 branch, not trunk.  we're breaking stuff over there.

Fair enough, I will do the test with 0.6. But again, I saw such
behavior with a trunk
from like 3 weeks ago. Just to say that I don't believe it to be
something broke
recently. But I admit, I should have tried with 0.6 and I will do it.

> What happens if you give the jvm 50% more ram?

A quick test doesn't show the problem with 50% more ram, at least not in a
short time frame. But I'm still not convinced there is no problem, I saw pretty
weird performance with bigger columns. Let me try to come up with a more
compelling test against 0.6. I'll keep you posted, even if I'm wrong :)

> Are you using a 64-bit JVM?



Reply via email to