On Fri, 23 Feb 2001, Hannu Krosing wrote:
HK> > DM> I just done the experiment with increasing HZ to 1000 on my own machine
HK> > DM> (PII 374). Your test program reports 2 ms instead of 20. The other side
HK> > DM> of increasing HZ is surely more overhead to scheduler system. Anyway, it's
HK> >
> Okay, plan B then: let's ask people to redo their benchmarks with
> -s bigger than one. Now, how much bigger?
>
> To the extent that you think this is a model of a real bank, it should
> be obvious that the number of concurrent transactions cannot exceed the
> number of tellers; there should n
> -Original Message-
> From: Tom Lane
>
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Is this unmodified pgbench or has it Hiroshi tweaked behaviour of
> > connecting each client to its own database, so that locking and such
> > does not shade the possible benefits (was it about 15% ?)
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
>> It seems to me that the branches table should have at least 10 to 100
>> entries, and tellers about 10 times whatever branches is. 10
>> accounts rows seems enough though.
> Those numbers are defined in the TPC-B spec.
Ah. And of course, the TPC
> I didn't much like that approach to altering the test, since it also
> means that all the clients are working with separate tables and hence
> not able to share read I/O; that doesn't seem like it's the same
> benchmark at all. What would make more sense to me is to increase the
> number of row
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Is this unmodified pgbench or has it Hiroshi tweaked behaviour of
> connecting each client to its own database, so that locking and such
> does not shade the possible benefits (was it about 15% ?) of delay>1
I didn't much like that approach to alterin
On Fri, Feb 23, 2001 at 01:09:37PM +0200, Hannu Krosing wrote:
> Dmitry Morozovsky wrote:
>
> > DM> I just done the experiment with increasing HZ to 1000 on my own machine
> > DM> (PII 374). Your test program reports 2 ms instead of 20. The other side
> > DM> of increasing HZ is surely more overh
Lincoln Yeoh wrote:
>
> Oops.
>
> I rechecked the start up script, and the 7.0.3 doesn't have fsync off or
> whatever. Dunno why I thought it was on (heh maybe because it was a lot
> faster than 6.5.3!).
>
> Hmm, this means 7.0.3 is quite fast...
>
Your app seems to have many rollbacks.
Yes ro
I wrote:
>
> I tried with -B 1024 10 times for commit_delay=0 and 1 respectively.
> The average result of 'pgbench -c 10 -t 100' is as follows.
>
> [commit_delay=0]
> 26.462817(including connections establishing)
> 26.788047(excluding connections establishing)
> [commit_delay=1]
> 27.630405(in
> Tom Lane wrote:
> >
> > > platform) i686-pc-linux-gnu, compiled by GCC
> egcs-2.91.60(turbolinux 4.2)
> > > min delay) 10msec according to your test program.
> > > -B) 64 (all other settings are default)
> >
> > Thanks. Could I trouble you to run it again with a larger -B, say
> > 1024 or 20
I Inoue wrote:
>
> Tom Lane wrote:
> >
> > > platform) i686-pc-linux-gnu, compiled by GCC egcs-2.91.60(turbolinux 4.2)
> > > min delay) 10msec according to your test program.
> > > -B) 64 (all other settings are default)
> >
> > Thanks. Could I trouble you to run it again with a larger -B, say
>
Tom Lane wrote:
>
> > platform) i686-pc-linux-gnu, compiled by GCC egcs-2.91.60(turbolinux 4.2)
> > min delay) 10msec according to your test program.
> > -B) 64 (all other settings are default)
>
> Thanks. Could I trouble you to run it again with a larger -B, say
> 1024 or 2048? What I've foun
Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> >> Hmm, you mean you set up a separate test database for each pgbench
> >> "client", but all under the same postmaster?
>
> > Yes. Different database is to make the conflict as less as possible.
> > The conflict among backends is a
"Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
>> Hmm, you mean you set up a separate test database for each pgbench
>> "client", but all under the same postmaster?
> Yes. Different database is to make the conflict as less as possible.
> The conflict among backends is a greatest enemy of CommitDelay
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I changed pgbench so that different connection connects
> > to the different database and got the following results.
>
> Hmm, you mean you set up a separate test database for
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I changed pgbench so that different connection connects
> to the different database and got the following results.
Hmm, you mean you set up a separate test database for each pgbench
"client", but all under the same postmaster?
> The results of
> p
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I've been suspicious if pgbench is an (unique)
> > appropiriate test case for evaluaing commit_delay.
>
> Of course it isn't. Never trust only one benchmark.
>
> I've asked the Great Bridge folks to run their TPC-C benchmark with
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I've been suspicious if pgbench is an (unique)
> appropiriate test case for evaluaing commit_delay.
Of course it isn't. Never trust only one benchmark.
I've asked the Great Bridge folks to run their TPC-C benchmark with both
zero and small nonzero com
Tom Lane wrote:
>
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > In your test cases I always see "where bid = 1" at "update branches"
> > i.e.
> > update branches set bbalance = bbalance + ... where bid = 1
>
> > ISTM there's no multiple COMMIT in your senario-s due to
> > their lock conflicts
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> In your test cases I always see "where bid = 1" at "update branches"
> i.e.
> update branches set bbalance = bbalance + ... where bid = 1
> ISTM there's no multiple COMMIT in your senario-s due to
> their lock conflicts.
Hmm. It looks like using a
I did not realize how much WAL improved performance when using fsync.
> > "Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> > > So, is it OK to use commit_delay=0?
> >
> > Certainly. In fact, I think that's about to become the default ;-)
>
> I agree with Tom. I did some benchmarking tests using
Tom Lane wrote:
>
> I wrote:
> > Thus, our past arguments about whether a few microseconds of delay
> > before commit are a good idea seem moot; we do not have any portable way
> > of implementing that, and a ten millisecond delay for commit is clearly
> > Not Good.
>
> I've now finished running
* Tom Lane <[EMAIL PROTECTED]> [010216 22:49]:
> "Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> > So, is it OK to use commit_delay=0?
>
> Certainly. In fact, I think that's about to become the default ;-)
>
> I have now experimented with several different platforms --- HPUX,
> FreeBSD, and two
lockhart> > ... See included png file.
lockhart>
lockhart> What kind of machine was this run on?
lockhart>
lockhart> - Thomas
Sorry to forget to mention about that.
SONY VAIO Z505CR/K (note PC)
Pentium III 750MHz/256MB memory/20GB IDE HDD
Linux (kernel 2.2.17)
configure --
> ... See included png file.
What kind of machine was this run on?
- Thomas
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> I agree with Tom. I did some benchmarking tests using pgbench for a
> computer magazine in Japan. I got a almost equal or better result for
> 7.1 than 7.0.3 if commit_delay=0. See included png file.
Interesting curves. One thing you might like to know i
> "Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> > So, is it OK to use commit_delay=0?
>
> Certainly. In fact, I think that's about to become the default ;-)
I agree with Tom. I did some benchmarking tests using pgbench for a
computer magazine in Japan. I got a almost equal or better result for
"Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> So, is it OK to use commit_delay=0?
Certainly. In fact, I think that's about to become the default ;-)
I have now experimented with several different platforms --- HPUX,
FreeBSD, and two considerably different strains of Linux --- and I find
that t
28 matches
Mail list logo
