On Tue, Mar 9, 2010 at 7:15 AM, Sylvain Lebresne <sylv...@yakaz.com> wrote:
>  1) stress.py -t 10 -o read -n 50000000 -c 1 -r
>  2) stress.py -t 10 -o read -n 500000 -c 1 -r
> In the case 1) I get around 200 reads/seconds and that's pretty stable. The
> disk is spinning like crazy (~25% io_wait), very few cpu or memory used,
> performances are IO bound, which is expected.
> In the case 2) however, it starts with reasonnable performance (400+
> reads/seconds), but it very quickly drop to an average of 80 reads/seconds

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.

> 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.

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

Are you using a 64-bit JVM?


Reply via email to