Re: [PERFORM] Slow Performance on a XEON E5504
On 08/24/2012 05:47 AM, Felix Schubert 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) 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? Regards, Felix. There are many question there: - Are you using the same disc models in both systems (Xeon and Intel i7)? - Which are the values for work_mem, shared_buffers, maintainance_work_men, effective_io_cache, etc ? - Is PostgreSQL the unique service in these servers? My first advice is that PostgreSQL 9.2 was released today, which has a lot of major performance improvements, so, you should update your both installations to this new version to obtain a better performance, security and stability. Best wishes Mit freundlichen Grüßen Felix Schubert FEScon ... and work flows! felix schubert haspelgasse 5 69117 heidelberg mobil: +49-151-25337718 mail: in...@fescon.de mailto:in...@fescon.de skype: fesmac http://www.uci.cu/ 10mo. ANIVERSARIO DE LA CREACION DE LA UNIVERSIDAD DE LAS CIENCIAS INFORMATICAS... CONECTADOS AL FUTURO, CONECTADOS A LA REVOLUCION http://www.uci.cu http://www.facebook.com/universidad.uci http://www.flickr.com/photos/universidad_uci
[PERFORM] 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? Mit freundlichen Grüßen Felix Schubert FEScon ... and work flows! felix schubert haspelgasse 5 69117 heidelberg mobil: +49-151-25337718 mail: in...@fescon.de skype: fesmac
[PERFORM] 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 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Slow Performance on a XEON E5504
On Sat, Aug 25, 2012 at 6:07 AM, Felix Schubert in...@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
Re: [PERFORM] Slow Performance on a XEON E5504
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.marl...@gmail.com: On Sat, Aug 25, 2012 at 6:07 AM, Felix Schubert in...@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 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Slow Performance on a XEON E5504
On Sat, Aug 25, 2012 at 6:59 AM, Scott Marlowe scott.marl...@gmail.com wrote: On Sat, Aug 25, 2012 at 6:53 AM, Felix Schubert in...@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. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Slow Performance on a XEON E5504
On Sat, Aug 25, 2012 at 6:53 AM, Felix Schubert in...@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? -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
Re: [PERFORM] Slow Performance on a XEON E5504
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.marl...@gmail.com: Well it sounds like it does NOT have a battery back caching module on it, am I right?
Re: [PERFORM] Slow Performance on a XEON E5504
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 in...@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.marl...@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. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
