Re: [PERFORM] Is Vacuum/analyze destroying my performance?

2006-12-04 Thread Matthew O'Connor
Just a wild guess, but the performance problem sounds like maybe as your data changes, eventually the planner moves some query from an index scan to a sequential scan, do you have any details on what queries are taking so long when things are running slow? You can turn on the GUC var

Re: [PERFORM] 8.2rc1 (much) slower than 8.2dev?

2006-12-04 Thread Tom Lane
Arjen van der Meijden [EMAIL PROTECTED] writes: I'll run another analyze on the database to see if that makes any difference, but after that I'm not sure what to check first to figure out where things go wrong? Look for changes in plans? regards, tom lane

Re: [PERFORM] Bad iostat numbers

2006-12-04 Thread Scott Marlowe
On Mon, 2006-12-04 at 01:17, Alex Turner wrote: People recommend LSI MegaRAID controllers on here regularly, but I have found that they do not work that well. I have bonnie++ numbers that show the controller is not performing anywhere near the disk's saturation level in a simple RAID 1 on

Re: [PERFORM] Bad iostat numbers

2006-12-04 Thread Scott Marlowe
On Mon, 2006-12-04 at 10:25, Scott Marlowe wrote: OTOH, with the choice at my last place of employment being LSI or Adaptec, LSI was a much better choice. :) I'd ask which LSI megaraid you've tested, and what driver was used. Does RHEL4 have the megaraid 2 driver? Just wanted to add

Re: [PERFORM] 8.2rc1 (much) slower than 8.2dev?

2006-12-04 Thread Arjen van der Meijden
Tom Lane wrote: Arjen van der Meijden [EMAIL PROTECTED] writes: I'll run another analyze on the database to see if that makes any difference, but after that I'm not sure what to check first to figure out where things go wrong? Look for changes in plans? Yeah, there are a few number of

Re: [PERFORM] Is Vacuum/analyze destroying my performance?

2006-12-04 Thread Carlo Stonebanks
Matthew O'Connor matthew@zeut.net wrote in message news:[EMAIL PROTECTED] Just a wild guess, but the performance problem sounds like maybe as your data changes, eventually the planner moves some query from an index scan to a sequential scan, do you have any details on what queries are taking

[PERFORM] Configuration settings for 32GB RAM server

2006-12-04 Thread Mark Lonsdale
Hi We are migrating our Postgres 7.3.4 application to postgres 8.1.5 and also moving it to a server with a much larger hardware configuration as well.The server will have the following specification. - 4 physical CPUs (hyperthreaded to 8) - 32 GB RAM - x86_64 architecture

Re: [PERFORM] Bad iostat numbers

2006-12-04 Thread Alex Turner
The RAID 10 was in there merely for filling in, not really as a compare, indeed it would be ludicrous to compare a RAID 1 to a 6 drive RAID 10!! How do I find out if it has version 2 of the driver? This discussion I think is important, as I think it would be useful for this list to have a list

Re: [PERFORM] Configuration settings for 32GB RAM server

2006-12-04 Thread Jeff Davis
On Mon, 2006-12-04 at 12:10 -0500, Mark Lonsdale wrote: - 4 physical CPUs (hyperthreaded to 8) - 32 GB RAM - x86_64 architecture - RedHat AS 4 - postgres 8.1.5 Ive been taking a look at the various postgres tuning parameters, and have come up with the following settings.

Re: [PERFORM] Bad iostat numbers

2006-12-04 Thread Michael Stone
On Mon, Dec 04, 2006 at 12:37:29PM -0500, Alex Turner wrote: This discussion I think is important, as I think it would be useful for this list to have a list of RAID cards that _do_ work well under Linux/BSD for people as recommended hardware for Postgresql. So far, all I can recommend is what

[PERFORM] How to move pg_xlog to another drive on Windows????

2006-12-04 Thread Joost Kraaijeveld
How can I move pg_xlog to another drive on Windows? In Linux I can use a symlink, but how do I that on windows? -- Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 web: www.askesis.nl ---(end of

Re: [PERFORM] Bad iostat numbers

2006-12-04 Thread Alex Turner
http://en.wikipedia.org/wiki/RAID_controller Alex On 12/4/06, Michael Stone [EMAIL PROTECTED] wrote: On Mon, Dec 04, 2006 at 12:37:29PM -0500, Alex Turner wrote: This discussion I think is important, as I think it would be useful for this list to have a list of RAID cards that _do_ work well

Re: [PERFORM] Bad iostat numbers

2006-12-04 Thread Michael Stone
On Mon, Dec 04, 2006 at 12:52:46PM -0500, Alex Turner wrote: http://en.wikipedia.org/wiki/RAID_controller What is the wikipedia quote supposed to prove? Pray tell, if you consider RAID==HBA, what would you call a SCSI (e.g.) controller that has no RAID functionality? If you'd call it an HBA,

Re: [PERFORM] Bad iostat numbers

2006-12-04 Thread Scott Marlowe
On Mon, 2006-12-04 at 11:43, Michael Stone wrote: On Mon, Dec 04, 2006 at 12:37:29PM -0500, Alex Turner wrote: This discussion I think is important, as I think it would be useful for this list to have a list of RAID cards that _do_ work well under Linux/BSD for people as recommended hardware

Re: [PERFORM] Bad iostat numbers

2006-12-04 Thread Scott Marlowe
On Mon, 2006-12-04 at 11:37, Alex Turner wrote: The RAID 10 was in there merely for filling in, not really as a compare, indeed it would be ludicrous to compare a RAID 1 to a 6 drive RAID 10!! How do I find out if it has version 2 of the driver? Go to the directory it lives in (on my Fedora

Re: [PERFORM] Configuration settings for 32GB RAM server

2006-12-04 Thread Vivek Khera
On Dec 4, 2006, at 12:10 PM, Mark Lonsdale wrote: - 4 physical CPUs (hyperthreaded to 8) i'd tend to disable hyperthreading on Xeons... shared_buffers – 50,000 - From what Id read, increasing this number higher than this wont have any advantages ? if you can, increase it until

Re: [PERFORM] Configuration settings for 32GB RAM server

2006-12-04 Thread Joshua Marsh
On 12/4/06, Mark Lonsdale [EMAIL PROTECTED] wrote: Maintenance_work_mem = 1048576 – Figured Id allocate 1GB for this. Do you know how often and when you will be creating indexes or clustering? We set ours to 2GB because of the performance gains. We've also thought about testing it at 4GB.

Re: [PERFORM] How to move pg_xlog to another drive on Windows????

2006-12-04 Thread Merlin Moncure
On 12/4/06, Joost Kraaijeveld [EMAIL PROTECTED] wrote: How can I move pg_xlog to another drive on Windows? In Linux I can use a symlink, but how do I that on windows? you can possibly attempt it with junction points. good luck: http://support.microsoft.com/kb/205524 merlin

Re: [PERFORM] Configuration settings for 32GB RAM server

2006-12-04 Thread Scott Marlowe
On Mon, 2006-12-04 at 12:57, Joshua Marsh wrote: On 12/4/06, Mark Lonsdale [EMAIL PROTECTED] wrote: Maintenance_work_mem = 1048576 – Figured Id allocate 1GB for this. Do you know how often and when you will be creating indexes or clustering? We set

Re: [PERFORM] How to move pg_xlog to another drive on Windows????

2006-12-04 Thread Anthony Presley
Hmm ... I'm guessing you'd do it with a shortcut, and then rename the ShortCut from Shortcut to pg_xlog to pg_xlog. Haven't done it with PostgreSQL, but it works with a few other programs I've had to do that with. -- Anthony Presley Resolution Software Owner/Founder www.resolution.com On Mon,

Re: [PERFORM] Configuration settings for 32GB RAM server

2006-12-04 Thread Dave Cramer
On 4-Dec-06, at 12:10 PM, Mark Lonsdale wrote: Hi We are migrating our Postgres 7.3.4 application to postgres 8.1.5 and also moving it to a server with a much larger hardware configuration as well.The server will have the following specification. - 4 physical CPUs

[PERFORM] pgsql upgrade

2006-12-04 Thread Matt Chambers
Hi all, I've run into an issue with a Pg 7.4.6 to 8.1.5 upgrade along with hardware upgrade. I moved the database from a 2x 3.0ghz Xeon (512kb w/HT) to a 2x Opteron 250. The database is in memory on a tmpfs partition. (the application can rebuild the db during total system failure) When I

Re: [PERFORM] Bad iostat numbers

2006-12-04 Thread Greg Smith
On Mon, 4 Dec 2006, Alex Turner wrote: People recommend LSI MegaRAID controllers on here regularly, but I have found that they do not work that well. I have bonnie++ numbers that show the controller is not performing anywhere near the disk's saturation level in a simple RAID 1 on RedHat

Re: [PERFORM] Is Vacuum/analyze destroying my performance?

2006-12-04 Thread Matthew T. O'Connor
Carlo Stonebanks wrote: Just a wild guess, but the performance problem sounds like maybe as your data changes, eventually the planner moves some query from an index scan to a sequential scan, do you have any details on what queries are taking so long when things are running slow? You can turn

Re: [PERFORM] Bad iostat numbers

2006-12-04 Thread Alex Turner
I agree, that MegaRAID is very stable, and it's very appealing from that perspective. And two years ago I would have never even mentioned cciss based cards on this list, because they sucked wind big time, but I believe some people have started seeing better number from the 6i. 20MB/sec write,