Re: [PERFORM] Performance advice for a new low(er)-power server

2011-06-17 Thread Merlin Moncure
On Thu, Jun 16, 2011 at 5:44 PM, Merlin Moncure wrote: > it's complex -- but I think the whole issue becomes moot soon because > non consumer flash drives from here on out are going to have > capacitors in them (the 720 ramsdale will immediately knock out the > x25-e). So the prudent course of act

Re: [PERFORM] Performance advice for a new low(er)-power server

2011-06-17 Thread jesper
> On Jun 16, 2011, at 20:43, Greg Smith wrote: >> The layout you proposed (OS+WAL , data) might be effective, but if your >> write volume is low it may not be much of an improvement at all over a >> simple RAID1 of two drives. The odds that you are going to correctly >> lay out individual section

Re: [PERFORM] Performance advice for a new low(er)-power server

2011-06-17 Thread Haestan
On Jun 16, 2011, at 20:43, Greg Smith wrote: > The layout you proposed (OS+WAL , data) might be effective, but if your write > volume is low it may not be much of an improvement at all over a simple RAID1 > of two drives. The odds that you are going to correctly lay out individual > sections o

Re: [PERFORM] Performance advice for a new low(er)-power server

2011-06-17 Thread Haestan
On Jun 16, 2011, at 20:29, Jesper Krogh wrote: > On 2011-06-16 17:09, Haestan wrote: >> I am evaluating hardware for a new PostgreSQL server. For reasons >> concerning power consumption and available space it should not have >> more than 4 disks (in a 1U case), if possible. Now, I am not sure wha

Re: [PERFORM] Performance advice for a new low(er)-power server

2011-06-16 Thread Merlin Moncure
On Thu, Jun 16, 2011 at 5:12 PM, Greg Smith wrote: > On 06/16/2011 03:04 PM, Merlin Moncure wrote: >> >> I don't necessarily agree. the drives are SLC and have the potential >> to have a much longer lifespan than any MLC drive, although this is >> going to depend a lot on the raid controller if wr

Re: [PERFORM] Performance advice for a new low(er)-power server

2011-06-16 Thread Greg Smith
On 06/16/2011 03:04 PM, Merlin Moncure wrote: I don't necessarily agree. the drives are SLC and have the potential to have a much longer lifespan than any MLC drive, although this is going to depend a lot on the raid controller if write caching is disabled. Also, reading the post that got all th

Re: [PERFORM] Performance advice for a new low(er)-power server

2011-06-16 Thread Merlin Moncure
On Thu, Jun 16, 2011 at 1:43 PM, Greg Smith wrote: > These drives are one of the worst choices on the market for PostgreSQL > storage.  They're unusably slow if you disable the caches, and even that > isn't guaranteed to work.  There is no way to make them safe.  See > http://wiki.postgresql.org/w

Re: [PERFORM] Performance advice for a new low(er)-power server

2011-06-16 Thread Scott Marlowe
On Thu, Jun 16, 2011 at 12:43 PM, Greg Smith wrote: > There are already three layers involved here: > > -Database shared_buffers cache > -Operating system read/write cache > -RAID controller cache > > I would be skeptical that adding a fourth one near the bottom of this stack > is likely to help a

Re: [PERFORM] Performance advice for a new low(er)-power server

2011-06-16 Thread Greg Smith
On 06/16/2011 11:09 AM, Haestan wrote: The cheaper option would be to buy 15k Seagate SAS disks with a 3ware 9750SA (battery backed) controller. Does it matter whether to use a 4-disk RAID10 or 2x 2-disk RAID1 (system+pg_xlog , pg_data) setup? Am I right that both would be faster than just using

Re: [PERFORM] Performance advice for a new low(er)-power server

2011-06-16 Thread Jesper Krogh
On 2011-06-16 17:09, Haestan wrote: I am evaluating hardware for a new PostgreSQL server. For reasons concerning power consumption and available space it should not have more than 4 disks (in a 1U case), if possible. Now, I am not sure what disks to use and how to layout them to get the best perf

Re: [PERFORM] Performance advice for a new low(er)-power server

2011-06-16 Thread Merlin Moncure
On Thu, Jun 16, 2011 at 10:09 AM, Haestan wrote: > Hi, > > I am evaluating hardware for a new PostgreSQL server. For reasons > concerning power consumption and available space it should not have > more than 4 disks (in a 1U case), if possible. Now, I am not sure what > disks to use and how to layo

Re: [PERFORM] Performance advice

2003-06-26 Thread Manfred Koizar
On Wed, 25 Jun 2003 11:47:48 +0200, "Michael Mattox" <[EMAIL PROTECTED]> wrote: >> |INFO: --Relation public.jdo_sequencex-- >> |INFO: Pages 28: Changed 1, Empty 0; Tup 1: Vac 5124, Keep 0, UnUsed 0. >> ^ >> This table could stand more frequent V

Re: [PERFORM] Performance advice

2003-06-25 Thread pgsql
On Wed, 25 Jun 2003, Achilleus Mantzios wrote: > What i think would be ideal (helpful/feasible) > is some kind of documentation of the algorithms involved > in the planner/optimizer, along with some pointers > to postgresql.conf parameters where applicable. > > This way we will know > - Why somet

Re: [PERFORM] Performance advice

2003-06-25 Thread Paul Thomas
On 25/06/2003 10:47 Michael Mattox wrote: I'm using Java Data Objects (JDO) which is an O/R mapper. It generated the schema from my object model by default it used a table for a sequence. I just got finished configuring it to use a real postgres sequence. With the way they have it designed, it o

Re: [PERFORM] Performance advice

2003-06-25 Thread Achilleus Mantzios
I agree that a "directed graph"-like performance map would be difficult to be written or understood. What i think would be ideal (helpful/feasible) is some kind of documentation of the algorithms involved in the planner/optimizer, along with some pointers to postgresql.conf parameters where appli

Re: [PERFORM] Performance advice

2003-06-25 Thread Rod Taylor
> I think the biggest area of confusion for me was that the various parameters > are very briefly described and no context is given for their parameters. > improvements to the performance sections of the documentation would make a > huge difference. Agreed.. Josh has done some work recently re-

Re: [PERFORM] Performance advice

2003-06-25 Thread Rod Taylor
On Wed, 2003-06-25 at 04:12, Hilary Forbes wrote: > PM4JI but from my point of view this has been a most useful thread. I too have > found it difficult to find the right bit of documentation on performance. I *think* > what is needed is some sort of a route map, Poor Performance - start here.

Re: [PERFORM] Performance advice

2003-06-25 Thread Shridhar Daithankar
On 25 Jun 2003 at 11:47, Michael Mattox wrote: > I'm using Java Data Objects (JDO) which is an O/R mapper. It generated the > schema from my object model by default it used a table for a sequence. I > just got finished configuring it to use a real postgres sequence. With the > way they have it d

Re: [PERFORM] Performance advice

2003-06-25 Thread Michael Mattox
> [ This has been written offline yesterday. Now I see that most of it > has already been covered. I send it anyway ... ] Still great advice with slightly different explanations, very useful. > |INFO: --Relation public.jdo_sequencex-- > |INFO: Pages 28: Changed 1, Empty 0; Tup 1: Vac 5124, Ke

Re: [PERFORM] Performance advice

2003-06-25 Thread Howard Oblowitz
I agree a route map would really help. > -Original Message- > From: Hilary Forbes [SMTP:[EMAIL PROTECTED] > Sent: 25 June 2003 10:12 > To: Rod Taylor > Cc: [EMAIL PROTECTED] > Subject: Re: [PERFORM] Performance advice > > PM4JI but from my point of v

Re: [PERFORM] Performance advice

2003-06-25 Thread Hilary Forbes
PM4JI but from my point of view this has been a most useful thread. I too have found it difficult to find the right bit of documentation on performance. I *think* what is needed is some sort of a route map, Poor Performance - start here. Then some questions with sections of the documentation

Re: [PERFORM] Performance advice

2003-06-24 Thread Manfred Koizar
[ This has been written offline yesterday. Now I see that most of it has already been covered. I send it anyway ... ] On Tue, 24 Jun 2003 09:39:32 +0200, "Michael Mattox" <[EMAIL PROTECTED]> wrote: >Websites are monitored every 5 or 10 minutes (depends on client), >there are 900 monitors which c

Re: [PERFORM] Performance advice

2003-06-24 Thread Michael Mattox
> > configure it properly and trial & error. I do think the > documentation could > > be enhanced a bit here, but I'm sure there are some users who don't make > > Do you have any specific thoughts about documentation? Areas of > confusion? Was it difficult to find the information in question, or

Re: [PERFORM] Performance advice

2003-06-24 Thread Rod Taylor
> configure it properly and trial & error. I do think the documentation could > be enhanced a bit here, but I'm sure there are some users who don't make Do you have any specific thoughts about documentation? Areas of confusion? Was it difficult to find the information in question, or was it simp

Re: [PERFORM] Performance advice

2003-06-24 Thread Josh Berkus
Micheal, > I changed the postgres.conf settings as suggested by several people. I've > attached it to this email, please let me know if you see anything else I > can tweak. top still says I have plenty of ram, so should I increase the > buffers and/or effective_cache even more? Effective cache,

Re: [PERFORM] Performance advice

2003-06-24 Thread Michael Mattox
I want to thank everyone for their help and post a status update. I've made quite a bit of improvements. Here's what all I did: I refactored my algorithm, instead of updating the timestamp, monitoring the website, and then updating the status (two transactions), I wait and update the timestamp a

Re: [PERFORM] Performance advice

2003-06-24 Thread Tom Lane
"Shridhar Daithankar" <[EMAIL PROTECTED]> writes: >> - Would a RAID setup make the disk faster? Because top rarely shows the >> CPUs above 50%, I suspect maybe the disk is the bottleneck. > Yes it is. You need to move WAL to a different disk. For an update-intensive setup, putting WAL on its own

Re: [PERFORM] Performance advice

2003-06-24 Thread Michael Mattox
> Don't log your monitoring info directly into the database, log > straight to one > or more text-files and sync them every few seconds. Rotate the > files once a > minute (or whatever seems suitable). Then have a separate process > that reads > "old" files and processes them into the database. > >

Re: [PERFORM] Performance advice

2003-06-24 Thread Richard Huxton
On Tuesday 24 Jun 2003 8:39 am, Michael Mattox wrote: > I'd like to get some feedback on my setup to see if I can optimize my > database performance. My application has two separate applications: > > The first application connects to websites and records the statistics in > the database. Websites

Re: [PERFORM] Performance advice

2003-06-24 Thread Shridhar Daithankar
On 24 Jun 2003 at 12:10, Achilleus Mantzios wrote: > On Tue, 24 Jun 2003, Shridhar Daithankar wrote: > > With java runnning on same machine, I would not trust that machine for having > > free RAM all the time, no matter how much RAM you have put into it. > > There are always the -Xmx, -Xss, -Xms

Re: [PERFORM] Performance advice

2003-06-24 Thread Achilleus Mantzios
On Tue, 24 Jun 2003, Shridhar Daithankar wrote: > On 24 Jun 2003 at 13:29, Shridhar Daithankar wrote: > > > - I have at my disposal one other server which has 2 Xeons, 10,000 RPM SCSI > > > drive. Would it make sense to put Postgres on it and leave my apps running > > > on the more powerful 4 CPU

Re: [PERFORM] Performance advice

2003-06-24 Thread Shridhar Daithankar
On 24 Jun 2003 at 13:29, Shridhar Daithankar wrote: > > - I have at my disposal one other server which has 2 Xeons, 10,000 RPM SCSI > > drive. Would it make sense to put Postgres on it and leave my apps running > > on the more powerful 4 CPU server? Argh.. Forgot it first time. With java runnni

Re: [PERFORM] Performance advice

2003-06-24 Thread Shridhar Daithankar
On 24 Jun 2003 at 9:39, Michael Mattox wrote: > I'd like to get some feedback on my setup to see if I can optimize my > database performance. My application has two separate applications: > > The first application connects to websites and records the statistics in the > database. Websites are m