On Sat, Aug 25, 2012 at 6:07 AM, Felix Schubert <input@xxxxxxxxx> wrote: > Hello List, > > I've got a system on a customers location which has a XEON E5504 @ 2.00GHz Processor (HP Proliant) > > It's postgres 8.4 on a Debian Squeeze System running with 8GB of ram: > > The Postgres Performance on this system measured with pgbench is very poor: > > transaction type: TPC-B (sort of) > scaling factor: 1 > query mode: simple > number of clients: 40 > number of transactions per client: 100 > number of transactions actually processed: 4000/4000 > tps = 158.283272 (including connections establishing) > tps = 158.788545 (excluding connections establishing) For a single thread on a 10k RPM drive the maximum number of times per second you can write and get a proper fsync back is 166. This is quite close to that theoretical max. > The same database on a Core i7 CPU 920 @ 2.67GHz, 8 cores with 8GB RAM same distro and Postgresql Version is much faster: > > transaction type: TPC-B (sort of) > scaling factor: 1 > query mode: simple > number of clients: 40 > number of transactions per client: 100 > number of transactions actually processed: 4000/4000 > tps = 1040.534002 (including connections establishing) > tps = 1065.215134 (excluding connections establishing) This is much faster than the theoretical limit of a single 10k RPM drive obeying fsync. I'll ignore the rest of your post where you get 53 tps after optimization. The important thing you forgot to mention was your drive subsystem here. I'm gonna take a wild guess that they are both on a single drive and that the older machine is using an older SATA or PATA interface HD that is lying about fsync, and the new machine is using a 10k RPM drive that is not lying about fsync and you are getting a proper ~150 tps from it. So, what kind of IO subsystems you got in those things? -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
