Re: strange performance regression between 7.4 and 8.1

On 3/2/07, Ron <rjpeace@earthlink.net> wrote:
> At 02:43 PM 3/2/2007, Alex Deucher wrote:
> >On 3/2/07, Ron <rjpeace@earthlink.net> wrote:
> >>
> >>...and I still think looking closely at the actual physical layout of
> >>the tables in the SAN is likely to be worth it.
> >
> >How would I go about doing that?
> >
> >Alex
>
> Hard for me to give specific advice when I don't know what SAN
> product we are talking about nor what kind of HDs are in it nor how
> those HDs are presently configured...
>
> I quote you in an earlier post:
> "The RAID groups on the SAN were set up for maximum capacity rather
> than for performance.  Using it for the databases just came up recently."
>
> That implies to me that the SAN is more or less set up as a huge 105
> HD (assuming this number is correct?  We all know how "assume" is
> spelled...) JBOD or RAID 5 (or 6, or 5*, or 6*) set.
>
> =IF= that is true, tables are not being given dedicated RAID
> groups.  That implies that traditional lore like having pg_xlog on
> dedicated spindles is being ignored.
> Nor is the more general Best Practice of putting the most heavily
> used tables onto dedicated spindles being followed.
>
> In addition, the most space efficient RAID levels: 5* or 6*, are not
> the best performing one (RAID 10 striping your mirrors)
>
> In short, configuring a SAN for maximum capacity is exactly the wrong
> thing to do if one is planning to use it in the best way to support
> DB performance.
>
> I assume (there's that word again...) that there is someone in your
> organization who understands how the SAN is configured and administered.
> You need to talk to them about these issues.
>

Ah OK.  I see what you are saying;  thank you for clarifying.  Yes,
the SAN is configured for maximum capacity; it has large RAID 5
groups.  As I said earlier, we never intended to run a DB on the SAN,
it just happened to come up, hence the configuration.

Alex