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@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
