Thread: Slow Performance on a XEON E5504
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) 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) Even optimizing the postgresql.conf values doesn't change a lot on the tps values. (less than 10%) Tried Postgresql 9.1 on the Proliant: transaction type: TPC-B (sort of) scaling factor: 1 query mode: simple number of clients: 40 number of threads: 1 number of transactions per client: 100 number of transactions actually processed: 4000/4000 tps = 53.114978 (including connections establishing) tps = 53.198667 (excluding connections establishing) Next was to compare the diskperformance which was much better on the XEON than on the Intel i7. Any idea where to search for the bottleneck? best regards, Felix Schubert
On Sat, Aug 25, 2012 at 6:07 AM, Felix Schubert <input@fescon.de> 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?
Hi Scott, the controller is a HP i410 running 3x300GB SAS 15K / Raid 5 Mit freundlichen Grüßen Felix Schubert Von meinem iPhone gesendet :-) Am 25.08.2012 um 14:42 schrieb Scott Marlowe <scott.marlowe@gmail.com>: > On Sat, Aug 25, 2012 at 6:07 AM, Felix Schubert <input@fescon.de> 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance
On Sat, Aug 25, 2012 at 6:59 AM, Scott Marlowe <scott.marlowe@gmail.com> wrote: > On Sat, Aug 25, 2012 at 6:53 AM, Felix Schubert <input@fescon.de> wrote: >> Hi Scott, >> >> the controller is a HP i410 running 3x300GB SAS 15K / Raid 5 > > Well it sounds like it does NOT have a battery back caching module on > it, am I right? Also what software did you use to benchmark your drive subsystem? Bonnie++ is a good place to start. There are better suites out there but it's been a while for me since I've used them. Also note the HP i410 is not the fastest RAID controller ever, but it should be faster than this if it has a battery backed cache on it which will allow write-back operation. Without it the controller will default to write-through, which is much slower.
On Sat, Aug 25, 2012 at 6:53 AM, Felix Schubert <input@fescon.de> wrote: > Hi Scott, > > the controller is a HP i410 running 3x300GB SAS 15K / Raid 5 Well it sounds like it does NOT have a battery back caching module on it, am I right?
Don't know but I forwarded the question to the System Administrator.
Anyhow thanks for the information up to now!
best regards,
Felix
Am 25.08.2012 um 14:59 schrieb Scott Marlowe <scott.marlowe@gmail.com>:
Well it sounds like it does NOT have a battery back caching module on
it, am I right?
No problem, hope it helps. The single most important part of any fast, transactional server is the RAID controller and its cache. On Sat, Aug 25, 2012 at 3:26 PM, Felix Schubert <input@fescon.de> wrote: > Don't know but I forwarded the question to the System Administrator. > > Anyhow thanks for the information up to now! > > best regards, > > Felix > > Am 25.08.2012 um 14:59 schrieb Scott Marlowe <scott.marlowe@gmail.com>: > > Well it sounds like it does NOT have a battery back caching module on > it, am I right? > > -- To understand recursion, one must first understand recursion.