Skip site navigation (1) Skip section navigation (2)

SAN performance mystery

From: Tim Allen <tim(at)proximity(dot)com(dot)au>
To: pgsql-performance(at)postgresql(dot)org
Subject: SAN performance mystery
Date: 2006-06-15 21:50:19
Message-ID: 4491D61B.9040507@proximity.com.au (view raw or flat)
Thread:
Lists: pgsql-performance
We have a customer who are having performance problems. They have a 
large (36G+) postgres 8.1.3 database installed on an 8-way opteron with 
8G RAM, attached to an EMC SAN via fibre-channel (I don't have details 
of the EMC SAN model, or the type of fibre-channel card at the moment). 
They're running RedHat ES3 (which means a 2.4.something Linux kernel).

They are unhappy about their query performance. We've been doing various 
things to try to work out what we can do. One thing that has been 
apparent is that autovacuum has not been able to keep the database 
sufficiently tamed. A pg_dump/pg_restore cycle reduced the total 
database size from 81G to 36G. Performing the restore took about 23 hours.

We tried restoring the pg_dump output to one of our machines, a 
dual-core pentium D with a single SATA disk, no raid, I forget how much 
RAM but definitely much less than 8G. The restore took five hours. So it 
would seem that our machine, which on paper should be far less 
impressive than the customer's box, does more than four times the I/O 
performance.

To simplify greatly - single local SATA disk beats EMC SAN by factor of 
four.

Is that expected performance, anyone? It doesn't sound right to me. Does 
anyone have any clues about what might be going on? Buggy kernel 
drivers? Buggy kernel, come to think of it? Does a SAN just not provide 
adequate performance for a large database?

I'd be grateful for any clues anyone can offer,

Tim



Attachment: tim.vcf
Description: text/x-vcard (117 bytes)

Responses

pgsql-performance by date

Next:From: Scott MarloweDate: 2006-06-15 21:56:54
Subject: Re: SAN performance mystery
Previous:From: Bruce MomjianDate: 2006-06-15 21:46:29
Subject: Re: Test request for Stats collector performance improvement

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group