Re: tpc.org benchmark statspack or any very high transaction system (>4000 tps) statspack report?

The first counter-argument to your colleague's suggestion is the "piggyback" commit.

Assume you can do a 2 m/s turnaround on a call to log writer, limiting a SINGLE SESSION to 500 transactions per second - I've picked 2 m/s because even with 4 Gigabit links to a SAN cache you won't often get a much faster turnaround than that in "real" systems.

You only need about 30 concurrent sessions to keep on issuing commits at about half this rate to hit the target you want. Assume about 15 commit at once, the log writer can respond by clearing all 15 calls at once; but while it's doing this, the other 15 commit - so that their synch calls have to wait for
the current write to complete. But after the log writer has acknowledged the batch of commits, it can handle the second batch seven simultaneously - during with the first 15 sessions generate more redo and commit .. and so on.

It's the sort of case where your statspack might say:

    time spent in log file parallel write 1,000 seconds     time spent in log file sync 45,000 seconds

then when you look at the average times, the writes average about 2 m/s, and the log file syncs about 3 m/s.

The numbers don't quite add up - but I hope you get the idea. Log file sync TOTALS often overstate the impact of waiting for log writes in highly concurrent system when viewed at the system level.

Regards

Jonathan Lewis
http://jonathanlewis.wordpress.com

Author: Cost Based Oracle: Fundamentals
http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html

The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html

• Original Message ----- From: "Zhu,Chao" <zhuchao_at_gmail.com> To: <oracle-l_at_freelists.org> Sent: Friday, May 16, 2008 12:57 AM Subject: tpc.org benchmark statspack or any very high transaction system (>4000 tps) statspack report?

> hi,
> Anyone has information about tpc.org tpc-c benchmark statspack?
> I am very interested in their statspack report, see whether with such
> kind of huge transaction (it is something like 72000 transaction per
> second). As one business transaction involves quite a few DMLs, actual DML
> is far more than that.
> One of my colleagu has a theory that with redo write response time of
> 0.5ms (redo sync time in statspack), you can go at most 3600 "user commit"
> with reasonable(say, less than 2ms for redo write) response time even your
> SAN still have enough IO capacity; I disagree but I don't have such data
> about detailed performance data.
> Anyone has information where I can get the statspack for tpc.org tpcc
> benchmark, or can share your statspack report with that part abstraction?
> (just system load profile part, and redo performance part)?
>
> --
> Regards
> Zhu Chao
> www.cnoug.org
>

--
http://www.freelists.org/webpage/oracle-l