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
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 system.
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 DM a bit
-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 each
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.
Hmm. It
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 never
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 rows in
-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% ?) of delay1
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 found is that
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 overhead to
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
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
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' '; ''[EMAIL PROTECTED]' '
Sent: 2-17-01 4:13
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.1b4 bad performance
Schmidt, Peter
"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
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]'
Subject: Re: [ADMIN] v7.1b4 bad performance
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. All other
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]'
Subject: Re: [ADMIN] v7.1b4 bad performance
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
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
"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, when I
change
The varnameCOMMIT_DELAY/varname parameter defines for how long
the backend will be forced to sleep after writing a commit record
to the log with functionLogInsert/function call but before
performing a functionLogFlush/function. This delay allows other
backends to add their commit
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]'
Subject: Re: [ADMIN] v7.1b4 bad performance
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 I ran
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
number of clients
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
comparison?
Also, I'm
"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 comparing
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 compare
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 like
31 matches
Mail list logo
