Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TBBBC-0007LG-6q for pgsql-performance@postgresql.org; Mon, 10 Sep 2012 21:06:02 +0000 Received: from ns3.uci.cu ([200.55.140.180] helo=mx3.uci.cu) by magus.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1TBBB4-0001R0-Bj for pgsql-performance@postgresql.org; Mon, 10 Sep 2012 21:06:01 +0000 Received: (qmail 11237 invoked by uid 507); 10 Sep 2012 20:59:03 -0000 Received: from 10.0.0.184 by ns3.uci.cu (envelope-from , uid 501) with qmail-scanner-2.01st (avp: 5.0.2.0. spamassassin: 3.0.6. perlscan: 2.01st. Clear:RC:1(10.0.0.184):. Processed in 1.193829 secs); 10 Sep 2012 20:59:03 -0000 Received: from unknown (HELO ucimail3.uci.cu) (10.0.0.184) by 0 with SMTP; 10 Sep 2012 20:59:02 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by ucimail3.uci.cu (Postfix) with ESMTP id 364D91E8C00B for ; Mon, 10 Sep 2012 16:59:02 -0400 (CDT) X-Virus-Scanned: amavisd-new at uci.cu Received: from ucimail3.uci.cu ([127.0.0.1]) by localhost (ucimail3.uci.cu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdY6OMcZO25k; Mon, 10 Sep 2012 16:58:58 -0400 (CDT) Received: by ucimail3.uci.cu (Postfix, from userid 101) id CDBE21E8C00E; Mon, 10 Sep 2012 16:58:58 -0400 (CDT) Received: from [10.8.46.124] (unknown [10.8.46.124]) (Authenticated sender: mlortiz@uci.cu) by ucimail3.uci.cu (Postfix) with ESMTPSA id BEF7F1E8C00F; Mon, 10 Sep 2012 16:58:58 -0400 (CDT) Message-ID: <504E5491.3020108@uci.cu> Date: Mon, 10 Sep 2012 16:58:57 -0400 From: Marcos Ortiz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Felix Schubert CC: pgsql-performance@postgresql.org Subject: Re: Slow Performance on a XEON E5504 References: <63BD52D1-CE65-4A82-9071-E2ED44E2527F@fescon.de> In-Reply-To: <63BD52D1-CE65-4A82-9071-E2ED44E2527F@fescon.de> Content-Type: multipart/alternative; boundary="------------070904020204050601060505" X-Pg-Spam-Score: -2.3 (--) X-Archive-Number: 201209/35 X-Sequence-Number: 47781 This is a multi-part message in MIME format. --------------070904020204050601060505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: input@fescon.de > skype: fesmac > > > > 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 --------------070904020204050601060505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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
skype: fesmac






--------------070904020204050601060505--