Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 0E3096503E3 for ; Mon, 7 Jul 2008 19:22:16 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 03310-09 for ; Mon, 7 Jul 2008 19:22:08 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from westnet.com (westnet.com [216.187.52.2]) by postgresql.org (Postfix) with ESMTP id E2333650399 for ; Mon, 7 Jul 2008 19:22:07 -0300 (ADT) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id m67MM51Z019046; Mon, 7 Jul 2008 18:22:05 -0400 (EDT) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id m67MM5pu019042; Mon, 7 Jul 2008 18:22:05 -0400 (EDT) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Mon, 7 Jul 2008 18:22:05 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: Jeffrey Baker cc: "pgsql-performance@postgresql.org" Subject: Re: Practical upper limits of pgbench read/write tps with 8.3 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200807/65 X-Sequence-Number: 30665 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