Re: Ideal disk setup for Postgresql 7.4? - Mailing list pgsql-performance

From Steve Poe
Subject Re: Ideal disk setup for Postgresql 7.4?
Date
Msg-id 41F79610.20003@sfnet.cc
Whole thread Raw
In response to Re: Ideal disk setup for Postgresql 7.4?  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Ideal disk setup for Postgresql 7.4?
Re: Ideal disk setup for Postgresql 7.4?
List pgsql-performance
>FWIW, 7.4.6 is a binary, drop-in place upgrade for 7.4.2.  And 7.4.2 has known
>bugs.   However, I understand your situation.
>
>
>
As soon as we get the go-ahead, I will upgrade. I think the company is
actually looking towards 8.0 certification.

>>Okay, thanks. Even with 7-disks? I trust that.
>>
>>
>
>Well, it's less bad with 7 disks than it is with 3, certainly.   However,there
>is an obvious and quick gain to be had by splitting off the WAL logs onto
>their own disk resource ... up to 14%+ performance in some applications.
>
>
>
Pardon my ignorance, but the WAL logs are comprised of pg_xlog and
pg_clog? Their own disk resource, but not within the same channel of
disks the database is on, right?

>>So, RAID 1+0 (sw) is
>>probably the best option. I've run sw RAID personally for years without
>>issue. I am a bit hesitant in doing sw RAID for a production server for
>>a database --- probably because its not my server. Any thoughts on sw
>>RAID for Postgresql?
>>
>>
>
>Yes.   See my article for one.  In generaly, SW RAID on BSD or Linux works
>well for PostgreSQL ... UNLESS your machine is already CPU-bound, in which
>case it's a bad idea.   If you're hitting the CS bug, it's definitely a bad
>idea, because the SW RAID will increase context switching.
>
>So if your choice, on your system, is between sw RAID 10, and hw RAID 5, and
>you're having excessive CSes, I'd stick with the HW RAID.
>
>
>
Okay. InCPU-bound servers, use hw RAID. Any hw raids to avoid?

>>Okay. Darn. While I don't write the queries for the application, I do
>>interact with the company frequently. Their considering moving the
>>queries into the database with PL/pgSQL. Currently their queries are
>>done through ProvIV development using ODBC. Will context switching be
>>minimized here by using PL/pgSQL?
>>
>>
>
>Won't make a difference, actually.   Should improve performance in other ways,
>though, by reducing round-trip time on procedures.  Feel free to recommend
>the company to this list.
>
>
>
I think their too busy to monitor/watch this list. Not a put-down to
them, but I have to do my own leg work to help decide what we're going
to do.

>>Dual Xeon 2.8 CPUs with HT turned off.
>>
>>
>
>Yeah, thought it was a Xeon.
>
>
>
If we went with a single CPU, like Athlon/Opertron64,  would CS
storming  go away?


Thanks.

Steve Poe

pgsql-performance by date:

Previous
From: PFC
Date:
Subject: Re: 200 times slower then MSSQL??
Next
From: PFC
Date:
Subject: Re: [SQL] OFFSET impact on Performance???