Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 4FC642E00A8 for ; Mon, 26 Nov 2007 20:57:26 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 21149-05 for ; Mon, 26 Nov 2007 20:57:15 -0400 (AST) Received: from westnet.com (westnet.com [216.187.52.2]) by postgresql.org (Postfix) with ESMTP id 298E92E0079 for ; Mon, 26 Nov 2007 20:57:22 -0400 (AST) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id lAR0vKQP026043; Mon, 26 Nov 2007 19:57:20 -0500 (EST) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id lAR0vK1L026039; Mon, 26 Nov 2007 19:57:20 -0500 (EST) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Mon, 26 Nov 2007 19:57:20 -0500 (EST) From: Greg Smith X-X-Sender: gsmith@westnet.com To: Damon Hart cc: pgsql-performance@postgresql.org Subject: Re: PostgreSQL performance on various distribution stock kernels In-Reply-To: <1196117408.19996.16.camel@xw1.bbd> Message-ID: References: <1196117408.19996.16.camel@xw1.bbd> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/314 X-Sequence-Number: 27729 On Mon, 26 Nov 2007, Damon Hart wrote: > Fedora 8: > Linux 2.6.23.1-49.fc8 #1 SMP Thu Nov 8 21:41:26 EST 2007 i686 i686 i386 > GNU/Linux > > OpenVZ: > Linux 2.6.18-8.1.15.el5.028stab049.1 #1 SMP Thu Nov 8 16:23:12 MSK 2007 > i686 i686 i386 GNU/Linux 2.6.23 introduced a whole new scheduler: http://www.linux-watch.com/news/NS2939816251.html so it's rather different from earlier 2.6 releases, and so new that there could easily be performance bugs. > Does your 10K RPM drive 166 TPS ceiling apply in this arrangement with > multiple disks Number of disks has nothing to do with it; it depends only on the rate the disk with the WAL volume is spinning at. But that's for a single client. > pgbench > scale: 50 > clients: 50 > transactions per client: 100 With this many clients, you can get far more transactions per second committed than the max for a single client (166@10K rpm). What you're seeing, somewhere around 500 per second, is reasonable. Note that you're doing two things that make pgbench less useful than it can be: 1) The number of transactions you're committing is trivial, which is one reason why your test runs have such a huge variation. Try 10000 transactions/client if you want something that doesn't vary quite so much. If it doesn't run for a couple of minutes, you're not going to get good repeatability. 2) The way pgbench works, it takes a considerable amount of resources to simulate this many clients. You might get higher (and more realistic) numbers if you run the pgbench client on another system than the server. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD