pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedSlow Performance on a XEON E5504
9+ messages / 3 participants
[nested] [flat]
* Slow Performance on a XEON E5504
@ 2012-08-24 09:47 Felix Schubert <input@fescon.de>
2012-09-10 20:58 ` Re: Slow Performance on a XEON E5504 Marcos Ortiz <mlortiz@uci.cu>
0 siblings, 1 reply; 9+ messages in thread
From: Felix Schubert @ 2012-08-24 09:47 UTC (permalink / raw)
To: pgsql-performance
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: input@fescon.de
skype: fesmac
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Slow Performance on a XEON E5504
2012-08-24 09:47 Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
@ 2012-09-10 20:58 ` Marcos Ortiz <mlortiz@uci.cu>
0 siblings, 0 replies; 9+ messages in thread
From: Marcos Ortiz @ 2012-09-10 20:58 UTC (permalink / raw)
To: Felix Schubert <input@fescon.de>; +Cc: pgsql-performance
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 <mailto:input@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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Slow Performance on a XEON E5504
@ 2012-08-25 12:07 Felix Schubert <input@fescon.de>
2012-08-25 12:42 ` Re: Slow Performance on a XEON E5504 Scott Marlowe <scott.marlowe@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Felix Schubert @ 2012-08-25 12:07 UTC (permalink / raw)
To: pgsql-performance
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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Slow Performance on a XEON E5504
2012-08-25 12:07 Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
@ 2012-08-25 12:42 ` Scott Marlowe <scott.marlowe@gmail.com>
2012-08-25 12:53 ` Re: Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
0 siblings, 1 reply; 9+ messages in thread
From: Scott Marlowe @ 2012-08-25 12:42 UTC (permalink / raw)
To: Felix Schubert <input@fescon.de>; +Cc: pgsql-performance
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?
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Slow Performance on a XEON E5504
2012-08-25 12:07 Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
2012-08-25 12:42 ` Re: Slow Performance on a XEON E5504 Scott Marlowe <scott.marlowe@gmail.com>
@ 2012-08-25 12:53 ` Felix Schubert <input@fescon.de>
2012-08-25 12:59 ` Re: Slow Performance on a XEON E5504 Scott Marlowe <scott.marlowe@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Felix Schubert @ 2012-08-25 12:53 UTC (permalink / raw)
To: Scott Marlowe <scott.marlowe@gmail.com>; +Cc: pgsql-performance
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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Slow Performance on a XEON E5504
2012-08-25 12:07 Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
2012-08-25 12:42 ` Re: Slow Performance on a XEON E5504 Scott Marlowe <scott.marlowe@gmail.com>
2012-08-25 12:53 ` Re: Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
@ 2012-08-25 12:59 ` Scott Marlowe <scott.marlowe@gmail.com>
2012-08-25 13:04 ` Re: Slow Performance on a XEON E5504 Scott Marlowe <scott.marlowe@gmail.com>
2012-08-25 21:26 ` Re: Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
0 siblings, 2 replies; 9+ messages in thread
From: Scott Marlowe @ 2012-08-25 12:59 UTC (permalink / raw)
To: Felix Schubert <input@fescon.de>; +Cc: pgsql-performance
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?
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Slow Performance on a XEON E5504
2012-08-25 12:07 Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
2012-08-25 12:42 ` Re: Slow Performance on a XEON E5504 Scott Marlowe <scott.marlowe@gmail.com>
2012-08-25 12:53 ` Re: Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
2012-08-25 12:59 ` Re: Slow Performance on a XEON E5504 Scott Marlowe <scott.marlowe@gmail.com>
@ 2012-08-25 13:04 ` Scott Marlowe <scott.marlowe@gmail.com>
1 sibling, 0 replies; 9+ messages in thread
From: Scott Marlowe @ 2012-08-25 13:04 UTC (permalink / raw)
To: Felix Schubert <input@fescon.de>; +Cc: 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.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Slow Performance on a XEON E5504
2012-08-25 12:07 Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
2012-08-25 12:42 ` Re: Slow Performance on a XEON E5504 Scott Marlowe <scott.marlowe@gmail.com>
2012-08-25 12:53 ` Re: Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
2012-08-25 12:59 ` Re: Slow Performance on a XEON E5504 Scott Marlowe <scott.marlowe@gmail.com>
@ 2012-08-25 21:26 ` Felix Schubert <input@fescon.de>
2012-08-25 21:47 ` Re: Slow Performance on a XEON E5504 Scott Marlowe <scott.marlowe@gmail.com>
1 sibling, 1 reply; 9+ messages in thread
From: Felix Schubert @ 2012-08-25 21:26 UTC (permalink / raw)
To: Scott Marlowe <scott.marlowe@gmail.com>; +Cc: pgsql-performance
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?
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Slow Performance on a XEON E5504
2012-08-25 12:07 Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
2012-08-25 12:42 ` Re: Slow Performance on a XEON E5504 Scott Marlowe <scott.marlowe@gmail.com>
2012-08-25 12:53 ` Re: Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
2012-08-25 12:59 ` Re: Slow Performance on a XEON E5504 Scott Marlowe <scott.marlowe@gmail.com>
2012-08-25 21:26 ` Re: Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
@ 2012-08-25 21:47 ` Scott Marlowe <scott.marlowe@gmail.com>
0 siblings, 0 replies; 9+ messages in thread
From: Scott Marlowe @ 2012-08-25 21:47 UTC (permalink / raw)
To: Felix Schubert <input@fescon.de>; +Cc: pgsql-performance
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.
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2012-09-10 20:58 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2012-08-24 09:47 Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
2012-09-10 20:58 ` Marcos Ortiz <mlortiz@uci.cu>
2012-08-25 12:07 Slow Performance on a XEON E5504 Felix Schubert <input@fescon.de>
2012-08-25 12:42 ` Scott Marlowe <scott.marlowe@gmail.com>
2012-08-25 12:53 ` Felix Schubert <input@fescon.de>
2012-08-25 12:59 ` Scott Marlowe <scott.marlowe@gmail.com>
2012-08-25 13:04 ` Scott Marlowe <scott.marlowe@gmail.com>
2012-08-25 21:26 ` Felix Schubert <input@fescon.de>
2012-08-25 21:47 ` Scott Marlowe <scott.marlowe@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox