Re: CommitDelay performance improvement

Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> At 00:42 25/02/01 -0800, Nathan Myers wrote:
>> The only really bad performers were (0), (10k,1), (100k,20). The best
>> were (30k,1) and (30k,10), although (30k,5) also did well except at 40.
>> Why would 30k be a magic delay, regardless of siblings? What happened
>> at 40?

> I had assumed that 40 was one of the glitches - it would be good if Tom (or
> someone else) could rerun the suite, to see if we see the same dip.

Yes, I assumed the same. I posted the script; could someone else make
the same run? We really need more than one test case ;-)

> I agree that 30k looks like the magic delay, and probably 30/5 would be a
> good conservative choice. But now I think about the choice of number, I
> think it must vary with the speed of the machine and length of the
> transactions; at 20tps, each TX is completing in around 50ms.

Yes, I think so too. This machine is able to do about 40 pgbench tr/sec
single-client with fsync off, so the computational load is right about
25msec per transaction. That's presumably why 30msec looks like a good
delay number. What interested me was that there doesn't seem to be a
very sharp peak; anything from 10 to 100 msec yields fairly comparable
results. This is a good thing ... if there *were* a sharp peak at the
average xact length, tuning the delay parameter would be an impossible
task in real-world cases where the transactions aren't all alike.

On the data so far, I'm inclined to go with 10k/5 as the default, so as
not to risk wasting time with overly long delays on machines that are
faster than this one. But we really need some data from other machines
before deciding. It'd be nice to see some results with <10k delays too,
from a machine where the kernel supports better-than-10msec delay
resolution. Where's the Alpha contingent??

regards, tom lane