Re: Ideal disk setup for Postgresql 7.4?
От | Steve Poe |
---|---|
Тема | Re: Ideal disk setup for Postgresql 7.4? |
Дата | |
Msg-id | 41F79610.20003@sfnet.cc обсуждение исходный текст |
Ответ на | Re: Ideal disk setup for Postgresql 7.4? (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Ideal disk setup for Postgresql 7.4?
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: Ideal disk setup for Postgresql 7.4? (Josh Berkus <josh@agliodbs.com>) |
Список | 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 по дате отправления: