Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 044DA650EA9 for ; Tue, 1 Jul 2008 22:38:17 -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 45096-09 for ; Tue, 1 Jul 2008 22:38: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 30D9E650EA7 for ; Tue, 1 Jul 2008 22:38:09 -0300 (ADT) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id m621c4g5009797; Tue, 1 Jul 2008 21:38:04 -0400 (EDT) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id m621c4fa009793; Tue, 1 Jul 2008 21:38:04 -0400 (EDT) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Tue, 1 Jul 2008 21:38:04 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: Jeffrey Baker cc: "pgsql-performance@postgresql.org" Subject: Re: Fusion-io ioDrive 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/14 X-Sequence-Number: 30614 On Tue, 1 Jul 2008, Jeffrey Baker wrote: > The only real problem with this benchmark is that the machine became > CPU-limited rather quickly. During the runs with the ioDrive, iowait was > pretty well zero, with user CPU being about 75% and system getting about > 20%. You might try reducing the number of clients; with a single CPU like yours I'd expect peak throughput here would be at closer to 4 clients rather than 8, and possibly as low as 2. What I normally do is run a quick scan of a few client loads before running a long test to figure out where the general area of peak throughput is. For your 8-way box, it will be closer to 32 clients. Well done test though. When you try again with the faster system, the only other postgresql.conf parameter I'd suggest bumping up is wal_buffers; that can limit best pgbench scores a bit and it only needs a MB or so to make that go away. It's also worth nothing that the gap between the two types of storage will go up up if you increase scale further; scale=100 is only making a 1.5GB or so database. If you collected a second data point at a scale of 500 I'd expect the standard disk results would halve by then, but I don't know what the fusion device would do and I'm kind of curious. You may need to increase this regardless because the bigger box has more RAM, and you want the database to be larger than RAM to get interesting results in this type of test. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD