On Sat, 17 Feb 2001, Tom Lane wrote:
[skip]
TL> Platform: HPUX 10.20 on HPPA C180, fast wide SCSI discs, 7200rpm (I think).
TL> Minimum select(2) delay is 10 msec on this platform.
[skip]
TL> I vote for commit_delay = 0, unless someone can show cases where
TL> positive delay is significantly be
Title: RE: [ADMIN] v7.1b4 bad performance
With -B 256 -F I'm getting around 70 tps, and I haven't got wonderful hardware: dual 450Mhz PII, 40GB SCSI drive, 320MB RAM, RH Linux 7.0. I presume that these benchmarks are not adjusted statistically to compensate for hardware or anything
Title: RE: [ADMIN] v7.1b4 bad performance
I'm using a test
machine that is even less powerful than what you are using. However, what I'm
interested in is the comparison between 7.0x and 7.1x. Shouldn't the 7.1b4
database be faster? Have you (or anyone else) done this
compar
Title: RE: [ADMIN] v7.1b4 bad performance
How
closely matched are the parameters of your 7.0 and 7.1 servers? Particularly the
-B parameters. Anyway, I'm busy trying to get my server set up with
both version to run the tests. I'll get back to you...
-Original
Messag
"Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> However, what I'm interested in is the comparison between 7.0x and 7.1x.
> Shouldn't the 7.1b4 database be faster? Have you (or anyone else) done this
> comparison?
7.1 is considerably faster if you compare performance without -F.
If you are comparin
On Wed, 14 Feb 2001, Tom Lane wrote:
> "Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> > However, what I'm interested in is the comparison between 7.0x and 7.1x.
> > Shouldn't the 7.1b4 database be faster? Have you (or anyone else) done this
> > comparison?
>
> 7.1 is considerably faster if you
Title: RE: [ADMIN] v7.1b4 bad performance
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 14, 2001 8:02 AM
> To: Schmidt, Peter
> Cc: 'Michael Ansley'; '[EMAIL PROTECTED]'
> Subject: Re: [ADMIN] v7
> > "Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> > > However, what I'm interested in is the comparison between
> > 7.0x and 7.1x.
> > > Shouldn't the 7.1b4 database be faster? Have you (or anyone
> > else) done this
> > > comparison?
> >
> > 7.1 is considerably faster if you compare performan
Title: RE: [ADMIN] v7.1b4 bad performance
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 16, 2001 10:59 AM
> To: Schmidt, Peter
> Cc: 'Tom Lane'; 'Michael Ansley'; '[EMAIL PROTECTED]'
> > This is very strange. Is there any specific query that is causing the
> > problem? Does EXPLAIN show the same output on both versions?
> >
>
>
> "pgbench" doesn't execute any complex sql...
>
> Explain shows exactly the same output for both versions(7.03 & 7.1b4):
I see. That is bad.
Title: RE: [ADMIN] v7.1b4 bad performance
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 16, 2001 2:26 PM
> To: Schmidt, Peter
> Cc: 'Tom Lane'; 'Michael Ansley'; '[EMAIL PROTECTED]'
FWIW, I get the following pgbench results on my machine (HPPA C180,
fast-wide-SCSI drives that I do not recall the specs for):
current sources, with -F
$ pgbench -t 1000 bench
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
number of clients: 1
number of transactions p
BTW, what -B setting were you running the postmaster with? While poking
at this, I was reminded that having adequate buffer space really makes
a considerable difference ... especially under WAL, where it's not
necessary to flush dirty buffers to disk at the end of each transaction.
The default -B
Title: RE: [ADMIN] v7.1b4 bad performance
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> I got roughly twice the tps reading (pgbench -t 1000, with
> -F) at -B 1024.
>
I tried -B 1024 and got roughly the same results (~50 tps). However, wh
"Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> I tried -B 1024 and got roughly the same results (~50 tps).
What were you using before?
> However, when I change WAL option commit_delay from the default of 5
> to 0, I get ~200 tps (which is double what I get with 7.03). I'm not
> sure I want to do
[ Charset ISO-8859-1 unsupported, converting... ]
>
>
> > -Original Message-
> > From: Tom Lane [mailto:[EMAIL PROTECTED]]
> > I got roughly twice the tps reading (pgbench -t 1000, with
> > -F) at -B 1024.
> >
>
> I tried -B 1024 and got roughly the same results (~50 tps). However, wh
> The COMMIT_DELAY parameter defines for how long
>the backend will be forced to sleep after writing a commit record
>to the log with LogInsert call but before
>performing a LogFlush. This delay allows other
>backends to add their commit records to the log so as to have all
>of
Title: RE: [ADMIN] v7.1b4 bad performance
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 16, 2001 7:13 PM
> To: Schmidt, Peter
> Cc: 'Bruce Momjian'; 'Michael Ansley'; '[EMAIL PROTECTED]'
> I get ~50 tps for any commit_delay value > 0. I've tried many values in the
> range 0 - 999, and always get ~50 tps. commit_delay=0 always gets me ~200+
> tps.
>
> Yes, I have tried multiple clients but got stuck on the glaring difference
> between versions with a single client. The tests that
Title: RE: [ADMIN] v7.1b4 bad performance
> BTW, have you tried pgbench with multiple clients (-c) rather
> than just
> one?
>
> regards, tom lane
I was wrong about multiple clients...
I've seen as many as 230 tps with CommitDelay=0.
Peter
nu
Okay, am going to guess that all four of these results are with
CommitDelay=0, and for each higher number of clients, the results get
better and better ... what if you increase CommitDelay back to 5, for
those various levels of client connections?
On Fri, 16 Feb 2001, Schmidt, Peter wrote:
>
>
Title: RE: [ADMIN] v7.1b4 bad performance
> -Original Message-
> From: The Hermit Hacker [mailto:[EMAIL PROTECTED]]
> Okay, am going to guess that all four of these results are with
> CommitDelay=0,
You guessed right. Here are results for ComitDelay=5.
Peter
Title: RE: [ADMIN] v7.1b4 bad performance
My understanding is that the TPC-3 test are not about complex SQL, they are about transaction benching, and as such, it doesn't need to be complex SQL, it just needs to test the transactional speed of the engine. The pgbench appears to
Title: RE: [ADMIN] v7.1b4 bad performance
I would consider this perfectly acceptable. Official benchmarks can only be without the -F switch prior to 7.1, so in raw performance terms (with acceptable safety) you have to compare 7.0.2 without -F to 7.1beta4 with -F, because those are the
Michael Ansley <[EMAIL PROTECTED]> writes:
> I would consider this perfectly acceptable. Official benchmarks can only be
> without the -F switch prior to 7.1, so in raw performance terms (with
> acceptable safety) you have to compare 7.0.2 without -F to 7.1beta4 with -F,
> because those are the f
Title: RE: [ADMIN] v7.1b4 bad performance
I thought that -F only turned off the shared mem fsyncing. Obviously not. I'll rethink my analysis ;-)
-Original Message-
From: Tom Lane
To: Michael Ansley
Cc: 'Schmidt, Peter '; ''Bruce Momjian' '; &#x
> ... See included png file.
What kind of machine was this run on?
- Thomas
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 --
On Sat, 17 Feb 2001, Tom Lane wrote:
> How's that again? 7.1 with -F is just as much at the mercy of a system
> crash as previous releases with -F, because it's not fsync'ing the WAL
> log. In either case, -F is only for those who trust their hardware + OS
> + UPS, or perhaps are running deve
> "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
Dmitry Morozovsky wrote:
> On Sun, 18 Feb 2001, 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 overhead to scheduler syste
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> >
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
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
> -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
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
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
> 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
> 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
> -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% ?)
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
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
42 matches
Mail list logo
