pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedPractical upper limits of pgbench read/write tps with 8.3
3+ messages / 2 participants
[nested] [flat]
* Practical upper limits of pgbench read/write tps with 8.3
@ 2008-07-07 21:05 Jeffrey Baker <jwbaker@gmail.com>
2008-07-07 22:22 ` Re: Practical upper limits of pgbench read/write tps with 8.3 Greg Smith <gsmith@gregsmith.com>
0 siblings, 1 reply; 3+ messages in thread
From: Jeffrey Baker @ 2008-07-07 21:05 UTC (permalink / raw)
To: pgsql-performance
I'm spending a third day testing with the ioDrive, and it occurred to
me that I should normalize my tests by mounting the database on a
ramdisk. The results were surprisingly low. On the single 2.2GHz
Athlon, the maximum tps seems to be 1450. This is achieved with a
single connection. I/O rates to and from the ramdisk never exceed
50MB/s on a one-minute average.
With the flash device on the same benchmark, the tps rate is 1350,
meaning that as far as PostgreSQL is concerned, on this machine, the
flash device achieves 90% of the best possible performance.
Question being: what's the bottleneck? Is PG lock-bound?
-jwb
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Practical upper limits of pgbench read/write tps with 8.3
2008-07-07 21:05 Practical upper limits of pgbench read/write tps with 8.3 Jeffrey Baker <jwbaker@gmail.com>
@ 2008-07-07 22:22 ` Greg Smith <gsmith@gregsmith.com>
2008-07-08 03:39 ` Re: Practical upper limits of pgbench read/write tps with 8.3 Jeffrey Baker <jwbaker@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Greg Smith @ 2008-07-07 22:22 UTC (permalink / raw)
To: Jeffrey Baker <jwbaker@gmail.com>; +Cc: pgsql-performance
On Mon, 7 Jul 2008, Jeffrey Baker wrote:
> On the single 2.2GHz Athlon, the maximum tps seems to be 1450...what's
> the bottleneck? Is PG lock-bound?
It can become lock-bound if you don't make the database scale
significantly larger than the number of clients, but that's probably not
your problem. The pgbench client driver program itself is pretty CPU
intensive and can suffer badly from kernel issues. I am unsurprised you
can only hit 1450 with a single CPU. On systems with multiple CPUs where
the single CPU running the pgbench client is much faster than your 2.2GHz
Athlon, you'd probably be able to get a few thousand TPS, but eventually
the context switching of the client itself can become a bottleneck.
Running pgbench against a RAM disk is a good way to find out where the
system bottlenecks at without disk I/O involvement, you might try that
test on your larger server when you get a chance. One interesting thing
to watch you may not have tried yet is running top and seeing how close to
a single CPU pgbench itself is running at. If you've got 4 CPUs, and the
pgbench client program shows 25% utilization, it is now the bottleneck
rather than whatever you thought you were measuring. I thought this might
be the case in the last test results you reported on Friday but didn't
have a chance to comment on it until now.
One thing you can try here is running pgbench itself on another server
than the one hosting the database, but that seems to top out at a few
thousand TPS as well; may get higher than you've been seeing though.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Practical upper limits of pgbench read/write tps with 8.3
2008-07-07 21:05 Practical upper limits of pgbench read/write tps with 8.3 Jeffrey Baker <jwbaker@gmail.com>
2008-07-07 22:22 ` Re: Practical upper limits of pgbench read/write tps with 8.3 Greg Smith <gsmith@gregsmith.com>
@ 2008-07-08 03:39 ` Jeffrey Baker <jwbaker@gmail.com>
0 siblings, 0 replies; 3+ messages in thread
From: Jeffrey Baker @ 2008-07-08 03:39 UTC (permalink / raw)
To: Greg Smith <gsmith@gregsmith.com>; +Cc: pgsql-performance
On Mon, Jul 7, 2008 at 3:22 PM, Greg Smith <gsmith@gregsmith.com> wrote:
> On Mon, 7 Jul 2008, Jeffrey Baker wrote:
>
>> On the single 2.2GHz Athlon, the maximum tps seems to be 1450...what's the
>> bottleneck? Is PG lock-bound?
>
> It can become lock-bound if you don't make the database scale significantly
> larger than the number of clients, but that's probably not your problem.
> The pgbench client driver program itself is pretty CPU intensive and can
> suffer badly from kernel issues. I am unsurprised you can only hit 1450
> with a single CPU. On systems with multiple CPUs where the single CPU
> running the pgbench client is much faster than your 2.2GHz Athlon, you'd
> probably be able to get a few thousand TPS, but eventually the context
> switching of the client itself can become a bottleneck.
On a 2GHz Core 2 Duo the best tps achieved is 2300, with -c 8.
pgbench itself gets around 10% of the CPU (user + sys for pgbench is
7s of 35s wall clock time, or 70 CPU-seconds, thus 10%).
I suppose you could still blame it on ctxsw between pgbench and pg
itself, but the results are not better with pgbench on another machine
cross-connected with gigabit ethernet.
-jwb
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2008-07-08 03:39 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2008-07-07 21:05 Practical upper limits of pgbench read/write tps with 8.3 Jeffrey Baker <jwbaker@gmail.com>
2008-07-07 22:22 ` Greg Smith <gsmith@gregsmith.com>
2008-07-08 03:39 ` Jeffrey Baker <jwbaker@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox